Good news, SPEEEEED :-)

Good news on the speed front, I transfered the ATorrent program to a native installation (Icaros in qemu) and there its really fast up to >3 MB/s (I have 50MBit so something like 5 MB/s possible), So 3 MB/s (Linux Mint DVD torrent Size: 1.3GB) in a virtual machine not bad, I would say. (Compiled on Linux it reaches also up to 3MB/s). This means my network handling is not that bad.
Seems the tap network for Linux hosted is very slow. there I always only get maximal 200 kb/s even on a local torrent network. (btw. the downloade file is 232.8 MB)

Until now I do not need any Threading. I’m still thinking if it later I will include some Threading possibilities. But my experience with threading at AROS are not so good, often not reproduceable crashes and deadlocks, even for code work perfectly on Linux/Windows.

To achieve this speed level I had to tweek the requests management and peer balancing. It work now much better but I’m still not satisfied. Some examples: If a request timed out (after a minute) I disconnect the peer. I noticed thats not always needed.. sometimes one packages time out but then later the other packages arrive (maybe a problem of the other side). Second: now all peers get the request with same priority, thats not bad but would make more sense if a fast peer is prefered over a slower/limited peer. I think about a kind of credit system for example: all peers start with 100 points. A request to a peer costs 10 Points, if the piece data arrive it earns again 10 points if it arrive at a specific time if it is faster it earns more point if it is slower it earns lower point.
A Timed out package costs 50 points. If the program has a slot free for it chooses the peer with highest points.
hmm maybe such thing would work, but difficult to test and set the right credits for every action.