forked from I2P_Developers/i2p.www
more SAMv3 cleanups
This commit is contained in:
@@ -98,7 +98,7 @@ is associated with one of the three types above, and cannot carry
|
||||
communications of another type.
|
||||
</p>
|
||||
|
||||
<h3>SAM connection handshake</h3>
|
||||
<h3>SAM Connection Handshake</h3>
|
||||
<p>
|
||||
No SAM communication can occur until after the client and bridge have
|
||||
agreed on a protocol version, which is done by the client sending
|
||||
@@ -126,7 +126,7 @@ If some error occurred, such as a bad request format, it replies with :
|
||||
</pre>
|
||||
</p>
|
||||
|
||||
<h3>SAM sessions</h3>
|
||||
<h3>SAM Sessions</h3>
|
||||
<p>
|
||||
A SAM session is created by a client opening a socket to the SAM
|
||||
bridge, operating a handshake, and sending a SESSION CREATE message,
|
||||
@@ -243,7 +243,7 @@ the session dies for any reason, the SAM bridge closes the socket.
|
||||
</p>
|
||||
|
||||
|
||||
<h3>SAM virtual streams</h3>
|
||||
<h3>SAM Virtual Streams</h3>
|
||||
<p>
|
||||
Virtual streams are guaranteed to be sent reliably and in order, with
|
||||
failure and success notification as soon as it is available.
|
||||
@@ -257,7 +257,7 @@ he wants to listen to requests coming from other I2P destinations.
|
||||
</p>
|
||||
|
||||
|
||||
<h3>SAM virtual streams : CONNECT</h3>
|
||||
<h3>SAM Virtual Streams : CONNECT</h3>
|
||||
<p>
|
||||
A client asks for a connection by :
|
||||
<ul><li>
|
||||
@@ -323,7 +323,7 @@ optional human-readable MESSAGE), and the SAM bridge closes the
|
||||
socket.
|
||||
</p>
|
||||
|
||||
<h3>SAM virtual streams : ACCEPT</h3>
|
||||
<h3>SAM Virtual Streams : ACCEPT</h3>
|
||||
<p>
|
||||
A client waits for an incoming connection request by :
|
||||
<ul><li>
|
||||
@@ -382,7 +382,7 @@ passing through the current socket is forwarded from and to the connected
|
||||
I2P destination peer, until one of the peer closes the socket.
|
||||
</p>
|
||||
|
||||
<h3>SAM virtual streams : FORWARD</h3>
|
||||
<h3>SAM Virtual Streams : FORWARD</h3>
|
||||
<p>
|
||||
A client can use a regular socket server and wait for connection requests
|
||||
coming from I2P. For that, the client has to :
|
||||
@@ -392,7 +392,7 @@ open a new socket with the SAM bridge
|
||||
pass the same HELLO handshake as above
|
||||
</li><li>
|
||||
send the forward command :
|
||||
</ul><li>
|
||||
</ul></li>
|
||||
|
||||
<pre>
|
||||
-> STREAM FORWARD
|
||||
@@ -460,7 +460,7 @@ soon as the "forwarding" socket is closed.
|
||||
|
||||
|
||||
|
||||
<h3>SAM repliable datagrams : sending a datagram</h3>
|
||||
<h3>SAM Repliable Datagrams : Sending a Datagram</h3>
|
||||
<p>
|
||||
While I2P doesn't inherently contain a FROM address, for ease of use
|
||||
an additional layer is provided as repliable datagrams - unordered
|
||||
@@ -488,7 +488,7 @@ following format :
|
||||
<ul><li>
|
||||
3.0 is the version of SAM
|
||||
</li><li>
|
||||
$nickname is the id of the DGRAM session that will be used
|
||||
$nickname is the id of the DATAGRAM session that will be used
|
||||
</li><li>
|
||||
The target is $destination, which is the base 64 of the <a href="{{ site_url('docs/spec/common-structures') }}#type_Destination">Destination</a>,
|
||||
which is 516 or more base 64 characters (387 or more bytes in binary),
|
||||
@@ -505,7 +505,7 @@ of the message to the specified destination.
|
||||
For an alternate method of sending repliable datagrams, see <a href="#dgsend">DATAGRAM SEND</a>.
|
||||
</p>
|
||||
|
||||
<h3>SAM repliable datagrams : receiving a datagram</h3>
|
||||
<h3>SAM Repliable Datagrams : Receiving a Datagram</h3>
|
||||
<p>
|
||||
Received datagrams are written by SAM on the socket from which the
|
||||
datagram session was opened, unless specified otherwise by the CREATE
|
||||
@@ -532,7 +532,7 @@ or other fields, merely the data that the sender provided. This
|
||||
continues until the session is closed (by the client dropping the
|
||||
connection).
|
||||
|
||||
<h3>SAM repliable datagrams : forwarding datagrams</h3>
|
||||
<h3>SAM Repliable Datagrams : Forwarding Datagrams</h3>
|
||||
<p>
|
||||
When creating a datagram session, the client can ask SAM to forward
|
||||
incoming messages to a specified ip:port. It does so by issuing the
|
||||
@@ -587,7 +587,7 @@ depending on signature type.
|
||||
</p>
|
||||
|
||||
|
||||
<h3>SAM anonymous datagrams</h3>
|
||||
<h3>SAM Anonymous Datagrams</h3>
|
||||
<p>
|
||||
Squeezing the most out of I2P's bandwidth, SAM allows clients to send
|
||||
and receive anonymous datagrams, leaving authentication and reply
|
||||
@@ -648,7 +648,7 @@ as appropriate. Support for the ID parameter may be added in a future release.
|
||||
|
||||
|
||||
|
||||
<h3>SAM utility functionality</h3>
|
||||
<h3>SAM Utility Commands/h3>
|
||||
<p>
|
||||
The following message can be used by the client to query the SAM
|
||||
bridge for name resolution:
|
||||
@@ -658,6 +658,7 @@ bridge for name resolution:
|
||||
NAME=$name
|
||||
</pre>
|
||||
|
||||
</p><p>
|
||||
which is answered by
|
||||
|
||||
<pre>
|
||||
@@ -726,7 +727,7 @@ which is 884 or more base 64 characters (663 or more bytes in binary),
|
||||
depending on signature type.
|
||||
The binary format is specified in <a href="http://docs.i2p-projekt.de/javadoc/net/i2p/data/PrivateKeyFile.html">Private Key File</a>.
|
||||
|
||||
<h3>RESULT values</h3>
|
||||
<h3>RESULT Values</h3>
|
||||
<p>
|
||||
These are the values that can be carried by the RESULT field, with
|
||||
their meaning:
|
||||
@@ -760,7 +761,7 @@ See those references for option names and defaults.
|
||||
Base 64 encoding must use the I2P standard Base 64 alphabet "A-Z, a-z, 0-9, -, ~".
|
||||
</p>
|
||||
|
||||
<h3>Client library implementations</h3>
|
||||
<h3>Client Library Implementations</h3>
|
||||
<p>
|
||||
Client libraries are available for C, C++, C#, Perl, and Python.
|
||||
These are in the apps/sam/ directory in the <a href="{{ get_url('downloads_list') }}">I2P Source Package</a>.
|
||||
|
Reference in New Issue
Block a user