diff --git a/i2p2www/pages/site/docs/api/samv3.html b/i2p2www/pages/site/docs/api/samv3.html index 60f6f53f..ec1d76e0 100644 --- a/i2p2www/pages/site/docs/api/samv3.html +++ b/i2p2www/pages/site/docs/api/samv3.html @@ -170,11 +170,11 @@ As of version 3.1 (I2P 0.9.14), the MIN and MAX parameters are optional. SAM will always return the highest version possible given the MIN and MAX constraints, or 3.1 if no constraints are given. -If the SAM bridge cannot find a suitable version, it replies with : +If the SAM bridge cannot find a suitable version, it replies with:
<- HELLO REPLY RESULT=NOVERSION-If some error occurred, such as a bad request format, it replies with : +If some error occurred, such as a bad request format, it replies with:
<- HELLO REPLY RESULT=I2P_ERROR MESSAGE=$message@@ -191,7 +191,7 @@ Each registered I2P Destination is uniquely associated with a session ID (or nickname).
-Each session is uniquely associated with : +Each session is uniquely associated with:
-If the creation was successful : +If the creation was successful:
<- SESSION STATUS RESULT=OK DESTINATION=$privkey@@ -261,25 +261,25 @@ depending on signature type. The binary format is specified in Private Key File.
-If the nickname is already associated with a session : +If the nickname is already associated with a session:
<- SESSION STATUS RESULT=DUPLICATED_ID
-If the destination is already in use : +If the destination is already in use:
<- SESSION STATUS RESULT=DUPLICATED_DEST
-If the destination is not a valid private destination key : +If the destination is not a valid private destination key:
<- SESSION STATUS RESULT=INVALID_KEY
-If some other error has occurred : +If some other error has occurred:
<- SESSION STATUS RESULT=I2P_ERROR MESSAGE=$message@@ -313,13 +313,13 @@ he wants to listen to requests coming from other I2P destinations.
-A client asks for a connection by : +A client asks for a connection by:
@@ -340,7 +340,7 @@ depending on signature type.If SILENT=true is passed, the SAM bridge won't issue any other message -on the socket : if the connection fails, the socket will be closed. +on the socket. If the connection fails, the socket will be closed. If the connection succeeds, all remaining data passing through the current socket is forwarded from and to the connected I2P destination peer. @@ -348,7 +348,7 @@ peer.
If SILENT=false, which is the default value, the SAM bridge sends a last message to its client before forwarding or shutting down the -socket : +socket:
<- STREAM STATUS @@ -379,13 +379,13 @@ socket.SAM Virtual Streams : ACCEPT
-A client waits for an incoming connection request by : +A client waits for an incoming connection request by:
@@ -399,7 +399,18 @@ This makes the session ${nickname} listen for one incoming connection request from the I2P network.-The SAM bridge answers with : +If SILENT=true is passed, the SAM bridge won't issue any other message +on the socket. If the accept fails, the socket will be closed. +If the accept succeeds, all remaining data passing through the +current socket is forwarded from and to the connected I2P destination +peer. +For reliability, and to receive the destination for incoming connections, +SILENT=false is recommended. + + +
+If SILENT=false, which is the default value, +the SAM bridge answers with:
<- STREAM STATUS @@ -420,11 +431,11 @@ The RESULT value may be one of: If the result is not OK, the socket is closed immediately by the SAM bridge. If the result is OK, the SAM bridge starts waiting for an incoming connection request from another I2P peer. When a request -arrives, the SAM bridge accepts it and : +arrives, the SAM bridge accepts it and:If SILENT=true was passed, the SAM bridge won't issue any other message -on the client socket : all remaining data passing through the +on the client socket. All remaining data passing through the current socket is forwarded from and to the connected I2P destination peer. @@ -439,13 +450,13 @@ I2P destination peer, until one of the peer closes the socket.
SAM Virtual Streams : FORWARD
A client can use a regular socket server and wait for connection requests -coming from I2P. For that, the client has to : +coming from I2P. For that, the client must:
@@ -461,7 +472,12 @@ This makes the session ${nickname} listen for incoming connection requests from the I2P network.-The SAM bridge answers with : +SILENT defaults to false. +Whether SILENT is true or false, +the SAM bridge always answers with a STREAM STATUS message. +Note that this is a different behavior from STREAM ACCEPT and STREAM CONNECT +when SILENT=true. +The STREAM STATUS message is:
<- STREAM STATUS @@ -490,7 +506,7 @@ forward connection requests. It is mandatory.When a connection request arrives from I2P, the SAM bridge requests a socket connection from $host:$port. If it is accepted after no more -than 3 seconds, SAM will accept the connection from I2P, and then : +than 3 seconds, SAM will accept the connection from I2P, and then:
If SILENT=true was passed, all data passing through the obtained @@ -532,8 +548,8 @@ After establishing a SAM session with STYLE=DATAGRAM, the client can send datagrams through SAM's UDP port (7655).
-The first line of a datagram sent through this port has to be in the -following format : +The first line of a datagram sent through this port must be in the +following format:
3.0 $nickname $destination @@ -553,7 +569,7 @@ following format :
The first line will be discarded by SAM before sending the remaining -of the message to the specified destination. +data of the message to the specified destination.
For an alternate method of sending repliable datagrams, see DATAGRAM SEND. @@ -567,7 +583,7 @@ command.
When a datagram arrives, the bridge delivers it to the client via the -message : +message:
<- DATAGRAM RECEIVED @@ -590,7 +606,7 @@ connection).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 -CREATE command with PORT and HOST options : +CREATE command with PORT and HOST options:
-> SESSION CREATE @@ -628,7 +644,7 @@ outbound.length=0). These options are documented below.. Forwarded datagrams are always prefixed with the destination (SILENT=false); SILENT=true is not honored. When a datagram arrives, the bridge sends to the specified host:port -a UDP packet containing the following data : +a UDP packet containing the following data:$destination\n$datagram_payload @@ -673,7 +689,7 @@ the session,the bridge delivers it to the client via:When anonymous datagrams are to be forwarded to some host:port, the bridge sends to the specified host:port a message containing -the following data : +the following data:
$datagram_payload