Big Muscle

There is no reason why any HDD/SSD should be overrused by using segmented downloading/uploading. Files are read/written by blocks which happens regardless the segmented thing. Also, any good OS caches data in memory (to avoid many reads/writes) and any good HDD/SSD caches data in its internal cache (to avoid many reads/writes leading to the performance degradation). So in the reality, there is no difference whether you read/write e.g. 1 MB with or without segmented downloading/uploading.

Study this http://en.wikipedia.org/wiki/Regular_expression and I am sure you will find what you want ;)

What does "a lot" mean?

There is TTH for the purpose you request.

User being in 112 hubs? This could be a guide for you...

Or you can look at bundles in current DC++ branch which have TTH for directories.

Your opinion seems interesting but what about overall performance? I don't think so that it eats so much handles and memory now (not counting extreme cases like 200 hubs + 150 PM frames). Wouldn't there be big performance drop when it needs to clear and refill whole chat history and userlist content everytime you click on another tab? (however, StrongDC++ based clients have already optimized userlist memory usage, because other DC++ clients just create another memory structure for each userlist's item and therefore they eat twice more memory than really needed).

It's not so bad but current segmented downloading implementation is not optimal for performance - it creates and destroys handles too often which is not good. StrongDC++ testing version tries to improve it, but some more tweaks are needed (especially on the uploader's side). However, there's really nothing bad about segmented downloading - it brings positives only (when implemented correctly). But I would appreciate any suggestions for improvement :-) To encryption: there's really no other proper way to implemented without using another TCP port. Yeah, you can use standard TCP port and transfer some header saying "transfer will be compressed", but it is not optimal - you need whole communication channel to be secure and not only part of transferred bytes. By the way, is it really such problem to forward another TCP port?

yeah, I have read it and...? There's written that "it can send in two ways, either ... or ...", so maybe you've mistaken it with just pure "it can send.", you can also read further - the fact I stated with "should" still pays, because note claims (shorten version, so you can understand it correctly): "DC++ will use the IP if it is returned by hub (of course, it can't use something which is not returned), but it is expected to happen" :-P and about ADCGET... what the **** does it have to do with this topic? Or you're just trying to move the discussion away? But yeah, you are right, it is mentioned in DC++ changelog as ADC feature, but it's not mentioned in StrongDC++ changelog :D Where did I complain? I just stated the fact... ok, I made mistake - pseudoprotocol is not violated by NMDC hubs (at least not in the case of $UserIP2), but pseudo-protocol's extension is violated but it doesn't change anything... and it doesn't work in NMDC properly because this obsolete pseudo-protocol doesn't provide proper way of getting external IP (StrongDC++ does, but NMDC doesn't - and StrongDC++ is not the only client using NAT-T in NMDC now, also many users disable the getting external IP address).

in many cases? Have you ever tested it? :-D Yeah, NAT Traversal is not standardized but it is something which works almost in all cases (and also worked for me when I was not behind NAT but software firewall blocked ports) :-P yeah, "many" is relative, so you probably mean that "3 of 10" = "many". You SHOULD study English more properly. http://www.thefreedictionary.com/should The main meaning of should is something that it's expected to happen. I am not unhappy, I don't care that something doesn't work with NMDC protocol properly. Using update file or DHT bootstrap file is totally bad idea, because server can be down, and doing this periodically (for users with their IP changing very often) can overload the server. StrongDC++ updates its external IP in more clever way :-P

Ah, you are partially right. There's no real NMDC protocol documentation and therefore it can't be violated. But if we talk about that reverse-engineered protocol pseudo-documentation, it states "hubs supporting the UserIP2 protocol extension should automatically send the client its own IP.", but almost all NMDC hubs report UserIP2 support although admin disables autosending IP to user (at least, such situation was some months ago and I haven't rechecked it since that time).

Try to fill in your external IP address (which is probably your router's address) in settings. NAT Traversal technique works correctly in ADC hubs only, because NMDC hubs doesn't provide you with your external IP (although there is some UserIP/UserIP2 in NMDC "protocol" which almost all NMDC hubs violates).

Sorry, I don't see a logic in this claim. You wouldn't commit in my repository, because it is open to public? Huh?! Maybe I don't understand you. And this is what I call "rude". I provide you my experimental code, you use it in your client and then you say me that I can contribute to your repository? Is there any reason why I should patch your code when it is you who is interested in merging my code with yours? But that's the fact! Yeah, Crise mentioned some more things + there are some arrows when moving tabs. Also, very often some weird workaround appears in your repository to avoid some my bug (instead of informing and putting heads together to find a real solution). Believe me or not, but putting weird code into wxWidgets library is not solution for simple bugs in client code (and this is how your developer works - I don't remember his name, but it wasn't Crise who made such commits). Why just not making real developer team and working together? The answer to this question is very easy - because you are interested in ApexDC++ completion only. This is not important to me. It wasn't the point of my posts. I wanted to point at your unappropriate behaviour around it. Why you should? Because your project is completely based on my project. I sometimes notice that you even copy every stupidity and you are not able to do simple things without me doing it first (e.g. emulation off by default - in reference to your recent PM to me etc.)... and on the other side, I could put the same question, because you also reported ApexDC++ bugs to me (e.g. in my forum's betatesters area etc.) [ But why I wasn't informed about this bug? (Atlhough I don't see such problems in my code). And current wxStrongDC++ state is that it is completely done except progressbars in queue and a few settings dialog which are not done by me. You are right here. AUI MDI tabs is the thing I was inspired in your code. To share page, I don't know why but why you just lose your time on doing something needless? Why you just didn't help me with doing it properly (I had to do it myself and it took me a few days only, no problems with portability etc.)? This just looks to me that you wanted to make at least something to have ApexDC++ "fully" functional and were not interested in migration help at all. You're still talking that portability is your priority and GUI rewrite is not your point of interest. So why do you merge with my GUI? Just because it's main step to portability! The rest is only a few compile fixes which can be fixed in a few hours! Just look at adrian, for example. He just wrote me "I will port this and this and then I will commit it to your SVN". This is how the team work should work!

Infinite TTH tree download can be caused by several reasons, but the most frequent ones are bad connection, memory error or something wrong at the uploader's side. But none of them should cause 100% CPU, this is your client's bug which must be fixed.

Crise: yeah, it was not in news posts. It was in another posts in this forum where Lee was talking about ApexDC GUI rewrite. But no, it's not being rewritten, you are just merging to StrongDC++ code and that's why I posted a link - to show how does it look like in StrongDC++. You are right that you were focusing on other platforms earlier than me - I saw it when Lee came to DCDev and started to complain and blame that I added one Windows-dependent line in StrongDC++ code and it makes you merging with my code more difficult. At the beginning, I didn't want to commit wx code to SVN at all, but I did it so everyone can test it and send patches. Lee said that he will but what happen then? I was added to developer group here on forum to have access to your SVN (where I was already removed from without a reason) and after checking your SVN code I saw that you only use StrongDC++ SVN code to prepare new ApexDC++ version (and not for testing, helping me to finish it, bugfixing and sending patches as I was told earlier). Then I was told that every patch I find in your SVN. But there was nothing - nothing except StrongDC++ code + your own embedded PNG images + some hacks to allow compiling on Mac + some Apex specific things. This was not the purpose of my SVN (and that's why I'm ending with SVN commits now). And same status was still there a few days ago, Lee, no more features as you say. Maybe you should take a think what is rude.