Skip to content
Russell Frank edited this page Jul 4, 2012 · 9 revisions

Mode of operation

Manager & Deputy are instantiated by main class and are handed data from the .torrent file. Deputy hits the tracker and sends a message to Manager with peer list. Manager decides what peers to talk to and instantiates Broker threads to talk to them. It continually verifies the state of Brokers; if they've errored out, it will shut them down.

Classes

Message?

Represents a Peer-to-Peer message in the protocol (Unchoke, Interested, Piece, etc.). Has static methods to encode and decode to/from Input/Output streams.

Broker (actor)

Keeps all the state of a peer in the client. This would be its socket, choke status, bitfield, requested piece, and more.

Funnel (actor)

Receives pieces and assembles them into some ByteBuffer. Runnable.

Piece (container)

Has an internal ByteBuffer, marks the number of the piece, marks the 'currently downloaded amount' (ie 16k of this piece has been downloaded).

Deputy (actor)

Runnable. Handles communication with the tracker.

Manager (actor)

Manages Broker objects. Verifies their state.

Torrent

Main class

Memos

Broker / Manager

  • available: Broker → Manager. Notes that a particular piece is available from this peer. The Manager must decide whether the Broker should retrieve this piece.

  • interest: Manager → Broker. Whether or not we're interested in the peer.

  • retreive: Manager → Broker. Tells the Broker to retrieve a block from the peer.

  • send: Manager → Broker. Tells the Broker to send a block.

  • complete: Broker → Manager. Informs the Manager that a piece has been downloaded. Payload contains the piece in question.

Manager / Deputy

  • peers: Deputy → Manager. Delivers a list of peers.

  • list: Manager → Deputy. Requests a list of peers.

Manager / Funnel

  • piece: Manager → funnel. Delivers a piece to the funnel.

  • fail: funnel → Manager. Informs the Manager that a piece validation failed and we'll need to re-request the piece.