Pothead

You're wrong. You ever had a look at the hide share code, and the amount of work arounds it has to try and get rid of the "guess-a-user" ? And it still fails occasionally due to Myinfo stripping, and lack of UserIP support. As soon as you get the same usernames in more than one hub, or the same user with different nicks in multiple hubs, you'll see it going wrong. here is some reading for you: http://www.dcpp.net/forum/viewtopic.php?t=474 http://www.dcpp.net/forum/viewtopic.php?t=5927 http://www.dcpp.net/forum/viewtopic.php?t=12415 http://www.dcpp.net/forum/viewtopic.php?t=14814

No. With NMDC protocol there is always the user guessing. The only way to actually tell which filelist to send, is for each share to have a specific port. So when they $ConnectToMe nick ip:port| you can tell from the port number they connect with, of which filelist to send. ;)

Passive mode isn't there just to piss you off. It's for people who either cannot open a ports. You can say you are active all you want, but if there isn't a port open, your firewall / router is just going to reject all the data. If you don't believe me, and you are passive, switch your settings to active mode. And then watch you timeout on everything, since you cannot receive any data. :D

What extension the files have, has nothing to do with the actual file headers. For example, get a torrent with 10 files in it. Wait until it's half done, and have a look at the details, and it'll say All 10 files are about half done. Now goto the directory, and the first 5 files will be at the full size, and the other 5 will be at 0 bytes. So it's a lot more complicated that people are making out. If you plan on sorting these parts out, and doing all that other crap, you might as well just add full Torrent support. It'll be easier.

I thought that torrent clients download loads of parts. And store them in the order it gets them. A randomish order. And when the torrent is complete, it puts them into the right order.

I've now heard of a way to do this successfully with NMDC protocol. You'll need a TCP and UDP port open for each share you have. Well that will work for active users, for passive users, erh, hmm, need to think about his one some more. Or only make it available to active users that will pursuade more people to bother trying to become active. :)

I don't think it's restricted to 10 because of instability. I would guess it's more to do with: 1. Save some slots for other people. 2. Prevent the slots being wasted, since it can fully saturate your connection, and still take more slots, which just slow the others down.

Does the Escape button do what you want ?

I'm not entirely sure either, but i think TLS "may" need it's own TCP port. For a couple of tutorials, read: http://dcpp.net/forum/viewtopic.php?t=15891 :)

:)

Not really used them, but i would class iDC and Zion as other op clients, on a later base. But i still use DCDM in most of my hubs, until i can find a suitable replacement, based on the latest dc++, and always kept up to date. DCDM development has virtually ground to a halt, with me only interested in bug fixes now (and sensible requests which can be done in under 5 minutes). Sounds like a stupid hub. Find a sensible one. 0.306 is blocked in most sensible hubs, because of the lack of TTH support. And some major security issues. Just because they cannot be arsed to upgrade doesn't mean you should forced to follow their example.

Nicks: Pothead and MikeJJ Gender: Male. Age: 27. Country: England. Zodiac: Gemini. Hobbies: Reading, cards, computers. On Dc since: late 2003. Ran a hub since: early 2004. Worse moment on DC: Demonstrating a script to Flow84. And melting his router in the process. Best thing that happened on DC: getting sick of being kicked for using DCDM++, so i installed Visual Studio . . . . I was also pretty happy when i found Hope. Sharing something i had been looking for, for about 18 months. Funniest thing on DC: Not entirely sure, there has been some really funny conversations and piss taking over the years i've been on it.

Could check if Amount of segments left minus Amount of slots for that file equal 0. If so, disconnect slowest segment, just before any segment finishes (unless it's the slowest one finishing, then no need to disconnect it. :shifty:)

That's because the new dc++ fails that check. In DCDM svn this is sorted for the automatic searching (based on dc++ version number, it may be skipped), but unfortunately not got around to prevent people from manually doing this check on them. :rolleyes:

I wonder how much attitutes like these will change when DC++ is multisource as well. ;)

What is TLS ? Anyway, try also opening port 1128 for TCP access. (TCP needs 2 ports now . . . . the one you specify, and the next number)

Apex is based on a later version of dc++. The later dc++'s removed support for old clients. So you are best complaining at the dc++ forum not here. But that said, it won't make any difference. Upgrade oDC is the most likely answer.

They have not said that. :D

You gotta choice. You can not have search spy working in hubs where you hide you share, or you can respond to search results in hubs where you got your share hidden (making hide share option useless). Or you can re-do it differently than the original hide share code, but that involves a lot of messing about. *** Edit *** Plus hide share option shouldn't be used, unless you have a Full Myinfo string and Userip in All hubs you are in. Otherwise it won't work properly (in regards of which filelist to send). I tried my best to work around the lack of these, but the less you have, the more guesswork it has to do.

You might want to read this post: http://www.dcpp.net/forum/viewtopic.php?t=16175 :ermm:

Yes, they both are still being developed. :ermm:

It stops partial sharing, so it is a solution. Most people on the DC network don't have a multisouce client anyway, so what's the harm in turning it off, if having it on means you are breaking the law in your country. ?

I did have it a few years ago, and know where i can get it from again if wanted . But it still exhibits the "guess-the-hub-the-user-is-in" characteristic. Wouldn't need a complete re-write. Just have "hub = addy:port" in the client to client communication. Or the token idea. But this protocol change would need to be done in dc++ to be effective.

Impossible to work properly for hubs which use the NMDC protocol (without changing the protocol). Should work fine with ADC protocol hubs. ;)

hehe, bummer. Well done SkyNet for being the first person to get it right. :)