I’m still playing with this debian torrent to see how real world torrent networks react. And one thing what happen, quiet often I would say, that the other side is not available from one second to the other. The problem is that my calls wait for data… the only solution make EVERY read from the socket non blocking, and thats exactly what I did.
Especially the handshake I noticed can need quiet a long time.. so in the past my handshake often failed, I just stopped to early… but I dont want to wait there until the answer arrive. Same for the payload, or better worse for payload.. I played around with the badwidth limiting of transmission (the other side of my torrent test network) and it seems that it makes this limit by slow down the piece sending.. so if he want to sent one block (usually 16kbyte Size) and the limit is set to 5kb/s it just divides the package in 3 part and send every second one of the parts ;). Nice idea btw. I will remember this when I include a limiter myself one day.
So I build something like a state machine for the network part, that can download the payload or make the handshake piece by piece. sometimes it makes it a little bit slower for one peer, but MUCH faster for multiple peers if one is limited or just slow.
In the video one can see how the download runs and at the same time new peers make the handshake. (before it always freezed at thisd position so I limited the handshake time to 100 ms)
To make some small speed tests I also begin to count the bytes transfered and measure the time… the speed is shown as the window title atm.
I only counts the real pieces bytes and not the network overhead.
Local I saw something like 700kb/s for small files and for big files something like 200kb/s on the real network.. mostly 60-70 but also once for two peers 180kb/s. Thats not very fast, but ok. Its not optimized and I notice the program waste much time for the debugoutput. First I bring it to work then I care about optimizations.