iodine/doc/proto_00000403.txt

113 lines
3.2 KiB
Plaintext
Raw Normal View History

2008-12-06 13:20:47 +00:00
Detailed specification of protocol in version 00000403
======================================================
CMC = 2 byte Cache Miss Counter, increased every time it is used
Version:
Client sends:
2008-12-07 09:41:06 +00:00
First byte v or V
Rest encoded with base32:
4 bytes big endian protocol version
CMC
2008-12-06 13:20:47 +00:00
Server replies:
2008-12-07 09:41:06 +00:00
4 chars:
2008-12-06 13:20:47 +00:00
VACK (version ok), followed by login challenge
VNAK (version differs), followed by server protocol version
VFUL (server has no free slots), followed by max users
2008-12-07 09:41:06 +00:00
4 byte value: means login challenge/server protocol version/max users
1 byte userid of the new user, or any byte if not VACK
2008-12-06 13:20:47 +00:00
Login:
Client sends:
2008-12-07 09:41:06 +00:00
First byte l or L
Rest encoded with base32:
1 byte userid
2008-12-06 13:20:47 +00:00
16 bytes MD5 hash of: (first 32 bytes of password) xor (8 repetitions of login challenge)
2008-12-07 09:41:06 +00:00
CMC
2008-12-06 13:20:47 +00:00
Server replies:
LNAK means not accepted
x.x.x.x-y.y.y.y-mtu-netmask means accepted (server ip, client ip, mtu, netmask bits)
2008-12-06 13:20:47 +00:00
Case check:
Client sends:
2008-12-07 09:41:06 +00:00
First byte z or Z
2008-12-06 13:20:47 +00:00
Lots of data that should not be decoded
Server replies:
The requested domain copied raw
Switch codec:
Client sends:
2008-12-07 09:41:06 +00:00
First byte s or S
5 bits coded as Base32 char, meaning userid
5 bits coded as Base32 char, with value 5 or 6, representing number of raw
bits per encoded byte
2008-12-06 13:20:47 +00:00
Server sends:
Name of codec if accepted. After this all upstream data packets must
be encoded with the new codec.
2008-12-07 09:41:06 +00:00
BADCODEC if not accepted. Client must then revert to Base32
2008-12-06 13:20:47 +00:00
Probe downstream fragment size:
Client sends:
First byte r or R
15 bits coded as 3 Base32 chars: UUUUF FFFFF FFFFF
meaning 4 bits userid, 11 bits fragment size
Then follows a long random query which contents does not matter
Server sends:
Requested number of bytes as a response. The first two bytes contains
the requested length. Rest of message can be any data.
BADFRAG if requested length not accepted.
Set downstream fragment size:
Client sends:
First byte n or N
Rest encoded with base32:
1 byte userid
2 bytes new downstream fragment size
CMC
Server sends:
2 bytes new downstream fragment size. After this all downstream
payloads will be max (fragsize + 2) bytes long.
BADFRAG if not accepted.
2008-12-06 13:20:47 +00:00
Data:
Upstream data header:
3210 432 10 43 210 4321 0
+----+---+--+--+---+----+-+
|UUUU|SSS|FF|FF|DDD|GGGG|L|
+----+---+--+--+---+----+-+
2008-12-06 13:20:47 +00:00
Downstream data header:
7 654 3210 765 4321 0
+-+---+----+---+----+-+
|C|SSS|FFFF|DDD|GGGG|L|
+-+---+----+---+----+-+
UUUU = Userid
2008-12-06 13:20:47 +00:00
L = Last fragment in packet flag
SS = Upstream packet sequence number
FFFF = Upstream fragment number
DDD = Downstream packet sequence number
GGGG = Downstream fragment number
C = Compression enabled for downstream packet
Upstream data packet starts with 1 byte ASCII hex coded user byte, then 3 bytes
Base32 encoded header, then comes the payload data, encoded with chosen codec.
2008-12-06 13:20:47 +00:00
Downstream data starts with 2 byte header. Then payload data, which may be
compressed.
2008-12-06 13:20:47 +00:00
Ping:
Client sends:
First byte p or P
Rest encoded with Base32:
1 byte with 4 bits userid
1 byte with:
3 bits downstream seqno
4 bits downstream fragment
CMC
2008-12-06 13:20:47 +00:00
The server response to Ping and Data packets is a DNS NULL type response:
2008-12-07 09:41:06 +00:00
If server has nothing to send, data length is 0 bytes.
If server has something to send, it will send a downstream data packet,
prefixed with 2 bytes header as shown above.