forked from I2P_Developers/i2p.www
cleanups
This commit is contained in:
@ -118,15 +118,15 @@ Scheduled for I2P release 0.9.25.
|
||||
<h2>Version 3 Protocol</h2>
|
||||
<h3>Simple Anonymous Messaging (SAM version 3.0) Specification Overview</h3>
|
||||
<p>
|
||||
Client application talks to SAM bridge, which deals with
|
||||
The client application talks to the SAM bridge, which deals with
|
||||
all of the I2P functionality (using the streaming
|
||||
lib for virtual streams, or I2CP directly for async messages).
|
||||
library for virtual streams, or I2CP directly for datagrams).
|
||||
|
||||
</p><p>
|
||||
The client<-->SAM bridge communication may unencrypted or unauthenticated.
|
||||
By default, the client<-->SAM bridge communication is unencrypted and unauthenticated.
|
||||
The SAM bridge may support SSL/TLS connections;
|
||||
configuration and implementation details are outside the scope of this specification.
|
||||
As of SAM 3.2, optional authentication in the handshake is specified
|
||||
As of SAM 3.2, optional authentication user/password parameters are supported in the initial handshake
|
||||
and may be required by the bridge..
|
||||
|
||||
</p><p>
|
||||
@ -142,7 +142,8 @@ I2P communications can take three distinct forms:
|
||||
I2P communications are supported by I2P sessions, and each I2P
|
||||
session is bound to an address (called destination). An I2P session
|
||||
is associated with one of the three types above, and cannot carry
|
||||
communications of another type.
|
||||
communications of another type,
|
||||
unless using <a href="#master">MASTER sessions</a>.
|
||||
</p>
|
||||
|
||||
|
||||
@ -971,6 +972,14 @@ To create multiplexed subsessions, you must create a master session
|
||||
and then add subsessions to the master session.
|
||||
Each subsession must have a unique id and a unique listen protocol and port.
|
||||
Subsessions may also be removed from the master session.
|
||||
|
||||
</p><p>
|
||||
With a MASTER session and a combination of subsessions, a SAM client
|
||||
may support multiple applications, or a single sophisticated application
|
||||
using a variety of protcols, on a single set of tunnels.
|
||||
For example, a bittorrent client could set up a streaming subsession
|
||||
for peer-to-peer connections, together with datagram and raw subsessions
|
||||
for DHT communication.
|
||||
</p>
|
||||
|
||||
<h4>Creating a MASTER Session</h4>
|
||||
|
Reference in New Issue
Block a user