Michel de Graaf
7435d48b32
The slot cap merged from master defaults to 2 uploads, and the CLI capped downloads at 5. Those are the numbers you pick when your own bandwidth is the scarce resource, but a Soulseek transfer is paced by the peer on the other end — usually a few hundred KiB/s — so what fills a modern link is many transfers at once, not faster ones. Upload slots go to 10, downloads to 20. The queue itself stays: privileged users being able to jump it is a condition of being a tolerated third-party client. serve_file also slept half a second after the last byte so the downloader could drain before the socket closed. With a cap that is time no other peer can use, and 64 uploads over 10 slots paid it six times over. A half-close says "that is the whole file" and TCP still delivers everything written before the FIN. Measured with 64 waiting peers: 2 slots 24.2s, 8 slots 6.2s, 32 slots 3.1s; at 10 slots the linger alone was 5.4s to 3.05s.
24 lines
412 B
JSON
24 lines
412 B
JSON
{
|
|
"score": 97.78,
|
|
"parts": {
|
|
"downloads": 1.0000,
|
|
"uploads": 1.0000,
|
|
"searches": 1.0000,
|
|
"browses": 1.0000,
|
|
"throughput": 0.8522
|
|
},
|
|
"load": {
|
|
"peers": 1024,
|
|
"searches": 128,
|
|
"downloads": 512,
|
|
"leechers": 256,
|
|
"browses": 128,
|
|
"file_bytes": 4194304
|
|
},
|
|
"observed": {
|
|
"downloads_completed": 512,
|
|
"uploads_completed": 256,
|
|
"bytes": 3221225472
|
|
}
|
|
}
|