Files
i2p.itoopie/apps/ministreaming/doc/protocol.txt

84 lines
2.0 KiB
Plaintext
Raw Normal View History

2004-04-08 04:41:54 +00:00
ministreaming protocol:
*******************
Each message looks like the following
1 byte type
3 byte id
x byte payload.
messages from client to server have type 0xA0 to 0xAF,
messages from server to client have type 0x50 to 0x5F.
Each "connections" has 2 IDs, a client ID and a server ID.
These IDs may be any 3-byte values except 00 00 00, which is reserved.
All connections are created as PROP_RELIABILITY_GUARANTEED.
"actions" are the things a proper tunnel implementation SHOULD do
when it receives such a message.
Client->Server:
===============
0xA0 Send data
id: the server id
payload: the data to send
actions: send the data to the TCP connection
0xA1 SYN
id: the client id
payload: the public key dynamically created by the client
actions: create a server ID and create a TCP connection. When successful,
send an ACK back, otherwise a close.
0xA2 Close
id: the server id
payload: nothing
actions: close the connection
Server->Client
==============
0x50 Send data
id: the client id
payload: the data to send
actions: send the data to the TCP connection
0x51 ACK
id: the client id
payload: the server id
actions: nothing
0x52 Close
id: the client id
payload: nothing
actions: close the connection
Sample conversations:
=====================
a) Service not available (e.g. the server on the TCP port is not running)
C->S A1 12 34 56 key... (SYN, client ID = 12 34 56)
S->C 52 12 34 56 (Close)
b) Service available, server sends data, client closes
C->S A1 23 45 67 key... (SYN)
S->C 51 23 45 67 98 76 54 (ACK, server ID = 98 76 54)
S->C 50 23 45 67 data (Send data)
C->S A2 98 76 54 (Close)
c) Service available, client sends data first, server closes after answer (HTTP)
C->S A1 11 11 11 key... (SYN)
S->C 51 11 11 11 FF FF FF (ACK)
C->S A0 FF FF FF data (send data)
S->C 50 11 11 11 data (answer with data)
S->C 50 11 11 11 data (more data)
S->C 51 11 11 11 (Close)