Big Muscle

Member
 View profile  See their activity

  • Content count

    702

  • Joined

  • Last visited

Posts posted by Big Muscle

  1. Posted

    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 ;)

  2. Posted

    YES IT IS TURNED OFF PER DEFAULT!!

    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.

  6. Posted

    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.

  7. Posted

    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)

  8. Posted

    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.

    "My Will Be Done" is your mindset. I suppose that is the reason you also don't provide the user info in the Search Spy area too

    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.

    You can't prove it because the StrongDC authors just did it the way Apex proposes to do 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.

  9. Posted

    You are adding a MAJOR feature without their knowledge!
    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.

    I have the ONLY copy of a photo I took that 10,000 users want. Tell me exactly what is going to happen?

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

    Answer that if you can in technical detail without emotion. Answer it professionally. Show us plots of projected connection and bandwidth utilization, show us the research you have done already both actual and theoretical. Show us how ApexDC is going to handle 10,000 hits either direction.

    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.

    Show us how segmented downloads will select 5 fast users vs. 5 slow ones.

    What does the segmented downloads do with DHT search engine?

    And, an aside, you say I can ban a user from my system...

    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!

    turn DC++ into TORRENT...

    You still talk about torrent, but torrent and DHT are two completely different and independent things. Maybe you should learn before complaining.

  10. Posted

    It is "ON" by default

    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

    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

    Think about the future and just imagine:

    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.

    100,000 folks pinging and waiting in your "Waiting Users" folder

    Pinging? There's no pinging according to waiting users.

    How about the ability to BAN users or LIMIT users from making multiple connections through multiple hubs so my Brother/Sister etc. can get my vacation pictures without me having to manually disconnect the other users to free up bandwidth?

    But it's already there. Unless you use that old stupid NMDC protocol that has no way to differentiate users.

    How about finding out why Taskmanager says ApexDC++ uses constantly more and more memory with every screen update until you minimize and restore it?

    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?

    How about speeding up some internal search and display functions?

    Speeding up? On my Athlon XP 3200+, 1 GB RAM, it's pretty fast in all operations.

    How about fixing it so I can individually limit bandwidth by file or directory so 10 million users downloading a movie don't take it all up?

    How about a way to grant a slot to an individual that works? (and select a given amount of bandwidth for that user!)

    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.

    Instead of thinking only for yourself stealing from me

    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.

  12. Posted

    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.

  13. Posted

    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.

  14. Posted

    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.

    Teobald likes this

  16. Posted

    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.

  20. Posted

    ADC devs working on something.. and nmdc have it already available (thx BigMuscle :D) :)

    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.

  22. Posted

    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?

  23. Posted

    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 ;-)

  25. Posted

    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.