Big Muscle

I'm absolutely sure that it has been discussed here trilliontimes so use search first. If it doesn't help: - use /rebuild command in chat - or delete hashdata and hashindex files and rehash your share

Special DHT window is planned and it won't be ready soon. If DHT works correctly, you will see DHT nodes count increasing and stopping at 1920. You can also see dht.xml file for some information. Yesterday, I was in 3 hubs (+ DHT) and I needed to download 6,5 GB ISO file. It found about 10 sources (4 from DHT, 6 from hubs). I got no slots available for all hub users and was downloading about 1.8 MiB/s from DHT users only. It works very nice, but you must give it some time after startup :)

I would implement it for ADC if someone had made per-favgroup settings.

You can have different IP in different (favorite) hubs. But setting IP (received from one hub) for all hubs (where default settings is used) is a good idea. However, DHT does exactly the same thing.

check this: http://dcpp.wordpress.com/2010/02/13/passive-mode-c-c-connections-and-nat-traversal/ briefly: if there's connection between A-S and B-S (S is hub in our case), you can bind ports to create connection between A-B.

You must use ADC to get it fully work. It shouldn't depend whether NAT, firewall or nothing is used and should work in almost all cases. It works in NMDC only under certain conditions, because many NMDC hubs violates this old protocol.

Also, if you would use ADC or NMDC with UserIP2 then your IP would be updated correctly on hub join. The problem is that many NMDC hubs violate NMDC procotol - they report UserIP2 support, but don't send user's IP at all (especially when such option is disabled).

As visible in the callstack, the library BfsExt.dll is responsible for the crash. Uninstall program which uses it and everything will be fine.

This is interesting question. When did it happen? On settings change, after crash etc.?

what DC protocol do you use? ADC or NMDC?

If it doesn't work in some hub, it means that such hub isn't properly configured to read connection field. It is hub bug in most cases, because connection field is standard part of protocol command in contrast to tag which is ignored (and not to sent to users) by many hubs.

I'll send it to you when I get home next weekend. But I will remove this server-bootstrapping from StrongDC++ and will replace it with better way.

No, it doesn't. The only difference is the used field.

yes, this one I share on DC++, but it's old as hell Anyway, thank you that you are interested in DHT. But it's logical - your client is dead, impracticable and archaic today, so you must find something new :)

Upload limit is included in connection field where it is more logical.

Sorry, but only a fool can his share in this way. This is totally illogical and such users should be banned for non-organised sharelist. And also fools ask what has already been answered twice? three-times?

What OS do you have? As I remember correctly, WinXP ignores URL colors and sets it according to background color.

Yes and how? We were trying to add background image into Miranda's message log and without success. It has no background image feature and it also ignores any drawing events.

Because this feature just did nothing and had no sense. Whole user check is grouped into Check filelist item, but its functionality is not 100% complete yet.

As I know, background images aren't easily supported in richedits.

I was partially wrong. That each-15-results resorting occurs only when sorted by Hits column. In other case, it should insert items correctly sorted.

eMule has 3 options: a ) bootstrap from external nodes.dat (equivalent in StrongDC++ is to bootstrap from external dht.xml) b ) bootstrap from saved nodes.dat (as StrongDC++ always does when dht.xml is present in Settings folder - and it's always there when you don't run it for the 1st time) c ) bootstrap from known nodes (i.e. eMule must be connected to some server, which is not much usable, because I didn't find any working one when I was testing it) d ) bootstrap from certain node = from IP (not much usable, because you must get this IP somewhere) So the only possibility to bootstrap when you are running eMule for the 1st time is A. And it's working because this file contain many nodes (as I remember, v1 stores 200 nodes, v2 stores 5000 nodes) and only ONE node is needed to bootstrap from, so there's high probability that 1 nodes is still online. And it is much more reliable and secure than bootstrapping from server DB as StrongDC++ does. But I think that we should rather develop some good way to bootstrap from known nodes in DC hubs.

Then why published nodes.dat for eMule's KAD network works very well?

You still forget one thing. You can publish special dht.xml (for example with 1500 known nodes) with the client and it still will be able to co-operate inside this DHT network. Bootstrapping from server isn't required at all (only improvement in StrongDC++ which is not vital) and it will be removed soon, because I don't like when application connects to external website. Bootstrapping from known nodes in the DC hub would also solve that "private hubs" problems. But still, there's no solution for NMDC (without hacks).

Lee, Crise: strongdc++ website is not the only way to bootstrap from. It's only a bonus for StrongDC++ clients. I don't see the reason why other clients should connect to StrongDC++ website. The bootstrap script is very simple, so everyone can make such script (and I think everyone can make it much better then I did). Btw, Crise should have my bootstrap script because I share it and he downloaded it from me some time ago. The other possibility to bootstrap is how all other DHT clients/implementations do it. Users must download node list from server (e.g. nodes.dat in eMule, dht.xml in StrongDC++). Bootstrapping from known nodes in ADC is a plan. But NMDC won't be supported in such way, I don't want any more hacks for this old stupid protocol.