ut2dc

[mappy 1]

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

[Mek 13]

Nice. But when your torrent transfer finishes, the files are not in your DC share immediately. I mean, there must be a filelist refresh and hashing, first. But how can you force a filelist refresh programatically? (you can do it by pressing ctrl+E manually).

[mappy 1]

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)

[Guest Toast]

any plans on getting out of the old school nmdc protocol and onto adc aswell ?

[Lee 84]

any plans on getting out of the old school nmdc protocol and onto adc aswell ?

...and also getting the hubs upgraded to ADC :)

[mappy 1]

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.

[Crise 26]

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.

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.

[mappy 1]

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

Next step is to use wireshark, i guess.

[mappy 1]

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

[Guest Toast]

well if you need any help etc just pop into adcs://devpublic.adcportal.com:16591 you got all the adc developers there, incase you wanna give ADC another go

oh and you might wanna consider a proper developer page like launchpad or github or sourceforge for your project instead of a fileshare page like mediafire things have a tenancy to get lost at those