Big Muscle

This happens when some device in your network reports UDP port that is different from that one you have set. It is usually because port is not correctly forwarded in router, or you don't have public IP address.

Searching by keywords in DHT possible very easily. When your share is being indexed, it just splits all filenames to single words, then hashes each word and publish this hash to the network. Searching process runs in same way as when searching for hash, but it just specify that search is for keywords. I was considering whether to put keywords searching into StrongDC++ DHT network, but decided that it would increase bandwidth a lot. Also, there is big probability that users wouldn't connect to another hubs anymore.

It's true that it allows faster spreading downloaded segments over network and will increase a chance to download complete file when only partial sources are available. The code is just my guess. On Friday, Lee asked me how it could be done, so I just spit out this code although I have never tested it before. Today, I analyzed the code more and made some tests and it is not usable as it seems. Many users won't probably notice any problems, because they just can't know that the speed could be better. Current segment downloading (in contrast to old RevConnect's code) is designed that faster sources will get larger segments and the randomization thing completely breaks this intention. The result is lower download speed (and I don't talk about some small difference as 400 kB/s vs 300 kB/s, but about 10 MB/s vs 1 MB/s) and much more stress to HDD (because fast sources will download e.g. 50 random small segments instead of 1 large continuous block). And the last thing is that it breaks preview function. My conclusion is that the intention is good, but it must be done in completely different way than just randomization. It must take in account all possible factors, especially that dynamic segment size.

No, it won't. Everything will be slowed down especially on very fast connections. Yes, it will be very fast at beginning, but since downloaded segments have no arrangement, soon or later, you will end up with semi-downloaded file with a lot of small undownloaded segments in it (instead of a few bigger segments in normal case). And what happens then? When your download speed is e.g. 10 MB/s and segment size is e.g. 1 MB, your speed will be degraded to approx. 1 MB/s, just because randomization completely breaks that dynamic segment size which has been done in the past to dramatically improve download speed on fast connections. And the more bytes downloaded, the worse it will be.

try File menu > Open own filelist. Is you share visible there?

PMs over DHT were supposed to work, but I disabled this feature later, because I haven't found any possibility to avoid PM spam.

I would advise: * try StrongDC++ to exclude any ApexDC-specific error * try DC++ 0.770

I really have no clue why this happening. The code for all sockets is same, so it is really interesting why it happens for DHT socket only. Try exchaning DHT and general UDP ports to see what happens.

But I was talking about stated wannabe problems: - they claim that DHT is bad, because it will share data outside of their private hub. It's true, but when user connects to another hubs, it will be shared outside of their private hub too. And they will be much more easily accessible in hubs, because you just use search or download filelist to get them. You need to know TTH in DHT. So hubs are more security issue than DHT. - they claim that DHT is bad, because it will use their limited bandwidth. Again, it's true, but when you don't use DHT and only connect to hubs, you will get less sources. And less sources = more stress on uploader's bandwidth, because you will download more bytes from them. So when many users disable DHT, users' bandwidth will be used much more.

I use no antivirus and still living :rolleyes:

try ctrl+up and ctrl+down :rolleyes:

I'm not sure you know what you are talking about. Or why do you talk about DHT when named problems paid for every hub and is not DHT specific? DHT = virtual hub and that's why same rules should be applied on DHT like on another hubs.

enabled by default - what's the difference in bandwidth usage when DHT is enabled by default and when it's not enabled by default and user enables it on his own? their - as you said, it's their bandwidth, so why the hell should the hub decide whether user wants DHT or not? If you block users who are connected to another hubs too, then everything is ok. And PPK is right in that topic, more clients with DHT-based network exists and also some of them are fakeclient which can fake tag. So you won't be able to block them It's same as it was with upload limiter in the client. StrongDC++ was blocked in some stupid hubs because of upload limiter (although it was set to e.g. 10 MB/s) So hubs were full of fakeclients with limit set to 1 kB/s (and nothing in tag) and admins were happy, because there were no clients with L: in its tag It's really funny arguments against DHT, I read everywhere. It's still "DHT this" and "DHT that", so we will block it. But another hubs where user is connected to are no problem although the same arguments can be applied on them. That's the reason why DHT detection will be removed in future and only hub count will be increased by one when DHT is enabled. Oh, and by the way, when user enables DHT after connection to your hubs has already been made, then your detection fails, because DHT won't be reported to anywhere. So it is better for you to have it enabled it by default :P

Also, since any DHT security issues are only private hubs admins' myth, they must solve anything about it by their own. From what I have already read, I'm thinking about removing DHT detection and putting enabled DHT in hub count in tag (NMDC) or INF/HN (ADC). It will more reflect so-called private issues and will be more honest.

Since direct connect is about sharing in public, then yes, it's good.

TestSUR checking has already been removed and whole client detection was merged under "Filelist check", but old profiles still expect TestSUR and therefor return error.

I just guess you use old (and incompatible) client profiles.

But it's the user who breaks privacy and not DHT. It's user who shares such private material and same problem can appear when he is connected to another hub. It's not limited to DHT only. Lee: DHT is just experimental option, so it is in Advanced settings. When it is maximally optimized and all bugs are fixed than it will be moved to some other page - sharing or upload page. I was also thinking about putting it into Favorite hubs (as non-deletable item) where user could connect/disconnect or select auto-connect (by (un)checking the checkbox).

DHT just uses modification of ADC protocol. That's all. But the guide is still faulty. ApexDC++ doesn't come with DHT, it is StrongDC++ which comes with it ;)

How is the security broken?

It's absolutely stupid to block DHT via hub. Why should this happen? Any real reasons? DHT is just another hub where user is connected to, should hubs block another hubs too? One opinion is that it can break user privacy. But question is "How?". When user doesn't want it, he can disable it. But when user wants it and leaves it enabled, it's only his right. Hub has absolutely no rights to decide what user enables unless it is some thing which can influence other users in hub or hub itself (e.g. fake features, too much segments per file etc.) But how DHT influences hub or other users? In no way. It's just ******** of admins/hubowners which prefer virused, trojaned or just exploitable clients in their hubs before having DHT enabled.

What OS do you have? During wx migration I found interesting bug in Windows 7 - they completely freeze when system runs out of memory.

Sorry, but could you explain what does this thing have to do in p2p client? Or should we also implement controlling of Microsoft Word? Or maybe BIOS editor in DC client would be good thing :whistling:

Only verified downloaded data are saved to disk. If remote client doesn't provide full TTH tree (or provides invalid one), then verification will be based on whole TTH root, so it will be processed at the end of whole file. And it means parts before can't be verified, so they won't be saved to disk.

Limit isn't 5*(slots + 4) but 5*slots + 4. So You get 54 kB/s by having 10 slots (5 * 10 + 4 = 54) :thumbsup: