... | ... | @@ -379,6 +379,10 @@ in or is interested in the file. This record type has the following fields: |
|
|
<dd><p>The socket through which to communicate with the peer.
|
|
|
</p>
|
|
|
</dd>
|
|
|
<dt>bitfield</dt>
|
|
|
<dd><p>A bitfield representing the availability of pieces from that peer.
|
|
|
</p>
|
|
|
</dd>
|
|
|
<dt>choking</dt>
|
|
|
<dd><p>A boolean indicating whether the remote peer choked us. When we are choked,
|
|
|
we shouldn’t request blocks to that peer.
|
... | ... | @@ -399,6 +403,10 @@ choking it, it shouldn’t ask |
|
|
remote peer will not likely unchoke us unless it is aware we are interested.
|
|
|
</p>
|
|
|
</dd>
|
|
|
<dt>channel</dt>
|
|
|
<dd><p>A <code>guile-fibers</code> channel.
|
|
|
</p>
|
|
|
</dd>
|
|
|
</dl>
|
|
|
</dd></dl>
|
|
|
|
... | ... | @@ -409,96 +417,137 @@ remote peer will not likely unchoke us unless it is aware we are interested. |
|
|
</p></dd></dl>
|
|
|
|
|
|
<dl>
|
|
|
<dt><a name="index-get_002dnew_002dpeer"></a>Scheme Procedure: <strong>get-new-peer</strong> <em><var>host</var> <var>port</var> [#:options (<var>id</var> <code>#f</code>]</em></dt>
|
|
|
<dt><a name="index-update_002dpeer"></a>Scheme Procedure: <strong>update-peer</strong> <em><var>peer</var> [#:options <var>id</var> <var>sock</var> <var>bitfield</var> <var>choking</var> <var>interested</var> <var>am-choking</var> <var>am-interested</var> <var>channel</var>]</em></dt>
|
|
|
<dd><p>This procedure returns an updated record for peer with the same content for
|
|
|
fields of <var>peer</var>, but updating values of the corresponding optional
|
|
|
arguments that were given.
|
|
|
</p></dd></dl>
|
|
|
|
|
|
<dl>
|
|
|
<dt><a name="index-get_002dnew_002dpeer"></a>Scheme Procedure: <strong>get-new-peer</strong> <em><var>host</var> <var>port</var> [#:options (<var>id</var> <code>#f</code>)]</em></dt>
|
|
|
<dd><p>This procedure connects to a peer specified by <var>host</var> and <var>port</var> and
|
|
|
returns a new peer object. The <code>id</code> field is filled with the value of
|
|
|
the optional argument <var>id</var>.
|
|
|
</p></dd></dl>
|
|
|
|
|
|
<dl>
|
|
|
<dt><a name="index-send_002dhandshake"></a>Scheme Procedure: <strong>send-handshake</strong> <em><var>peer</var> <var>infohash</var> <var>self-id</var></em></dt>
|
|
|
<dd><p>This procedure sends a handshake message to <var>peer</var>. The handshake must be
|
|
|
the first message sent to the peer. It specifies the <var>infohash</var> and our
|
|
|
<var>self-id</var> (peer id).
|
|
|
<dt><a name="index-send_002dhandshake"></a>Scheme Procedure: <strong>send-handshake</strong> <em><var>sock</var> <var>infohash</var> <var>self-id</var></em></dt>
|
|
|
<dd><p>This procedure sends a handshake message to <var>sock</var>, a peer socket. The
|
|
|
handshake must be the first message sent to the peer. It specifies the
|
|
|
<var>infohash</var> and our <var>self-id</var> (peer id).
|
|
|
</p></dd></dl>
|
|
|
|
|
|
<dl>
|
|
|
<dt><a name="index-receive_002dhandshake"></a>Scheme Procedure: <strong>receive-handshake</strong> <em><var>peer</var> <var>infohash</var></em></dt>
|
|
|
<dd><p>This procedure waits for the handshake of the <var>peer</var> and compares its content
|
|
|
<dt><a name="index-receive_002dhandshake"></a>Scheme Procedure: <strong>receive-handshake</strong> <em><var>sock</var> <var>infohash</var></em></dt>
|
|
|
<dd><p>This procedure waits for the handshake on <var>sock</var> and compares its content
|
|
|
with the <var>infohash</var> we are interested in. If the handshake is valid, returns
|
|
|
an updated <code>peer</code> object.
|
|
|
the remote <code>peer-id</code> object associated to the connection, i.e. the peer
|
|
|
id of the remote peer. Otherwise, returns <code>#f</code>.
|
|
|
</p></dd></dl>
|
|
|
|
|
|
<dl>
|
|
|
<dt><a name="index-receive_002dmessage"></a>Scheme Procedure: <strong>receive-message</strong> <em><var>peer</var></em></dt>
|
|
|
<dd><p>This procedure waits for a message from the <var>peer</var> and decodes it. If it
|
|
|
is a valid message, returns an updated <code>peer</code> object. It prints the
|
|
|
message and its content to the standard output.
|
|
|
</p></dd></dl>
|
|
|
<dt><a name="index-receive_002dmessage"></a>Scheme Procedure: <strong>receive-message</strong> <em><var>sock</var></em></dt>
|
|
|
<dd><p>This procedure waits for a message on <var>sock</var> and decodes it. If it is an
|
|
|
invalid message, returns <code>#f</code> or throws an exception. Otherwise it returns
|
|
|
a symbol or an association list corresponding to the message that was received.
|
|
|
</p>
|
|
|
<p>The bittorrent protocol specifies these messages:
|
|
|
</p>
|
|
|
<ul>
|
|
|
<li> <code>'keep-alive</code>
|
|
|
</li><li> <code>'choke</code>
|
|
|
</li><li> <code>'unchoke</code>
|
|
|
</li><li> <code>'interested</code>
|
|
|
</li><li> <code>'not-interested</code>
|
|
|
</li><li> <code>(("type" 'have) ("piece" <var>piece-num</var>))</code>
|
|
|
</li><li> <code>(("type" 'bitfield) ("bitfield" <var>bitfield</var>))</code>
|
|
|
</li><li> <code>(("type" 'request) ("index" <var>index</var>) ("start" <var>start</var>)
|
|
|
("len" <var>len</var>))</code>
|
|
|
</li><li> <code>(("type" 'piece) ("index" <var>index</var>) ("start" <var>start</var>)
|
|
|
("block" <var>block</var>))</code>
|
|
|
</li><li> <code>(("type" 'cancel) ("index" <var>index</var>) ("start" <var>start</var>)
|
|
|
("len" <var>len</var>))</code>
|
|
|
</li><li> <code>(("type" 'port) ("port" <var>port</var>))</code>
|
|
|
</li></ul>
|
|
|
</dd></dl>
|
|
|
|
|
|
<dl>
|
|
|
<dt><a name="index-send_002dkeep_002dalive"></a>Scheme Procedure: <strong>send-keep-alive</strong> <em><var>peer</var></em></dt>
|
|
|
<dt><a name="index-send_002dkeep_002dalive"></a>Scheme Procedure: <strong>send-keep-alive</strong> <em><var>sock</var></em></dt>
|
|
|
<dd><p>This procedure sends a keep-alive message. These messages must be sent from time
|
|
|
to time because peers will close the connection after typically 2 minutes of
|
|
|
inactivity.
|
|
|
</p></dd></dl>
|
|
|
|
|
|
<dl>
|
|
|
<dt><a name="index-send_002dchoke"></a>Sceme Procedure: <strong>send-choke</strong> <em><var>peer</var></em></dt>
|
|
|
<dd><p>This procedure sends a message to choke the remote <var>peer</var>. It should not
|
|
|
ask us for pieces anymore.
|
|
|
<dt><a name="index-send_002dchoke"></a>Sceme Procedure: <strong>send-choke</strong> <em><var>sock</var></em></dt>
|
|
|
<dd><p>This procedure sends a message to choke the remote peer on <var>sock</var>. It
|
|
|
should not ask us for pieces anymore.
|
|
|
</p></dd></dl>
|
|
|
|
|
|
<dl>
|
|
|
<dt><a name="index-send_002dunchoke"></a>Scheme Procedure: <strong>send-unchoke</strong> <em><var>peer</var></em></dt>
|
|
|
<dd><p>This procedure send a message to unchoke the remote <var>peer</var>. It can now
|
|
|
request pieces from us.
|
|
|
<dt><a name="index-send_002dunchoke"></a>Scheme Procedure: <strong>send-unchoke</strong> <em><var>sock</var></em></dt>
|
|
|
<dd><p>This procedure send a message to unchoke the remote peer on <var>sock</var>. It can
|
|
|
now request pieces from us.
|
|
|
</p></dd></dl>
|
|
|
|
|
|
<dl>
|
|
|
<dt><a name="index-send_002dinterested"></a>Scheme Procedure: <strong>send-interested</strong> <em><var>peer</var></em></dt>
|
|
|
<dd><p>Tell the remote <var>peer</var> we are interested.
|
|
|
<dt><a name="index-send_002dinterested"></a>Scheme Procedure: <strong>send-interested</strong> <em><var>sock</var></em></dt>
|
|
|
<dd><p>Tell the remote peer on <var>sock</var> we are interested.
|
|
|
</p></dd></dl>
|
|
|
|
|
|
<dl>
|
|
|
<dt><a name="index-send_002dnot_002dinterested"></a>Scheme Procedure: <strong>send-not-interested</strong> <em><var>peer</var></em></dt>
|
|
|
<dd><p>Tell the remote <var>peer</var> we are not interested.
|
|
|
<dt><a name="index-send_002dnot_002dinterested"></a>Scheme Procedure: <strong>send-not-interested</strong> <em><var>sock</var></em></dt>
|
|
|
<dd><p>Tell the remote peer on <var>sock</var> we are not interested.
|
|
|
</p></dd></dl>
|
|
|
|
|
|
<dl>
|
|
|
<dt><a name="index-send_002dhave"></a>Scheme Procedure: <strong>send-have</strong> <em><var>peer</var> <var>piece</var></em></dt>
|
|
|
<dd><p>Notify the <var>peer</var> we have completed download of <var>piece</var>, the zero-based
|
|
|
index of the piece.
|
|
|
<dt><a name="index-send_002dhave"></a>Scheme Procedure: <strong>send-have</strong> <em><var>sock</var> <var>piece</var></em></dt>
|
|
|
<dd><p>Notify the remote peer on <var>sock</var> we have completed download of <var>piece</var>,
|
|
|
the zero-based index of the piece. It doesn’t need to be a piece downloaded
|
|
|
from that peer.
|
|
|
</p></dd></dl>
|
|
|
|
|
|
<dl>
|
|
|
<dt><a name="index-send_002dbitfield"></a>Scheme Procedure: <strong>send-bitfield</strong> <em><var>peer</var> <var>bitfield</var></em></dt>
|
|
|
<dd><p>Send a <var>bitfield</var> to the <var>peer</var> to tell it what pieces we already have
|
|
|
or not. This is not required if we don’t have any piece yet. This procedure
|
|
|
should only be used once after the handshake and before sending any other
|
|
|
message.
|
|
|
<dt><a name="index-send_002dbitfield"></a>Scheme Procedure: <strong>send-bitfield</strong> <em><var>sock</var> <var>bitfield</var></em></dt>
|
|
|
<dd><p>Send a <var>bitfield</var> to the remote peer on <var>sock</var> to tell it what pieces
|
|
|
we already have or not. This is not required if we don’t have any piece yet.
|
|
|
This procedure should only be used once after the handshake and before sending
|
|
|
any other message.
|
|
|
</p></dd></dl>
|
|
|
|
|
|
<dl>
|
|
|
<dt><a name="index-send_002drequest"></a>Scheme Procedure: <strong>send-request</strong> <em><var>peer</var> <var>index</var> <var>start</var> <var>len</var></em></dt>
|
|
|
<dd><p>Ask <var>peer</var> for a part of a piece of size <var>len</var>, starting at offset
|
|
|
<var>start</var> in the <var>index</var> piece. A typical value for <var>len</var> is 16384.
|
|
|
<dt><a name="index-send_002drequest"></a>Scheme Procedure: <strong>send-request</strong> <em><var>sock</var> <var>index</var> <var>start</var> <var>len</var></em></dt>
|
|
|
<dd><p>Ask the remote peer on <var>sock</var> for a part of a piece of size <var>len</var>,
|
|
|
starting at offset <var>start</var> in the <var>index</var> piece. A typical value for
|
|
|
<var>len</var> is 16384.
|
|
|
</p></dd></dl>
|
|
|
|
|
|
<dl>
|
|
|
<dt><a name="index-send_002dpiece"></a>Scheme Procedure: <strong>send-piece</strong> <em><var>peer</var> <var>index</var> <var>start</var> <var>block</var></em></dt>
|
|
|
<dd><p>Send a block of data to the <var>peer</var>. This block corresponds to the <var>index</var>
|
|
|
piece at offset <var>start</var>. This should be used after a peer asked us for a
|
|
|
piece.
|
|
|
<dt><a name="index-send_002dpiece"></a>Scheme Procedure: <strong>send-piece</strong> <em><var>sock</var> <var>index</var> <var>start</var> <var>block</var></em></dt>
|
|
|
<dd><p>Send a block of data to the remote peer on <var>sock</var>. This block corresponds
|
|
|
to the <var>index</var> piece at offset <var>start</var>. This should be used after a
|
|
|
peer asked us for a piece.
|
|
|
</p></dd></dl>
|
|
|
|
|
|
<dl>
|
|
|
<dt><a name="index-send_002dcancel"></a>Scheme Procedure: <strong>send-cancel</strong> <em><var>peer</var> <var>index</var> <var>start</var> <var>len</var></em></dt>
|
|
|
<dd><p>Ask the <var>peer</var> to cancel sending the piece to us. The other arguments are
|
|
|
the same as for the <code>send-request</code> procedure.
|
|
|
<dt><a name="index-send_002dcancel"></a>Scheme Procedure: <strong>send-cancel</strong> <em><var>sock</var> <var>index</var> <var>start</var> <var>len</var></em></dt>
|
|
|
<dd><p>Ask the remote peer on <var>sock</var> to cancel sending the piece to us. The other
|
|
|
arguments are the same as for the <code>send-request</code> procedure.
|
|
|
</p></dd></dl>
|
|
|
|
|
|
<dl>
|
|
|
<dt><a name="index-send_002dport"></a>Scheme Procedure: <strong>send-port</strong> <em><var>peer</var> <var>listen-port</var></em></dt>
|
|
|
<dt><a name="index-send_002dport"></a>Scheme Procedure: <strong>send-port</strong> <em><var>sock</var> <var>listen-port</var></em></dt>
|
|
|
<dd><p>Send the <var>listen-port</var> we are listening on for the DHT protocol.
|
|
|
</p></dd></dl>
|
|
|
|
|
|
<dl>
|
|
|
<dt><a name="index-has_003f"></a>Scheme Procedure: <strong>has?</strong> <em><var>bitfield</var> <var>piece</var></em></dt>
|
|
|
<dd><p>If <var>bitfield</var> is a representation of the bitfield of some peer, returns
|
|
|
whether that peer has piece number <var>piece</var>.
|
|
|
</p></dd></dl>
|
|
|
|
|
|
<dl>
|
|
|
<dt><a name="index-has"></a>Scheme Procedure: <strong>has</strong> <em><var>bitfield</var> <var>piece</var></em></dt>
|
|
|
<dd><p>Update <var>bitfield</var> such that it now has the bit corresponding to piece
|
|
|
number <var>piece</var> set.
|
|
|
</p></dd></dl> |