Seed a torrent

[vimpunk]

Disk IO

• read specified block from disk
• read cache, read cache lines (pull in more blocks with one read)
• handle concurrent requests for same block with "read faults"

Peer

• handle request messages to upload block data
• handle cancel message to cancel block read:
  • probably can't cancel in-progress disk IO
  • but shouldn't upload block that was cancelled.
  • use cancel buffer and check presence before uploading after successful disk read?
• inbound connections:
  • peer session inbound constructor
  • handle inbound handhsakes
  • remove all checks that peer is not a seed (previously only downloading from seeds was supported)
  • if we have pieces, send bitfield message
• send have message to non-seed peers

Torrent

• conditionally allocate torrent on disk
• accept new connections
• unchoking peers: simplified or full unchoke algorithm? -> out of scope, we unchoke unconditionally for now (Unchoke algorithm #60)
• stop torrent alert (sent by engine) separate MR, out of scope (Use channels for engine-torrent communication #62)

Engine & CLI

• parameter to seed a file: cli arg with corresponding option in engine
• 'torrent complete' alert from torrent to engine, stopping a download session separate MR, out of scope (Use channels for engine-torrent communication #62)

Integration tests

Use cratetorrent for seeding and downloading as we already have test infrastructure to easily set up and verify cratetorrent downloads. As a next step we could have leech tests for e.g. transmission to ensure compatibility, but probably not before alpha release.

• set up 1 cratetorrent peer to seed a file
• set up 1 cratetorrent peer to download same file (can reuse existing test for the most part)

[vimpunk]

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.