mirror of
https://github.com/yarrick/iodine.git
synced 2025-08-14 23:07:26 +00:00
Applied patch from #88, thanks a lot!
This commit is contained in:
J. A. Bezemer
committed by
Erik Ekman
Erik Ekman
parent
1a26a91db3
commit
b177901d38
@@ -1,4 +1,4 @@
|
||||
Detailed specification of protocol in version 00000501
|
||||
Detailed specification of protocol in version 00000502
|
||||
======================================================
|
||||
|
||||
Note: work in progress!!
|
||||
@@ -7,6 +7,22 @@ Note: work in progress!!
|
||||
1. DNS protocol
|
||||
======================================================
|
||||
|
||||
Quick alphabetical index / register:
|
||||
0-9 Data packet
|
||||
A-F Data packet
|
||||
I IP address
|
||||
L Login
|
||||
N Downstream fragsize (NS.topdomain A-type reply)
|
||||
O Options
|
||||
P Ping
|
||||
R Downstream fragsize probe
|
||||
S Switch upstream codec
|
||||
V Version
|
||||
W (WWW.topdomain A-type reply)
|
||||
Y Downstream codec check
|
||||
Z Upstream codec check
|
||||
|
||||
|
||||
CMC = 2 byte Cache Miss Counter, increased every time it is used
|
||||
|
||||
Version:
|
||||
@@ -38,29 +54,55 @@ IP Request:
|
||||
Client sends:
|
||||
First byte i or I
|
||||
5 bits coded as Base32 char, meaning userid
|
||||
CMC
|
||||
CMC as 3 Base32 chars
|
||||
Server replies
|
||||
BADIP if bad userid, or
|
||||
I and then 4 bytes network order external IP address of iodined server
|
||||
|
||||
Case check:
|
||||
Upstream codec check / bounce:
|
||||
Client sends:
|
||||
First byte z or Z
|
||||
Lots of data that should not be decoded
|
||||
Server replies:
|
||||
The requested domain copied raw
|
||||
The requested domain copied raw, in the lowest-grade downstream codec
|
||||
available for the request type.
|
||||
|
||||
Downstream codec check:
|
||||
Client sends:
|
||||
First byte y or Y
|
||||
1 char, meaning downstream codec to use
|
||||
5 bits coded as Base32 char, meaning check variant
|
||||
CMC as 3 Base32 chars
|
||||
Possibly extra data, depending on check variant
|
||||
Server sends:
|
||||
Data encoded with requested downstream codec; data content depending
|
||||
on check variant number.
|
||||
BADCODEC if requested downstream codec not available.
|
||||
BADLEN if check variant is not available, or problem with extra data.
|
||||
|
||||
Downstream codec chars are same as in 'O' Option request, below.
|
||||
|
||||
Check variants:
|
||||
1: Send encoded DOWNCODECCHECK1 string as defined in encoding.h
|
||||
|
||||
(Other variants reserved; possibly variant that sends a decoded-encoded
|
||||
copy of Base32-encoded extra data in the request)
|
||||
|
||||
Switch codec:
|
||||
Client sends:
|
||||
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
|
||||
CMC
|
||||
5 bits coded as Base32 char, representing number of raw bits per
|
||||
encoded byte:
|
||||
5: Base32 (a-z0-5)
|
||||
6: Base64 (a-zA-Z0-9+-)
|
||||
26: Base64u (a-zA-Z0-9_-)
|
||||
7: Base128 (a-zA-Z0-9\274-\375)
|
||||
CMC as 3 Base32 chars
|
||||
Server sends:
|
||||
Name of codec if accepted. After this all upstream data packets must
|
||||
be encoded with the new codec.
|
||||
BADCODEC if not accepted. Client must then revert to Base32
|
||||
BADCODEC if not accepted. Client must then revert to previous codec
|
||||
BADLEN if length of query is too short
|
||||
|
||||
Options:
|
||||
@@ -68,6 +110,7 @@ Client sends:
|
||||
First byte o or O
|
||||
5 bits coded as Base32 char, meaning userid
|
||||
1 char, meaning option
|
||||
CMC as 3 Base32 chars
|
||||
Server sends:
|
||||
Full name of option if accepted. After this, option immediately takes
|
||||
effect in server.
|
||||
@@ -77,6 +120,8 @@ Server sends:
|
||||
Option chars:
|
||||
t or T: Downstream encoding Base32, for TXT/CNAME/A/MX (default)
|
||||
s or S: Downstream encoding Base64, for TXT/CNAME/A/MX
|
||||
u or U: Downstream encoding Base64u, for TXT/CNAME/A/MX
|
||||
v or V: Downstream encoding Base128, for TXT/CNAME/A/MX
|
||||
r or R: Downstream encoding Raw, for TXT/NULL (default for NULL)
|
||||
If codec unsupported for request type, server will use Base32; note
|
||||
that server will answer any mix of request types that a client sends.
|
||||
@@ -96,8 +141,10 @@ Client sends:
|
||||
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.
|
||||
Requested number of bytes as a response. The first two bytes contain
|
||||
the requested length. The third byte is 107 (0x6B). The fourth byte
|
||||
is a random value, and each following byte is incremented with 107.
|
||||
This is checked by the client to determine corruption.
|
||||
BADFRAG if requested length not accepted.
|
||||
|
||||
Set downstream fragment size:
|
||||
@@ -114,10 +161,10 @@ Server sends:
|
||||
|
||||
Data:
|
||||
Upstream data header:
|
||||
3210 432 10 43 210 4321 0
|
||||
+----+---+--+--+---+----+-+
|
||||
|UUUU|SSS|FF|FF|DDD|GGGG|L|
|
||||
+----+---+--+--+---+----+-+
|
||||
3210 432 10 43 210 4321 0 43210
|
||||
+----+---+--+--+---+----+-+-----+
|
||||
|UUUU|SSS|FF|FF|DDD|GGGG|L|UDCMC|
|
||||
+----+---+--+--+---+----+-+-----+
|
||||
|
||||
Downstream data header:
|
||||
7 654 3210 765 4321 0
|
||||
@@ -132,9 +179,11 @@ FFFF = Upstream fragment number
|
||||
DDD = Downstream packet sequence number
|
||||
GGGG = Downstream fragment number
|
||||
C = Compression enabled for downstream packet
|
||||
UDCMC = Upstream Data CMC, 36 steps a-z0-9, case-insensitive
|
||||
|
||||
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.
|
||||
Upstream data packet starts with 1 byte ASCII hex coded user byte; then 3 bytes
|
||||
Base32 encoded header; then 1 char data-CMC; then comes the payload data,
|
||||
encoded with the chosen upstream codec.
|
||||
|
||||
Downstream data starts with 2 byte header. Then payload data, which may be
|
||||
compressed.
|
||||
@@ -147,10 +196,18 @@ TXT:
|
||||
<=255 bytes)
|
||||
t or T: Base32 encoded before chop, decoded after un-chop
|
||||
s or S: Base64 encoded before chop, decoded after un-chop
|
||||
u or U: Base64u encoded before chop, decoded after un-chop
|
||||
v or V: Base128 encoded before chop, decoded after un-chop
|
||||
r or R: Raw no encoding, only DNS-chop
|
||||
CNAME/A/MX:
|
||||
SRV/MX/CNAME/A:
|
||||
h or H: Hostname encoded with Base32
|
||||
i or I: Hostname encoded with Base64
|
||||
j or J: Hostname encoded with Base64u
|
||||
k or K: Hostname encoded with Base128
|
||||
SRV and MX may reply with multiple hostnames, each encoded separately. Each
|
||||
has a 10-multiple priority, and encoding/decoding is done in strictly
|
||||
increasing priority sequence 10, 20, 30, etc. without gaps. Note that some DNS
|
||||
relays will shuffle the answer records in the response.
|
||||
|
||||
Ping:
|
||||
Client sends:
|
||||
@@ -162,10 +219,11 @@ Client sends:
|
||||
4 bits downstream fragment
|
||||
CMC
|
||||
|
||||
The server response to Ping and Data packets is a DNS NULL type response:
|
||||
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.
|
||||
The server response to Ping and Data packets is a DNS NULL/TXT/.. type response,
|
||||
always starting with the 2 bytes downstream data header as shown above.
|
||||
If server has nothing to send, no data is added after the header.
|
||||
If server has something to send, it will add the downstream data packet
|
||||
(or some fragment of it) after the header.
|
||||
|
||||
|
||||
"Lazy-mode" operation
|
||||
Reference in New Issue
Block a user