Commit bb39949b authored by Julien Lepiller's avatar Julien Lepiller

torrent: Protocol interface returns alists.

* torrent/protocol.scm (receive-message): Return an alist instead of
nothing.
(receive-handshake): Return the remote peer ID instead of a peer object.
(send-*): Use a socket instead of a peer object.
parent be36ad02
......@@ -356,78 +356,109 @@ returns a new peer object. The @code{id} field is filled with the value of
the optional argument @var{id}.
@end deffn
@deffn {Scheme Procedure} send-handshake @var{peer} @var{infohash} @var{self-id}
This procedure sends a handshake message to @var{peer}. The handshake must be
the first message sent to the peer. It specifies the @var{infohash} and our
@var{self-id} (peer id).
@deffn {Scheme Procedure} send-handshake @var{sock} @var{infohash} @var{self-id}
This procedure sends a handshake message to @var{sock}, a peer socket. The
handshake must be the first message sent to the peer. It specifies the
@var{infohash} and our @var{self-id} (peer id).
@end deffn
@deffn {Scheme Procedure} receive-handshake @var{peer} @var{infohash}
This procedure waits for the handshake of the @var{peer} and compares its content
@deffn {Scheme Procedure} receive-handshake @var{sock} @var{infohash}
This procedure waits for the handshake on @var{sock} and compares its content
with the @var{infohash} we are interested in. If the handshake is valid, returns
an updated @code{peer} object.
the remote @code{peer-id} object associated to the connection, i.e.@: the peer
id of the remote peer. Otherwise, returns @code{#f}.
@end deffn
@deffn {Scheme Procedure} receive-message @var{peer}
This procedure waits for a message from the @var{peer} and decodes it. If it
is a valid message, returns an updated @code{peer} object. It prints the
message and its content to the standard output.
@deffn {Scheme Procedure} receive-message @var{sock}
This procedure waits for a message on @var{sock} and decodes it. If it is an
invalid message, returns @code{#f} or throws an exception. Otherwise it returns
a symbol or an association list corresponding to the message that was received.
The bittorrent protocol specifies these messages:
@itemize
@item @code{'keep-alive}
@item @code{'choke}
@item @code{'unchoke}
@item @code{'interested}
@item @code{'not-interested}
@item @code{(("type" 'have) ("piece" @var{piece-num}))}
@item @code{(("type" 'bitfield) ("bitfield" @var{bitfield}))}
@item @code{(("type" 'request) ("index" @var{index}) ("start" @var{start})
("len" @var{len}))}
@item @code{(("type" 'piece) ("index" @var{index}) ("start" @var{start})
("block" @var{block}))}
@item @code{(("type" 'cancel) ("index" @var{index}) ("start" @var{start})
("len" @var{len}))}
@item @code{(("type" 'port) ("port" @var{port}))}
@end itemize
@end deffn
@deffn {Scheme Procedure} send-keep-alive @var{peer}
@deffn {Scheme Procedure} send-keep-alive @var{sock}
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.
@end deffn
@deffn {Sceme Procedure} send-choke @var{peer}
This procedure sends a message to choke the remote @var{peer}. It should not
ask us for pieces anymore.
@deffn {Sceme Procedure} send-choke @var{sock}
This procedure sends a message to choke the remote peer on @var{sock}. It
should not ask us for pieces anymore.
@end deffn
@deffn {Scheme Procedure} send-unchoke @var{peer}
This procedure send a message to unchoke the remote @var{peer}. It can now
request pieces from us.
@deffn {Scheme Procedure} send-unchoke @var{sock}
This procedure send a message to unchoke the remote peer on @var{sock}. It can
now request pieces from us.
@end deffn
@deffn {Scheme Procedure} send-interested @var{peer}
Tell the remote @var{peer} we are interested.
@deffn {Scheme Procedure} send-interested @var{sock}
Tell the remote peer on @var{sock} we are interested.
@end deffn
@deffn {Scheme Procedure} send-not-interested @var{peer}
Tell the remote @var{peer} we are not interested.
@deffn {Scheme Procedure} send-not-interested @var{sock}
Tell the remote peer on @var{sock} we are not interested.
@end deffn
@deffn {Scheme Procedure} send-have @var{peer} @var{piece}
Notify the @var{peer} we have completed download of @var{piece}, the zero-based
index of the piece.
@deffn {Scheme Procedure} send-have @var{sock} @var{piece}
Notify the remote peer on @var{sock} we have completed download of @var{piece},
the zero-based index of the piece. It doesn't need to be a piece downloaded
from that peer.
@end deffn
@deffn {Scheme Procedure} send-bitfield @var{peer} @var{bitfield}
Send a @var{bitfield} to the @var{peer} 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.
@deffn {Scheme Procedure} send-bitfield @var{sock} @var{bitfield}
Send a @var{bitfield} to the remote peer on @var{sock} 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.
@end deffn
@deffn {Scheme Procedure} send-request @var{peer} @var{index} @var{start} @var{len}
Ask @var{peer} for a part of a piece of size @var{len}, starting at offset
@var{start} in the @var{index} piece. A typical value for @var{len} is 16384.
@deffn {Scheme Procedure} send-request @var{sock} @var{index} @var{start} @var{len}
Ask the remote peer on @var{sock} for a part of a piece of size @var{len},
starting at offset @var{start} in the @var{index} piece. A typical value for
@var{len} is 16384.
@end deffn
@deffn {Scheme Procedure} send-piece @var{peer} @var{index} @var{start} @var{block}
Send a block of data to the @var{peer}. This block corresponds to the @var{index}
piece at offset @var{start}. This should be used after a peer asked us for a
piece.
@deffn {Scheme Procedure} send-piece @var{sock} @var{index} @var{start} @var{block}
Send a block of data to the remote peer on @var{sock}. This block corresponds
to the @var{index} piece at offset @var{start}. This should be used after a
peer asked us for a piece.
@end deffn
@deffn {Scheme Procedure} send-cancel @var{peer} @var{index} @var{start} @var{len}
Ask the @var{peer} to cancel sending the piece to us. The other arguments are
the same as for the @code{send-request} procedure.
@deffn {Scheme Procedure} send-cancel @var{sock} @var{index} @var{start} @var{len}
Ask the remote peer on @var{sock} to cancel sending the piece to us. The other
arguments are the same as for the @code{send-request} procedure.
@end deffn
@deffn {Scheme Procedure} send-port @var{peer} @var{listen-port}
@deffn {Scheme Procedure} send-port @var{sock} @var{listen-port}
Send the @var{listen-port} we are listening on for the DHT protocol.
@end deffn
@deffn {Scheme Procedure} has? @var{bitfield} @var{piece}
If @var{bitfield} is a representation of the bitfield of some peer, returns
whether that peer has piece number @var{piece}.
@end deffn
@deffn {Scheme Procedure} has @var{bitfield} @var{piece}
Update @var{bitfield} such that it now has the bit corresponding to piece
number @var{piece} set.
@end deffn
@bye
This diff is collapsed.
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment