Disk reads

Currently the communication between peer session and the disk tasks is through an indirection: the peer session sends a request to disk, disk sends the result to torrent, torrent performs some bookkeeping and forwards it to peer.

This same mechanism is used for reading blocks and returning them to the peer session that requested it. This is for simplicity, as the communication infrastructure already exists.

Flow

1. Peer sends request message
2. Session handles it and issues BlockRead command to disk
3. Disk reads block and additional cache_line_size blocks, places them in the read buffer, and returns them to peer's Torrent
4. Torrent records number of block bytes read and other metadata, and forwards block to peer

There is one problem here: we need to identify the peer session to which torrent should forward the block.

Two solutions:

• Session includes the peer's address (unique) in the read command, which is included in the response to torrent. Based on this, torrent can search for it in its session map and forward the message using its sender.
• Peer makes a copy of its sender and passes that along with the command. Then, disk uses that channel to send the block.

There is slight communication overhead in the second solution as creating and destroying the peer's mpsc::UnboundedSender incurs an atomic increment and decrement in Arc 's refcount, but this may be acceptable (especially with below optimization). Moreover, having to perform two trips instead of one (disk -> torrent -> peer vs disk -> peer) would likely be slower anyway (benching needed).

The second solution is chosen for simplicity.

Upload optimization

Read as many requests from peer tcp socket as possible and batch block reads. Send batch of blocks to disk and await a list of blocks to return.

Disk IO uses a read cache but this would optimize away mpsc communication overhead.

from cratetorrent.