mappy

Member
  • Content count

    44
  • Joined

  • Last visited

Posts posted by mappy


  1. 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:

    pzzGyFs.png


  2. 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.


  3. 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.


  4. 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? : )


  5. 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).


  6. 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.


  7. 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.


  8. Nice project, well chosen name too ;)

    Works like a charm, even noticed a FlexHub bug: hub was sending MyINFO's instead of NickList, will fix that.

    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 : )


  9. There seems to be a bug in calculating or formatting the $Key:

    $Lock was:

    EXTENDEDPROTOCOL_FLEXHUB_MULTIPROTOCOL_ML26

    Received :

    $Key ÑÀ° A ѱ±ÀÀ01‘ ÑÑqÑ!‘Ñ‘ ѱ±ÀÀ01!ç@a³e´1q¡/%DCN096%/åáá

    Should have been:

    $Key DÑÀ° A ѱ±ÀÀ01‘ ÑÑqÑ!‘Ñ‘ ѱ±ÀÀ01!ç@

    It looks like the key isn't calculated at all, just sending the same key everytime.

    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.


  10. PHP was doing protocol work, JS was there to bring neccessary updates to the GUI. Ajax was used to do that.

    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 smile.gif


  11. Not really, I made a chat-only DC client in pure HTML, JS, PHP and MySQL some years ago. However, it got some performance issues loading the userlist in larger hubs.

    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?


  12. flexdc

    cZyg6s.jpg

    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.


  13. if you have a better plan for direct connect then the guy that actually made the client that took dc into mainstream then please show and present your ideas cause you seem to have alot of em

    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


  14. DC++ will drop NMDC support in the future

    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?


  15. Toast: I should have known that would be the first suggestion rolleyes.gif

    As long as i don't use ADC personally, it's unlikely it'll be in any of my projects, but feel free to put it in yourself (or convince me to transition my hubs and rewrite all my bots, scripts, apps, ...)

    Lee: Thank you biggrin.gif


  16. I've tentatively completed my latest project, jmDC. If you have a phone that supports mobile java (J2ME), you now never have to miss another word of NMDC hub chat. : )

    I don't have screenshots yet, but please check it out if you have time. It's a fork of a popular java mobile IRC client, source is available under GPLv2. Any suggestions are welcome.

    http://code.google.com/p/jmdc/


  17. So... ApexDC++, as well as the upstream StrongDC++ and vanilla DC++, currently support english or cyrillic NMDC hubs based on system locale / codepage. Could you please bring this support to within the client, rather than externally? Like for instance how linuxdc++, freedc++ and eiskalt have an settings option to choose the displayed locale.

    This would give you the incredible feature of supporting UTF8 over ordinary old NMDC, like those other clients do.


  18. Mek

    Well, no... it's a web interface for a hub. Your users can visit a web page, log in and chat away on a hub of your choice.

    Because of the way html/javascript security works, the current implementation needs a proxy server. For simplicity's sake i forced it to run on the same server as the hub, but it's really arbitrary.

    Toast

    I get the message rolleyes.gif I'm copying everything to http://code.google.com/p/mappy/ .

    I'm still planning to stick with NMDC for the forseeable future, though. The same web interface should work fine with an ADC hub if the proxy backend is switched out, since it does all the real work.


  19. PSotAl.jpg

    DCWebUI

    Are you an NMDC hub owner? Give your users a javascript web interface!

    Javascript cannot open a direct TCP connection by itself. Through AJAX, however, it can retrieve urls and incorporate the response into the current page. DCWebUI uses a proxy program (supplied) that maintains connections server-side, and provides a HTTP api to communicate with the web interface.

    Binary, source code and instructions available from

    http://code.google.com/p/mappy/


  20. Dicehub

    This is the beginnings of an(other) NMDC server. It's single-threaded C++ and seems to work.

    It might be interesting to use as a basis for some other hobby project, since the source code is short..

    D1TaV.jpg

    Download

    Google Code


  21. Silly me. Both uhub and adchpp work fine if i connect with adc://localhost:port instead of just localhost:port. pinch.gif

    Thanks for your time anyway...


  22. No, not a known issue, could you describe this more... since I am connecting to ADC hubs both encrypted and unencrypted without any issues.. adchpp and uhub.

    So if you have any more details that would be big help, though I am unaware of any differences between ADC in DC++ and ADC in ApexDC++ that could create such issues (well aside from our default TLS setting, but that only matters for ADCS hubs and can be remedied by visit to settings). So your comment about difference between Apex and DC++ greatly interests me.

    Hello Crise, you make a great client.

    My comment about the difference between ApexDC++ and DC++ comes from trying to connect to DCDev, which only intermittently worked - which could be caused by a number of things, including DCDev's own intermittent uptime, or that it does use ADCS. So perhaps it was TLS related after all.

    I got a fresh adchpp 2.52 from their website this morning. With the stock configuration files, running from an administrator account and with the binary unblocked in firewall, both my existing ApexDC++ and a clean DC++ recognise that a server is running, but don't seem to fully go through the ADC login process; [image]

    I got the uhub-0.3.2 source, and built with mingw (make -f GNUmakefile). When the binary runs, it spits out "WARN: backend error." every millisecond or so. The warning seems to originate from src\network\backend.c (145), despite not triggering the error on (91) about not finding a backend. I tried to build with cygwin, but i get an error telling me to use mingw instead. Perhaps this is a known issue with uhub, perhaps i'm building it incorrectly. So i try the most recent windows build from their build archive, which is 0.28. This one runs fine, without any fatal errors, but i get the same symptom as with adchpp-2.52: [image] Both clients just sit there doing nothing. After a while, the connection times out, and they both reconnect.

    I'm a little suspicious about this, so i look up the ADC client-hub protocol and find out the handshake order, and perform it manually with netcat; [image] The server responds to my handshake, so it's at least mostly functional. Performing the same test with adchpp-2.52 gives me a similar result, as expected. But still, neither ApexDC++ or DC++ will finish a connection with either hubsoft.

    Any suggestions would be appreciated huh.gif

    Next step is to use wireshark, i guess.


  23. Funny you should mention that actually

    We've tried to migrate to ADC a couple of times, both for our flat hub and the campus hub, but ADC just seems less reliable.. ApexDC seems to not connect immediately to a fresh ADCH++ hub, and only connects intermittently to public ADC / ADCS hubs... DC++ seemed a bit more reliable at it last we tried, but Apex is substantially nicer : ) I havn't been able to isolate the problem, otherwise i'd submit a bug report. I don't suppose this is a known problem? In the present, NMDC works well enough, but better unicode support would be very nice.


  24. In my particular case, torrents are scheduled to run overnight, and they usually get hashed by the time anyone wakes up in the morning.

    To properly refresh the filelist programatically, i guess support would have to be added to the plugin API.. either that, or perhaps just an autohotkey script (find apex, restore window, ctrl+e, minimise window)