mappy

Member
  • Content count

    44
  • Joined

  • Last visited

Everything posted by mappy

  1. ApexDC++ 1.6.3 maintenance update available

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

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

    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.
  4. Individual options for HUBs

    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?
  5. dcwebui

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

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

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

    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).
  9. flexdc

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

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

    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 : )
  12. dcwebui

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

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

    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?
  15. jmDC

    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/
  16. jmDC

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

    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?
  18. jmDC

    Toast: I should have known that would be the first suggestion 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
  19. 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.
  20. dcwebui

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

    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.. Download Google Code
  22. ut2dc

    ut2dc About: This is a uTorrent announce bot, written in C++. When a torrent finishes on the uTorrent WebUI, it tells everyone in main chat. My flat uses an NMDC hub for chat and lan-only filesharing, but bandwidth limits mean we use a communal scheduling torrent server; so it's convenient to have the announces in our chat. Download: Public release v1: Mediafire More recent versions available here
  23. ut2dc

    Silly me. Both uhub and adchpp work fine if i connect with adc://localhost:port instead of just localhost:port. Thanks for your time anyway...
  24. ut2dc

    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 Next step is to use wireshark, i guess.
  25. ut2dc

    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.