mappy

Hi, I have a report from two users that they are unable to share files on 1.6.3.The other client might get an error message "error during decompression". The user's report: <__1> so it seems to be that people start to connect to you but instantly get cut off <__1> you can get opther people's filelists but when they go to get yours it fails <__1> i rolled back to 1.6.2 with no other changes and everything works again so i'm failry confident that its 1.6.3 causing the issue <__2> this is what it does [[embedded image]] <__1> so its a problem with the encryption on the filelist? <__2> then it just cuts itself off Embedded image:

Bump! I use several hubs on the LAN and online. Would it be possible to make "network interface" a per-hub or per-group setting instead of global?

Semi-major update (r4) with some much-needed attention. Added protocol buffering, proper sanitisation, private message support, wider compatibility with hubsofts and browsers, and removed the jQuery dependency. It should be a lot more stable and useful now. Instructions are now contained with the download. State of DC on mobile devices As far as I know, this (and MekDC) are the only ways of getting DC on an iOS device. Android has this, the flash flexDC, and there are at least two android DC clients in development. Blackberry and other J2ME devices can use jmDC. I plan on compiling FlexDC as a native application for both Android and iOS with the new flash builder 4.5 update soon.

I've fixed the bug in my lock2key. It should connect fine to most hubsofts now (tested with PtokaX, YnHub, and FlexHub). There's an updated version of dcwebui available with the changes applied (although, with no other changes). The bug also applies to ut2dc, so there's a new version of that now, too.

Huh, OK. Thanks for the information. I guess that's why it's always worked, then, since the core always uses EXTENDEDPROTOCOL/$Supports, and PtokaX would just be ignoring it if it's calculated slightly incorrectly. I'll look into this bug further, since it's going to affect all my C++ NMDC projects. Anyway, it still works on PtokaX for the meantime. P.S. Any ETA on new PtokaX stable release? : )

Yeah, it assumes Windows-1252 (Latin-1) when decoding the key, at least. I think i use system locale everywhere else. I'll look into it some more (and work in some more character encoding options for the next version).

Adobe have free and OSS versions of the Flex SDK that should be sufficient to compile the project. I was given a copy of Flash Builder 4 as part of some university promotion Adobe ran a while ago, which is a custom Eclipse setup. If you have that, you should be able to just create a new project and import the source files. With the standalone SDK, it should be easily possible although i'm not sure of the exact way of configuring it. I just tried FlexDC 1.1 against FlexHub 1055, and it seemed to unlock fine first try (image). Can you reproduce that every time? You can right-click in the top toolbar in FlexDC to enable debug mode.

Thanks for the reports! I've fixed the duplicate-operators bug and added password support. I've also included all my changes since the last release, including PM support and an updated swfok daemon.

I'm glad you like it : ) It's still kinda primitive, though, there are a few things i'd like to add (fixed PM support, multiple hubs/tabs, fully brandable) but for now it suits my private hub well enough. EDIT: There are $Supports flags to determine things like whether the client prefers MyINFOs instead of NickList, and things like that. It could equally be a bug at my end, this is really only tested with PtokaX, although i'm glad to hear it works with FlexHub : )

It'll send the same key if the lock doesn't change. It looks like they're the same for most of it, i wonder what's going on? My lock2key is compatible with PtokaX, at least, although i know it's one of the more lenient hubsofts. Here's what's going on under the hood, in nmdc.cpp; //NMDCHub::handle_command(char* szCommand) if (strcmp(szCommand, "$Lock")==0) { push_event(NMDC_SYSTEM_MSG, "\0", "Found a hub."); char key[BUFS]; parse_lock(szCommandNext, key, BUFS); sprintf_s(szSay, BUFL, "$Supports NoGetINFO UserIP2|$Key %s|$ValidateNick %s|", key, self.szNick); SayExplicit(szSay); // ... void NMDCHub::parse_lock(char *lock, char* destBuff, int out_buffsize) { int len = strlen(lock); char* key = new char[len + 1]; //lock-to-key transform for(int i = 1; i < len; i++) { key[i] = lock[i] ^ lock[i-1]; } key[0] = lock[0] ^ lock[len-1] ^ lock[len-2] ^ 5; for(int i = 0; i < len; i++) { key[i] = ((key[i]<<4) & 0xF0) | ((key[i]>>4) & 0x0F); } //sanitise memset(destBuff, 0, out_buffsize); char* newkey_p = destBuff; for(int i = 0; i < len; i++) { switch(key[i]) { case 0: case 5: case 36: case 96: case 124: case 126: sprintf_s(newkey_p, out_buffsize-(newkey_p-destBuff)-1, "/%%DCN%03d%%/", key[i]); newkey_p += 10; break; default: *newkey_p = key[i]; newkey_p++; } } *newkey_p = '\0'; //tidy up delete key; key=NULL; } I have an alternate nmdc core that uses STL strings instead of <cstring>, guess i should transition dcwebui over to that core instead as well, but to be honest i don't like this approach as much as flexdc, my flash-based webui. This is more cumbersome, and the one advantage that javascript has over flash, working on mobile devices, doesn't seem to apply to me personally (i have a S40-Webkit). EDIT: Like you mentioned in the flexdc thread, this could be caused by locale settings.

So, like my dcwebui, but using PHP+MySQL for the backend instead of a C++ daemon.. that's a pretty cool project. Can i ask how you managed a persistent connection to the hub, then? This flexdc implements all the protocol work in JS, so maybe my claim holds after all

Ah, cool to hear it, i'm not too worried about that claim. Most of my hub stuff is for small-time chat with people i know in real life, so i don't have the opportunity to test it with anything much bigger than the campus hub. For the record, though, did you have PHP or JS doing the protocol work?

flexdc Are you an NMDC hub owner? Give your users a flash web interface! It's quite easy to set up; all instructions are contained in one small easy download. Get v1.1 from here or get the latest version from my google code page.

Hi... I'm not a major client developer or anything, but no matter how badly the protocol was "designed", it has a ginormous user base and it can't be disposed of that trivially. I would really like to hear what arnetheduck has to say on the matter.. What I would like to see for NMDC is the protocol documented in a IETF RFC - of all the hundreds of implementations, it's impossible to set the record straight, but we can at least set it "firmly crooked". As a text-based internet protocol that was used first and documented second, it seems to sit well with other RFC "standards" like HTTP. I might sit in on dcdev for a while

I know ADC is the future and all development happens there... but there's pretty sizable NMDC infrastructure still out there (i realise i'm contributing to this situation). Is there a timeline for DC++ dropping NMDC?