|
|
Note: generate this file with `makeinfo --html --no-split doc/guile-torrent.texi`.
|
|
|
|
|
|
<h2 class="contents-heading">Table of Contents</h2>
|
|
|
|
|
|
<div class="contents">
|
|
|
|
|
|
<ul class="no-bullet">
|
|
|
<li><a name="toc-Encoding-and-decoding-data-1" href="#Encoding-and-decoding-data">1 Encoding and decoding data</a></li>
|
|
|
<li><a name="toc-Managing-_002etorrent-files-1" href="#Managing-_002etorrent-files">2 Managing .torrent files</a></li>
|
|
|
<li><a name="toc-Connecting-to-Trackers-1" href="#Connecting-to-Trackers">3 Connecting to Trackers</a></li>
|
|
|
<li><a name="toc-Sending-and-Receiving-Messages-1" href="#Sending-and-Receiving-Messages">4 Sending and Receiving Messages</a></li>
|
|
|
</ul>
|
|
|
</div>
|
|
|
|
|
|
|
|
|
<a name="Top"></a>
|
|
|
<div class="header">
|
|
|
<p>
|
|
|
Next: <a href="#Encoding-and-decoding-data" accesskey="n" rel="next">Encoding and decoding data</a>, Up: <a href="dir.html#Top" accesskey="u" rel="up">(dir)</a> [<a href="#SEC_Contents" title="Table of contents" rel="contents">Contents</a>]</p>
|
|
|
</div>
|
|
|
<a name="guile_002dtorrent"></a>
|
|
|
<h1 class="top">guile-torrent</h1>
|
|
|
|
|
|
<p>This document describes guile-torrent version 0.1, a guile
|
|
|
implementation of the bittorrent protocol.
|
|
|
</p>
|
|
|
<table class="menu" border="0" cellspacing="0">
|
|
|
<tr><td align="left" valign="top">• <a href="#Encoding-and-decoding-data" accesskey="1">Encoding and decoding data</a>:</td><td> </td><td align="left" valign="top">
|
|
|
</td></tr>
|
|
|
<tr><td align="left" valign="top">• <a href="#Managing-_002etorrent-files" accesskey="2">Managing .torrent files</a>:</td><td> </td><td align="left" valign="top">
|
|
|
</td></tr>
|
|
|
<tr><td align="left" valign="top">• <a href="#Connecting-to-Trackers" accesskey="3">Connecting to Trackers</a>:</td><td> </td><td align="left" valign="top">
|
|
|
</td></tr>
|
|
|
<tr><td align="left" valign="top">• <a href="#Sending-and-Receiving-Messages" accesskey="4">Sending and Receiving Messages</a>:</td><td> </td><td align="left" valign="top">
|
|
|
</td></tr>
|
|
|
</table>
|
|
|
|
|
|
<hr>
|
|
|
<a name="Encoding-and-decoding-data"></a>
|
|
|
<div class="header">
|
|
|
<p>
|
|
|
Next: <a href="#Managing-_002etorrent-files" accesskey="n" rel="next">Managing .torrent files</a>, Previous: <a href="#Top" accesskey="p" rel="prev">Top</a>, Up: <a href="#Top" accesskey="u" rel="up">Top</a> [<a href="#SEC_Contents" title="Table of contents" rel="contents">Contents</a>]</p>
|
|
|
</div>
|
|
|
<a name="Encoding-and-decoding-data-1"></a>
|
|
|
<h2 class="chapter">1 Encoding and decoding data</h2>
|
|
|
|
|
|
<p>Some parts of the bittorrent protocol use the <em>bencoding</em> for data
|
|
|
representation. This encoding is implemented in the <code>(torrent bencoding)</code>
|
|
|
module. This module consists of a record type and two public procedures:
|
|
|
</p>
|
|
|
<dl>
|
|
|
<dt><a name="index-dictionnary"></a>Data Type: <strong>dictionnary</strong></dt>
|
|
|
<dd><p>This data type represents a dictionnary. A dictionnary is a datastructure
|
|
|
that associates values to keys. This field contains only one element,
|
|
|
<code>alist</code>, a association list.
|
|
|
</p>
|
|
|
<dl>
|
|
|
<dt><a name="index-dictionnary_002dalist"></a>Scheme Procedure: <strong>dictionnary-alist</strong> <em><var>dictionnary</var></em></dt>
|
|
|
<dd><p>This procedure returns the actual association list contains in a dictionnary.
|
|
|
</p></dd></dl>
|
|
|
</dd></dl>
|
|
|
|
|
|
<dl>
|
|
|
<dt><a name="index-bencode"></a>Scheme Procedure: <strong>bencode</strong> <em><var>data</var></em></dt>
|
|
|
<dd><p>This procedure takes <var>data</var> and returns a <code>bytevector</code> corresponding
|
|
|
to the bencoded <var>data</var>. The data can be a <code>bytevector</code>, a <code>string</code>,
|
|
|
an <code>integer</code>, a <code>list</code> or a <code>dictionnary</code>.
|
|
|
</p></dd></dl>
|
|
|
|
|
|
<dl>
|
|
|
<dt><a name="index-bdecode"></a>Scheme Procedure: <strong>bdecode</strong> <em><var>port</var></em></dt>
|
|
|
<dd><p>This procedure takes <var>port</var> and reads data from it. After it reaches
|
|
|
<code>#eof</code>, this procedure returns the data corresponding to what it read in
|
|
|
the bencoding. The result can be a <code>dictionnary</code>, a <code>list</code>,
|
|
|
a <code>bytevector</code> or an <code>integer</code> depending on the data that has been
|
|
|
read.
|
|
|
</p></dd></dl>
|
|
|
|
|
|
<hr>
|
|
|
<a name="Managing-_002etorrent-files"></a>
|
|
|
<div class="header">
|
|
|
<p>
|
|
|
Next: <a href="#Connecting-to-Trackers" accesskey="n" rel="next">Connecting to Trackers</a>, Previous: <a href="#Encoding-and-decoding-data" accesskey="p" rel="prev">Encoding and decoding data</a>, Up: <a href="#Top" accesskey="u" rel="up">Top</a> [<a href="#SEC_Contents" title="Table of contents" rel="contents">Contents</a>]</p>
|
|
|
</div>
|
|
|
<a name="Managing-_002etorrent-files-1"></a>
|
|
|
<h2 class="chapter">2 Managing .torrent files</h2>
|
|
|
|
|
|
<p>One of the ways to get torrent informations is by loading a <samp>.torrent</samp> file.
|
|
|
The file contains many useful information, including announce URLs to wich
|
|
|
the bittorrent client can ask for more peers regularly, the hash of each piece,
|
|
|
their size and the list of files contained in the torrent.
|
|
|
</p>
|
|
|
<a name="index-infohash"></a>
|
|
|
<p>From this, we can derive the <em>infohash</em> which is a <code>sha-1</code> hash of a
|
|
|
part of that file and corresponds to the identifier of the torrent.
|
|
|
</p>
|
|
|
<p>Although there are multiple methods to get peers for a torrent, they all require
|
|
|
the infohash of the torrent before you can start asking for peers. The infohash
|
|
|
itself can come either from the <samp>.torrent</samp> file as seen in this section
|
|
|
or a <code>magnet://</code> URL. The content of this URL is actually the hexadecimal
|
|
|
representation of the infohash.
|
|
|
</p>
|
|
|
<p>The <code>(torrent metainfo)</code> module is responsible for parsing <samp>.torrent</samp>
|
|
|
files. This module contains the following definitions:
|
|
|
</p>
|
|
|
<dl>
|
|
|
<dt><a name="index-metainfo"></a>Data Type: <strong>metainfo</strong></dt>
|
|
|
<dd><p>This data type represents the necessary information contained in the <samp>.torrent</samp>
|
|
|
file.
|
|
|
</p>
|
|
|
<dl compact="compact">
|
|
|
<dt><code>info</code></dt>
|
|
|
<dd><p>The info section of the <samp>.torrent</samp> file.
|
|
|
</p>
|
|
|
</dd>
|
|
|
<dt><code>annouce</code></dt>
|
|
|
<dd><p>A string containing the address of the main announce URL for this torrent.
|
|
|
</p>
|
|
|
</dd>
|
|
|
<dt><code>infohash</code></dt>
|
|
|
<dd><p>A bytevector representing the infohash of this file.
|
|
|
</p>
|
|
|
</dd>
|
|
|
</dl>
|
|
|
</dd></dl>
|
|
|
|
|
|
<dl>
|
|
|
<dt><a name="index-torrent_002dinfo"></a>Data Type: <strong>torrent-info</strong></dt>
|
|
|
<dd><p>This data type represents the necessary infomation contained in the <code>info</code>
|
|
|
section of the <samp>.torrent</samp> file.
|
|
|
</p>
|
|
|
<dl compact="compact">
|
|
|
<dt>piece-length</dt>
|
|
|
<dd><p>A number representing the number of bytes of each piece
|
|
|
</p>
|
|
|
</dd>
|
|
|
<dt>pieces</dt>
|
|
|
<dd><p>A bytevector representing the concatenation of each piece’s <code>sha-1</code> hash.
|
|
|
This information is useful to independently check each piece’s integrity.
|
|
|
</p>
|
|
|
</dd>
|
|
|
<dt>private?</dt>
|
|
|
<dd><p>A boolean indicating whether this torrent is private i.e. whether the client
|
|
|
must only use the trackers present in the file or if it can use other means
|
|
|
such as the peer exchange protocol.
|
|
|
</p>
|
|
|
</dd>
|
|
|
<dt>single-file?</dt>
|
|
|
<dd><p>A boolean indicating whether this torrent contains a single file.
|
|
|
</p>
|
|
|
</dd>
|
|
|
<dt>name</dt>
|
|
|
<dd><p>A string containing the name of the torrent. In single-file mode, this
|
|
|
corresponds to the filename. In multiple-file mode, this corresponds to the
|
|
|
name of the folder containing the files.
|
|
|
</p>
|
|
|
</dd>
|
|
|
<dt>len</dt>
|
|
|
<dd><p>In single-file mode, a number representing the size of the file in bytes. In
|
|
|
multiple-files mode, <code>#f</code>.
|
|
|
</p>
|
|
|
</dd>
|
|
|
<dt>files</dt>
|
|
|
<dd><p>In single-file mode, <code>#f</code>. In multiple-files mode, a list of
|
|
|
<code>torrent-info-file</code> objects representing the content of the torrent.
|
|
|
</p>
|
|
|
</dd>
|
|
|
</dl>
|
|
|
</dd></dl>
|
|
|
|
|
|
<dl>
|
|
|
<dt><a name="index-torrent_002dinfo_002dfile"></a>Data Type: <strong>torrent-info-file</strong></dt>
|
|
|
<dd><p>This data type represents the necessary information to describe a file from
|
|
|
a torrent.
|
|
|
</p>
|
|
|
<dl compact="compact">
|
|
|
<dt>len</dt>
|
|
|
<dd><p>A number representing the size of the file in bytes.
|
|
|
</p>
|
|
|
</dd>
|
|
|
<dt>path</dt>
|
|
|
<dd><p>A list of strings representing the path to the file from the top-level directory
|
|
|
of the torrent.
|
|
|
</p>
|
|
|
</dd>
|
|
|
</dl>
|
|
|
</dd></dl>
|
|
|
|
|
|
<p>This module also defines the following procedure:
|
|
|
</p>
|
|
|
<dl>
|
|
|
<dt><a name="index-parse_002dtorrent_002dfile"></a>Scheme Procedure: <strong>parse-torrent-file</strong> <em><var>file</var></em></dt>
|
|
|
<dd><p>This procedure parses a <samp>.torrent</samp> file whose name is contained in <var>file</var>
|
|
|
and returns a <code>metainfo</code> object containing the necessary information in
|
|
|
that file.
|
|
|
</p></dd></dl>
|
|
|
|
|
|
<hr>
|
|
|
<a name="Connecting-to-Trackers"></a>
|
|
|
<div class="header">
|
|
|
<p>
|
|
|
Next: <a href="#Sending-and-Receiving-Messages" accesskey="n" rel="next">Sending and Receiving Messages</a>, Previous: <a href="#Managing-_002etorrent-files" accesskey="p" rel="prev">Managing .torrent files</a>, Up: <a href="#Top" accesskey="u" rel="up">Top</a> [<a href="#SEC_Contents" title="Table of contents" rel="contents">Contents</a>]</p>
|
|
|
</div>
|
|
|
<a name="Connecting-to-Trackers-1"></a>
|
|
|
<h2 class="chapter">3 Connecting to Trackers</h2>
|
|
|
|
|
|
<p>The <code>(torrent tracker)</code> module contains definitions and procedures that
|
|
|
deal with connecting to a tracker and getting information.
|
|
|
</p>
|
|
|
<dl>
|
|
|
<dt><a name="index-tracker"></a>Data Type: <strong>tracker</strong></dt>
|
|
|
<dd><dl compact="compact">
|
|
|
<dt>host</dt>
|
|
|
<dd><p>A string representing the host name of the tracker.
|
|
|
</p>
|
|
|
</dd>
|
|
|
<dt>page</dt>
|
|
|
<dd><p>A string representing the path to the annouce page. e.g. <code>"/announce"</code>
|
|
|
</p>
|
|
|
</dd>
|
|
|
<dt>proto</dt>
|
|
|
<dd><p>A string representing the protocol used to connect to the tracker. e.g.
|
|
|
<code>"http"</code>.
|
|
|
</p>
|
|
|
</dd>
|
|
|
<dt>port</dt>
|
|
|
<dd><p>A number representing the port of the tracker, or <code>#f</code> to use the standard
|
|
|
port for the protocol.
|
|
|
</p>
|
|
|
</dd>
|
|
|
<dt>infohash</dt>
|
|
|
<dd><p>The infohash of the torrent we are interested in, represented by a bytevector.
|
|
|
</p>
|
|
|
</dd>
|
|
|
<dt>state</dt>
|
|
|
<dd><p>The current state of this session:
|
|
|
</p>
|
|
|
<ul>
|
|
|
<li> <code>'start</code> indicates that we still haven’t connected to the tracker
|
|
|
during this session;
|
|
|
</li><li> <code>'complete</code> indicates that we have completed the download but haven’t
|
|
|
told the tracker yet;
|
|
|
</li><li> <code>'stop</code> indicates that we are about to stop, but we haven’t told the
|
|
|
server yet;
|
|
|
</li><li> <code>'running</code> indicates that we are operating normally.
|
|
|
</li></ul>
|
|
|
|
|
|
</dd>
|
|
|
<dt>uploaded</dt>
|
|
|
<dd><p>The number of bytes that we have uploaded during this session.
|
|
|
</p>
|
|
|
</dd>
|
|
|
<dt>downloaded</dt>
|
|
|
<dd><p>The number of bytes that we have downloaded during this session.
|
|
|
</p>
|
|
|
</dd>
|
|
|
<dt>left</dt>
|
|
|
<dd><p>The number of bytes left that we need to download.
|
|
|
</p>
|
|
|
</dd>
|
|
|
<dt>id</dt>
|
|
|
<dd><p>The tracker id or <code>#f</code> if the tracker didn’t send us its tracker id.
|
|
|
</p></dd>
|
|
|
</dl>
|
|
|
</dd></dl>
|
|
|
|
|
|
<dl>
|
|
|
<dt><a name="index-tracker_002dresponse"></a>Data Type: <strong>tracker-response</strong></dt>
|
|
|
<dd><dl compact="compact">
|
|
|
<dt>failure-reason</dt>
|
|
|
<dd><p>When an error occured, a string containing the reason of the failure. Otherwise
|
|
|
<code>#f</code>. If this field is set, no other field can be considered valid.
|
|
|
</p>
|
|
|
</dd>
|
|
|
<dt>warning-message</dt>
|
|
|
<dd><p>When a warning is issued by the tracker, a string containing the content of
|
|
|
the warning. Otherwise <code>#f</code>.
|
|
|
</p>
|
|
|
</dd>
|
|
|
<dt>interval</dt>
|
|
|
<dd><p>A number representing the interval in seconds at which the tracker would want us
|
|
|
to ask for more peers.
|
|
|
</p>
|
|
|
</dd>
|
|
|
<dt>min-interval</dt>
|
|
|
<dd><p>A number representing the minimum interval in seconds the tracker wants us to
|
|
|
respect between two requests.
|
|
|
</p>
|
|
|
</dd>
|
|
|
<dt>tracker-id</dt>
|
|
|
<dd><p>A string containing the tracker id. If no tracker id is given by the tracker,
|
|
|
<code>#f</code>. Otherwise, this value should be saved for future requests in the
|
|
|
<code>id</code> field of the <code>tracker</code> object.
|
|
|
</p>
|
|
|
</dd>
|
|
|
<dt>complete</dt>
|
|
|
<dd><p>The number of peers the tracker knows of that have finished downloading the
|
|
|
torrent.
|
|
|
</p>
|
|
|
</dd>
|
|
|
<dt>incomplete</dt>
|
|
|
<dd><p>The number of peers the tracker knows of that have not yet finished downloading
|
|
|
the torrent.
|
|
|
</p>
|
|
|
</dd>
|
|
|
<dt>peers</dt>
|
|
|
<dd><p>A list of peers, each represented by an association list containing two fields:
|
|
|
<code>"host"</code> and <code>"port"</code>. The value of these fields are integers.
|
|
|
</p>
|
|
|
</dd>
|
|
|
</dl>
|
|
|
</dd></dl>
|
|
|
|
|
|
<dl>
|
|
|
<dt><a name="index-uri_002dproto"></a>Scheme Procedure: <strong>uri-proto</strong> <em><var>uri</var></em></dt>
|
|
|
<dd><p>Returns the protocol part of the <var>uri</var>, e.g. <code>"http"</code>.
|
|
|
</p></dd></dl>
|
|
|
<dl>
|
|
|
<dt><a name="index-uri_002dhost"></a>Scheme Procedure: <strong>uri-host</strong> <em><var>uri</var></em></dt>
|
|
|
<dd><p>Returns the host part of the <var>uri</var>.
|
|
|
</p></dd></dl>
|
|
|
<dl>
|
|
|
<dt><a name="index-uri_002dport"></a>Scheme Procedure: <strong>uri-port</strong> <em><var>uri</var></em></dt>
|
|
|
<dd><p>Returns the port part of the <var>uri</var> as a number or <code>#f</code> if it is not
|
|
|
specified in the <var>uri</var>.
|
|
|
</p></dd></dl>
|
|
|
<dl>
|
|
|
<dt><a name="index-uri_002dpage"></a>Scheme Procedure: <strong>uri-page</strong> <em><var>uri</var></em></dt>
|
|
|
<dd><p>Returns the path part of the <var>uri</var>.
|
|
|
</p></dd></dl>
|
|
|
|
|
|
|
|
|
<dl>
|
|
|
<dt><a name="index-url_002dencode"></a>Scheme Procedure: <strong>url-encode</strong> <em><var>bv</var></em></dt>
|
|
|
<dd><p>This procedure takes a bytevector and returns the url-encoded value equivalent
|
|
|
to the content of the bytevector. This works by using the <code>%xx</code> encoding
|
|
|
for each character that cannot appear in a url.
|
|
|
</p></dd></dl>
|
|
|
|
|
|
<dl>
|
|
|
<dt><a name="index-ask_002dmore_002dpeers"></a>Scheme Procedure: <strong>ask-more-peers</strong> <em><var>tracker</var> <var>peerid</var> <var>port</var></em></dt>
|
|
|
<dd><p>This procedure will ask <var>tracker</var> for more peers. <var>peerid</var> and <var>port</var>
|
|
|
must contain respectively the peer id and port of our client. This makes a
|
|
|
request to the tracker and returns a <code>tracker-response</code> object in case
|
|
|
of success or a simple string containing the body of the response in case of
|
|
|
error.
|
|
|
</p></dd></dl>
|
|
|
|
|
|
<dl>
|
|
|
<dt><a name="index-get_002dnew_002dtracker"></a>Scheme Procedure: <strong>get-new-tracker</strong> <em><var>uri</var> <var>infohash</var> <var>left</var></em></dt>
|
|
|
<dd><p>This method can be used to initialize all the fields of a new <code>tracker</code>
|
|
|
object. It returns this new <code>tracker</code> object.
|
|
|
</p></dd></dl>
|
|
|
|
|
|
<hr>
|
|
|
<a name="Sending-and-Receiving-Messages"></a>
|
|
|
<div class="header">
|
|
|
<p>
|
|
|
Previous: <a href="#Connecting-to-Trackers" accesskey="p" rel="prev">Connecting to Trackers</a>, Up: <a href="#Top" accesskey="u" rel="up">Top</a> [<a href="#SEC_Contents" title="Table of contents" rel="contents">Contents</a>]</p>
|
|
|
</div>
|
|
|
<a name="Sending-and-Receiving-Messages-1"></a>
|
|
|
<h2 class="chapter">4 Sending and Receiving Messages</h2>
|
|
|
|
|
|
<p>The <code>(torrent protocol)</code> module is responsible for handling protocol
|
|
|
messages and connecting to peers.
|
|
|
</p>
|
|
|
<dl>
|
|
|
<dt><a name="index-peer"></a>Data Type: <strong>peer</strong></dt>
|
|
|
<dd><p>This data type represents a peer in the bittorrent protocol. A peer is another
|
|
|
client running the bittorrent protocol that either has the file we are interested
|
|
|
in or is interested in the file. This record type has the following fields:
|
|
|
</p>
|
|
|
<dl compact="compact">
|
|
|
<dt>id</dt>
|
|
|
<dd><p>A 20-bytes bytevector holding the peer-id of the remote peer.
|
|
|
</p>
|
|
|
</dd>
|
|
|
<dt>sock</dt>
|
|
|
<dd><p>The socket through which to communicate with the 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.
|
|
|
</p>
|
|
|
</dd>
|
|
|
<dt>interested</dt>
|
|
|
<dd><p>A boolean indicating whether the remote peer is interested by what we have. If
|
|
|
we wante to send it data, we should unchok it first.
|
|
|
</p>
|
|
|
</dd>
|
|
|
<dt>am-choking</dt>
|
|
|
<dd><p>A boolean indicating whether we are choking the remote peer. While we are
|
|
|
choking it, it shouldn’t ask
|
|
|
</p>
|
|
|
</dd>
|
|
|
<dt>am-interested</dt>
|
|
|
<dd><p>A boolean indicating whether we told the remote peer we were interested. The
|
|
|
remote peer will not likely unchoke us unless it is aware we are interested.
|
|
|
</p>
|
|
|
</dd>
|
|
|
</dl>
|
|
|
</dd></dl>
|
|
|
|
|
|
|
|
|
<dl>
|
|
|
<dt><a name="index-generate_002did"></a>Scheme Procedure: <strong>generate-id</strong></dt>
|
|
|
<dd><p>This procedure generates a 20-bytes peer-id.
|
|
|
</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).
|
|
|
</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
|
|
|
with the <var>infohash</var> we are interested in. If the handshake is valid, returns
|
|
|
an updated <code>peer</code> object.
|
|
|
</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>
|
|
|
|
|
|
<dl>
|
|
|
<dt><a name="index-send_002dkeep_002dalive"></a>Scheme Procedure: <strong>send-keep-alive</strong> <em><var>peer</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.
|
|
|
</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.
|
|
|
</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.
|
|
|
</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.
|
|
|
</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.
|
|
|
</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.
|
|
|
</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.
|
|
|
</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.
|
|
|
</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.
|
|
|
</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>
|
|
|
<dd><p>Send the <var>listen-port</var> we are listening on for the DHT protocol.
|
|
|
</p></dd></dl> |