Pothead
Member-
Content count
105 -
Joined
-
Last visited
Posts posted by Pothead
-
-
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. ;)i don't understand your point about the need of active and passive and stuff... don't you just have to create different file lists, and choose which one to use for each hub you connect to? -
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....when passive user try download from passive user DC must automatically say to this user "I'm active!" and start downloading......is it possible?
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
-
Maybe not, since there is an option "Put *.??? extension to temporary files" in most BT clients. So it is not hard to check out.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:i have tested clients with unlimited segments and i have never had a problem... the clients are stable and don't crash1. 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:
-
:)-- 0.674 2005-04-10 --*** WARNING ***
This version fixes a security bug, upgrade unless you want to risk losing data
anywhere on your drive, this error affects all clients from 0.307 to date (thanks cologic for finding it)
*** WARNING ***
-
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).Regarding the 0.401 issue Most GOOD OP Clients are 0.401 sourced have you found a decent OP client based any higher? Bet you havent thats why DCDM is still being developed I have a feeling Pothead would agree along with all the other op client developers.
Sounds like a stupid hub. Find a sensible one."[14:04] <-=Librarian=-> Dc++ ver.690 and up and strong Dc++ ver 2.0 and up are not allowed here if your found using those clients you will be banned until you roll back to an earlier client "most people in the hub use older clients.
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:hmm... bear in mind that zion/dcdm - maybe others too - have broken bcdc detection. new version of dc++ is detected as bcdc mod. -
I wonder how much attitutes like these will change when DC++ is multisource as well. ;)
-
I made a video. Watch it, nothing other is needed to be said
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.Did You remove something in Apex? -
They have not said that. :Dnot until DC++ implements it, and that is something the developers have said they will never do. -
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.
-
-
Yes, they both are still being developed. :ermm:I just noticed that CZDC++ and BCDC++ still seem to be in development. At least it appears so according to this list of DC clients. -
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. ?Turning off segment downloading, like mothod of suspending sharing fragments is not solution. -
I did have it a few years ago, and know where i can get it from again if wantedI think there was a special ODC++ version, which has that feature. I remember someone sent it to me, but I cannot recall if that was the source or the client...havent tried it.. 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.This feature, whatever you think of its rights and wrongs, is not one to go in ApexDC in its current form. The reason is that it would require such a huge amount of change to the assumptions that are inhenrent in the design of the client that a complete rewrite would be the best way (given that dc++ needs a complete rewrite anyway). -
Impossible to work properly for hubs which use the NMDC protocol (without changing the protocol).It's a common request... is it because of difficulty in implementation, or for some other reason that it has not been taken up yet?Should work fine with ADC protocol hubs. ;)
-
hehe, bummer. Well done SkyNet for being the first person to get it right. :)yeah, that's true, but actually you weren't the first one to say that, you were the second
Different Share for different HUBs
in Feature Requests
Posted
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