diff --git a/i2p2www/pages/site/docs/api/samv3.html b/i2p2www/pages/site/docs/api/samv3.html index 352c5fae..875ddd14 100644 --- a/i2p2www/pages/site/docs/api/samv3.html +++ b/i2p2www/pages/site/docs/api/samv3.html @@ -12,6 +12,7 @@ Java applications should use the streaming or I2CP APIs directly. was introduced in I2P release 0.7.3 (May 2009) and is a stable and supported interface. 3.1 is also stable and supports the signature type option, which is strongly recommended. More recent 3.x versions support advanced features. +Note that i2pd does not currently support most 3.2 and 3.3 features.
Alternatives: SOCKS, @@ -308,9 +309,10 @@ can forward back I2P datagrams to the client's datagram server.
-Version 3.1 was introduced in I2P release 0.9.14 (July 2014). SAM 3.1 is the recommended +Version 3.1 was introduced in Java I2P release 0.9.14 (July 2014). SAM 3.1 is the recommended minimum SAM implementation because of its support for better signature types than SAM 3.0. +i2pd also supports most 3.1 features.
-Version 3.2 was introduced in I2P release 0.9.24 (January 2016). +Version 3.2 was introduced in Java I2P release 0.9.24 (January 2016). +Note that i2pd does not currently support most 3.2 features.
-Version 3.3 was introduced in I2P release 0.9.25 (March 2016). +Version 3.3 was introduced in Java I2P release 0.9.25 (March 2016). +Note that i2pd does not currently support most 3.3 features.
Key=value pairs must be separated by a single space. (As of SAM 3.2, multiple spaces are allowed) -Values may be enclosed in double quotes if they contain spaces, +Values must be enclosed in double quotes if they contain spaces, e.g. key="long value text". (Prior to SAM 3.2, this did not work reliably in some implementations)
@@ -502,7 +506,7 @@ If the SAM bridge cannot find a suitable version, it replies with: If some error occurred, such as a bad request format, it replies with:
-<- HELLO REPLY RESULT=I2P_ERROR MESSAGE=$message +<- HELLO REPLY RESULT=I2P_ERROR MESSAGE="$message"@@ -531,13 +535,13 @@ Clients should promptly send the HELLO and the next command after connecting.
If a timeout occurs before the HELLO is received, the bridge replies with:
-<- HELLO REPLY RESULT=I2P_ERROR MESSAGE=$message +<- HELLO REPLY RESULT=I2P_ERROR MESSAGE="$message"and then disconnects.
If a timeout occurs after the HELLO is received but before the next command, the bridge replies with:
-<- SESSION STATUS RESULT=I2P_ERROR MESSAGE=$message +<- SESSION STATUS RESULT=I2P_ERROR MESSAGE="$message"and then disconnects. @@ -721,7 +725,7 @@ If the destination is not a valid private destination key:
If some other error has occurred:
-<- SESSION STATUS RESULT=I2P_ERROR MESSAGE=$message +<- SESSION STATUS RESULT=I2P_ERROR MESSAGE="$message"
@@ -1527,7 +1531,7 @@ which is answered by RESULT=$result NAME=$name [VALUE=$destination] - [MESSAGE=$message] + [MESSAGE="$message"] @@ -1639,7 +1643,7 @@ Either side may close the session and socket if no response is received in a rea
If a timeout occurs waiting for a PONG from the client, the bridge may send:
-<- SESSION STATUS RESULT=I2P_ERROR MESSAGE=$message +<- SESSION STATUS RESULT=I2P_ERROR MESSAGE="$message"and then disconnect.