MaxSimultaneousSourceSearch

[GooodFr]

Hi !
Thanks for aMule dev ;)
aMule, like eMule, since 20 years, are only able to download few files in same time (20 ? 30?)
If I have 1.000 file in my list, only 20-30 files will have source search.
970-980 files will wait till firths files finished.
20 years later, fast network, fast CPU, much memory ...
Why couldn't have a biggest MaxSimultaneousSourceSearch ?

[got3nks]

Thanks @GooodFr — this is a fair point and worth unpacking, because the limit you're hitting is real but it's more specific than a single "max files" knob.

There's no MaxSimultaneousSourceSearch setting as such. What actually gates a large queue is source discovery, throttled by two independent paths:

Kad — KADEMLIATOTALFILE = 5 caps how many files can be searching Kad for sources at once, and KADEMLIAASKTIME (1s) means at most one new search starts per second, with each file then backing off for hours (KADEMLIAREASKTIME). With a 1,000-file queue this is exactly the drip-feed you're describing.

ed2k servers — source requests are batched 15 files per TCP frame, one frame every ~5 minutes, plus a per-file re-ask timer of ~15–22 minutes.

On the Kad side, you're right that these numbers are inherited from eMule and predate modern hardware and network conditions. It's genuinely reconsiderable. The eMuleAI fork already raised KADEMLIATOTALFILE from 5 to 100 (keeping the 1-per-second ramp, so it fills gradually rather than bursting) and tightened the Kad re-ask interval, and that's a reasonable proof that the DHT can take more concurrent lookups.

Here's how the relevant constants compare across the three codebases:

Constant	eMule 0.70b	aMule	eMuleAI
KADEMLIATOTALFILE (concurrent Kad searches)	5	5	100
KADEMLIAASKTIME (gap between new searches)	1s	1s	1s
KADEMLIAREASKTIME (per-file Kad re-search)	1h	1h	30 min
FILEREASKTIME (re-ask an existing source)	29 min	~21.7 min	15 min
SERVERREASKTIME	15 min	~13.3 min	15 min
UDPSERVERREASKTIME	30 min	~21.7 min	30 min
ed2k server TCP batch	15 / 5 min	15 / 5 min	15 / 5 min

I'd want the other maintainers to weigh in before we commit to a specific value, since it changes our load on the shared Kad network — so consider this an open question rather than a decision.

The ed2k-server path is a different story and I'd leave it as-is. Those limits aren't about your hardware — they exist to stay within the source-request credits that Lugdunum servers meter, and the re-ask floor is deliberately kept above the ~10-minute mark that gets clients auto-banned for reask spam. Most servers still in operation run older Lugdunum builds, and flooding them with more frequent OP_GETSOURCES would get us throttled or banned rather than finding sources faster. Note that eMuleAI left the ed2k batch untouched too — the win there is on Kad, not ed2k.

Short version: the Kad limit is a candidate for a bump and there's prior art for it, pending maintainer agreement on the number; the ed2k-server limits should stay where they are.

cc @mrjimenez @ngosang @danim7 @sc0w — what's your appetite for raising the Kad concurrent-search cap? Prior art (eMuleAI) went 5 → 100; I'd lean toward something more conservative to start, but curious where you all land.

[mrjimenez]

Hi @got3nks , nice summary.

Indeed, those limits are old, still they must be adjusted carefully so we don't get banned or screw the network. That said, since we have a precedent with eMuleAI, that makes tickling with those things more secure.

For me it's thumbs up for raising Kad limits. What do you consider a conservative limit that still has a nice impact and is more adequate to a 20 years older internet?

[got3nks]

As drafted in #308, I'd settle for a middle-ground 50.

[danim7]

Agreed on keeping the current ed2k-servers limits, we will revisit when an alternative for Lugdunum becomes adopted.

For Kad, I'm positive to raise the 20 years old limits, but a deeper analysis may be necessary first:

• Is there any rate-limit / ban in the current code if we send too many packets? I did a quick grep in the code and found allowedPacketsPerMinute which may ban our client in kademlia/net/PacketTracking.cpp. Do the new constants risk triggering a ban?

• Also, are there any other constants raised by eMuleAI that we may also raise in our code to meet 2026 Internet standards? This one is not Kad specific, but I always think this "Max New Connections Per Five Seconds" in the preferences is really outdated, and if I'm reading eMuleAI source correctly, they raised it to 60.

[got3nks]

All valid points and already answered in #308