Big Muscle

I think there's no difference whether it is dc or adc. Since DC++ rule the Direct Connect work, official DC client doesn't exist anymore and there's no official DC specification, then we can talk DC++ == DirectConect. And I'm pleased that PPK used my other stuff in new version of his client (but it's funny that he didn't copied only a code but also my own comment) and also was inspired in one of my optimizations ;)

Then it's no worth implementing this, because only minimum users will enable it and it won't change anything. Such small amount users can be easily found in hubs and it brings nothing to finding sources.

I guess it could be because Apex doesn't contain StrongDC++ fix from June.

What's the purpose of running more instances? Faking?

I don't see any reason to allow it, since there's no possibility to have different/no share for more hubs. Yes, there are already some "implementations", but invoking race condition can lead to download different share ;-)

Such file is shared until you restart your client or until you delete it from Finished downloads window. About searching, these files won't never be found via classic search. They are found only via TTH search and are not displayed in Search window. They are immediately added as new source.

I'm for cleaning up this topic and having it for DHT suggestions only. I don't think we are interested in opinions like "I don't want to share, so remove this feature". Current status: DHT Nodes: 14646 (5790 verified)

I'm sorry, but this topic is about DHT search engine. You put some your opinions about it and I showed you that you were completely wrong (like bandwidth usage, search flooding etc). So then you just ignored my proves and start talking about things which aren't subject of this topic (extra slots, banning users etc.) So if you don't want to argument about things you started about then I don't really understand why you started to complain here. yes, you are right here! You should realize that you are in open source world and if you don't like it, just download sources and modify it yourself. And about Search Spy? There's no info, because protocol doesn't send other things then that it displays - another things you don't know about and start talking about it. Just the last things. What does this mean? What I can prove? What StrongDC authors did in Apex's way? I don't know if I understand you correctly, so I'm asking first.

Without their knowledge? It's not true! You're only trying persuade us that it's that. There was a post in my forum that it will be implemented. There is post in this forum about DHT, there is post on ADCPortal, there has been many discussion about DHT mainly in public hubs, there is entry about DHT in brief changelog and milion entries about DHT in detailed changelog, there was a public beta informing what DHT is, DHT Search engine is mentioned on StrongDC++ main page etc. So without whom knowledge? It's your problem that you are ignorant and ignore all stuff informing about DHT. In case, it's not some some very huge photo, nothing will happen. But let's say about movie/DVD image. If there is more (more than 10 - 20) users in DHT and 10000 starts searching for that movie/DVD image, there is a big probability that search request will never get to you. And what happens when that users want to download (after searching) that movie? It will be the same as you would be in hub where 10000 users wants your file. And you said something about multiplying, so it was only your bad theory which applies only for hub cases with O(N) complexity, but can't be applied to DHT where complexity is only O(log N). I don't have plots with network development, but I have exact numbers. When there was about 100 nodes in DHT, my client's traffic was about 27 MB/12 hours. Now, there is about 12000 nodes in DHT and my client's traffic is less than 17 MB/12 hours. What does the segmented downloads do with DHT search engine? no, I said that there is already "feature" which disallows what you wanted - same user downloading from you twice because he is in multiple hubs. Ban system will never be implemented, because this is SHARING application. If you don't want to share than turn your client off! You still talk about torrent, but torrent and DHT are two completely different and independent things. Maybe you should learn before complaining.

yes, and it can be turned off. It's only your problem that you aren't able to click on simple check box to disable feature you don't want. Maybe you shouldn't use computer at all, clicking is very important need! RIAA? Do you afraid of them? Maybe you share some illegal (copyrighted) material. But it's only your problem! Maybe some RIAA person watches this forum, so now they know that they should check you :-P If your numbers refer to DHT, then you have absolutely no point how DHT works. The more nodes participate in the network, the less probability that you will be contacted. Pinging? There's no pinging according to waiting users. But it's already there. Unless you use that old stupid NMDC protocol that has no way to differentiate users. ApexDC++? Maybe... but the first DHT client - StrongDC++. Eats at about 35 MB RAM with 5 big hubs and DHT enabled after 12 hours. Currently, it was 22 MB RAM after 2 hours with 2 hubs. Too much for you? Speeding up? On my Athlon XP 3200+, 1 GB RAM, it's pretty fast in all operations. Yes, of course. So I could set my limit 1 B/s for all users and unlimited for OPs. Very nice feature for fakers! And granting slots? It normally works per user basis. Stealing from you? Maybe you should stop using p2p networks at all, because it's about sharing. If you think that downloading from you is sharing than go away. And next time... use "Edit" function and don't create unnecessary new posts. But I know that it's really hard for you to click "Edit" button when you aren't able to uncheck simple checkbox to disable feature you don't want. And if you're talking about "USER CHOICE", then DHT IS USER CHOICE. It's only up to you if you leave it enabled or disable it. But you aren't able to disable it, then sorry, but we can't help you.

I also understand that users want make sharing illegal material much easier. Having DHT enabled plays agains sharing illegal material. But StrongDC++ will never go in such illegal way. So if user wants to use it for it, it's only his turn to customize the settings. I also understand that some people want to only share personal photos, videos etc. with their friends. But this isn't the purpose why StrongDC++ is being developed. But, if someone wants to use it for such purposes, it's only his turn to customize settings. Also, someone may thought that DHT will cause leaking private informations, file hashes, files etc. from "private" hubs. But this isn't true, because these informations aren't stored in hubs and have nothing to do with hubs. And, if ApexDC++ developers will set DHT defaultly off, it's only his right. But in such case, they don't have to implement it at all, because nearly nobody will turn it on. However, DHT bootstrap script will accept only StrongDC++ clients. About the security... yes, they are still some things which need to be solved.

Exactly, what you are saying is that what I wanted to avoid by not implementing keyword publishing in DHT. Therefore, connection to hub is still required to search files by keywords. DHT can be used only for TTH searches... also, there is another positive for DHT - when you are connected to hub and there's some user. When this user is found as a source (in hub or via DHT), it will initiate connection via DHT and not via hub. So as the result, it will decrease hub load.

The main problem is that a lot of users aren't aware of the purpose of SHARING DC-based application. It has been designed to share files with users. And not to share files with ONLY SOME users. Hubs are only a mean to allow connecting to these users. The second thing is that neither protocols (neither ADC nor NMDC) nor whole application differenciate between public, private or somewhat other. There's only internet network. So, if users use application/protocol for some special case, it's only his turn to study all documentation (changelogs, forums etc.) and to customize app's settings to its need. So there is really no reason to have DHT defaultly off or to inform user with some special things. The third thing is that it is open source application and users take its own responsibility for using it. If hubs will ban StrongDC++ due DHT, it's only their problem and I will only be glad that StrongDC++ users won't be in such hubs. StrongDC++ has been designed for sharing with all users, so our users shouldn't go to hubs which are against sharing. And the last thing, if you don't want to share your files with all people, then turn your client off, delete it from your HDD and go away from sharing world.

DHT is mentioned in a changelog so users are awared of this function. If they don't read it, it's their problem and not ours.

DHT has nothing to do with hubs so there is no reason why it shouldn't be visible to them. Or do you also display to hubs that you are connected to hubs DCDev Priv, DCDev Pub and e.g. Bestofall hub? I don't think so.

Being in private hub + DHT is absolutely the same as being in private hub + public hub ;-)

It has been proved that using more then a few hubs doesn't bring you anything. In other words, being in 200 hubs is absolutely same as being in 50 hubs.

we are not fakers, sorry.

Your claim is absolutely false. As I know ADC devs work on ADCS specs, but NMDC has neither its own specification less so the specification to its secure extension.

You don't have to wait for anything. This change is allowed since the first version of DC++ :)

Lotus: tag has been made for information purposes only. Of course, hub has right to ban client according to this tag. But... it should specify the real reason of ban. It's correct "You have too many slots in your tag. Correct it." when "S:9999" etc. Also it's correct "You have invalid/non-allowed tag. Correct it." for "<ApexDC...>". So, user should be able to correct it so he can enter the hub. (And because it is user settable option, he can change <ApexDC...> to something different - the same as he can change slot number S:9999 to S:3). What I only want to say is that using tag to detect client is bad option and it's not cheating when user is allowed to change the tag. Or is it cheating when user sets 3 slots and not 4?

Lotus: No, it's not what we are doing. We just follow protocol specification and update user's description according to user's choice. Since there's no tag in NMDC, we give user a choice whether to attach "core version" (ApexDC++'s core is still only DC++ 0.xxx) or "client version". If hub doesn't want ApexDC++ to enter, it should use proper means to detect and not restrict clients by user-settable field. It's hub fault. (If you still don't understand, just imagine what happens when user with original NMDC client sets its description to something like "<ApexDC...>" (protocol allows it; if hub doesn't allow it, it violates protocol). He will be banned for using ApexDC++ although he doesn't use it. It only shows that hubs use invalid mean to detect clients). adrian: the reason is same why NMDC hubs restrict user's description field. The difference is that ADC's VE field is really designed for client identification while NMDC's description field isn't. True, there's no such ADC hub today, but it may be because there's no "really usable" ADC hubsoft at all ;-)

So you want to say that original NMDC client violates its own NMDC protocol, because it allows user to write any tag he wants?

Also people should realize that there's no emulation. Since original NMDC client doesn't have any tag, it's a bug in NMDC hubsoft implementation if it detects clients by tag. Tag is only a part of description where user with original NMDC client can write what he wants.