# RAET # Reliable Asynchronous Event Transport Protocol
7: Application: Format: Data (Stack to Application interface buffering etc) 6: Presentation: Format: Data (Encrypt-Decrypt convert to machine independent format) 5: Session: Format: Data (Interhost communications. Authentication. Groups) 4: Transport: Format: Segments (Reliable delivery of Message, Transactions, Segmentation, Error checking) 3: Network: Format: Packets/Datagrams (Addressing Routing) 2: Link: Format: Frames ( Reliable per frame communications connection, Media access controller ) 1: Physical: Bits (Transceiver communication connection not reliable)
Link is hidden from Raet Network is IP host address and Udp Port Transport is Raet transactions, service kind, tail error checking, Could include header signing as part of transport reliable delivery serialization of header Session is session id key exchange for signing. Grouping is Road (like 852 channel) Presentation is Encrypt Decrypt body Serialize Deserialize Body Application is body data dictionary
Header signing spans both the Transport and Session layers.
JSON Header (Tradeoff some processing speed for extensibility, ease of use, readability)
Body initially JSON but support for "packed" binary body
Header ASCII Safe JSON Header termination: Empty line given by double pair of carriage return linefeed /r/n/r/n 10 13 10 13 ADAD 1010 1101 1010 1101
In json carriage return and newline characters cannot appear in a json encoded string unless they are escaped with backslash, so the 4 byte combination is illegal in valid json that does not have multi-byte unicode characters.
These means the header must be ascii safe so no multibyte utf-8 strings allowed in header.
Following Header Terminator is variable length signature block. This is binary and the length is provided in the header.
Following the signature block is the packet body or data. This may either be JSON or packed binary. The format is given in the json header
Finally is an optional tail block for error checking or encryption details
In UDP header
sh = source host sp = source port dh = destination host dp = destination port
In RAET Header
hk = header kind hl = header length
vn = version number
sd = Source Device ID dd = Destination Device ID cf = Corresponder Flag mf = Multicast Flag
si = Session ID ti = Transaction ID
sk = Service Kind pk = Packet Kind bf = Burst Flag (Send all Segments or Ordered packets without interleaved acks)
oi = Order Index dt = DateTime Stamp
sn = Segment Number sc = Segment Count
pf = Pending Segment Flag af = All Flag (Resent all Segments not just one)
nk = Auth header kind nl = Auth header length
bk = body kind bl = body length
tk = tail kind tl = tail length
Minion sends packet with SID of Zero with public key of minions Public Private Key pair Master acks packet with SID of Zero to let minion know it received the request
Some time later Master sends packet with SID of zero that accepts the Minion
Session is important for security. Want one session opened and then multiple transactions within session.
Session ID SID sid
GUID hash to guarantee uniqueness since no guarantee of nonvolatile storage or require file storage to keep last session ID used.
Four Service Types
One or more maybe (unacknowledged repeat) maybe means no guarantee
at most means fixed number of retries has finite probability of failing B1) finite retries B2) infinite retries with exponential back-off up to a maximum delay
Receiver requests retry of missing packet with same B1 or B2 retry type
This is two B sub transactions
Initially unicast messaging Eventually support for Multicast
The use case for C) is to fragment large packets as once a UDP packet exceeds the frame size its reliability goes way down So its more reliable to fragment large packets.
Better approach might be to have more modularity. Services Levels
- Maybe one or more
- Fire and forget
no transaction either side
- Repeat, no ack, no dupdet
repeat counter send side, no transaction on receive side
- Repeat, no Ack, dupdet
repeat counter send side, dup detection transaction receive side
- More or Less Once
- retry finite, ack no dupdet
retry timer send side, finite number of retires ack receive side no dupdet
- At most Once
- retry finite, ack, dupdet
retry timer send side, finite number of retires ack receive side dupdet
- Exactly once
- ack retry
retry timer send side, ack and duplicate detection receive side Infinite retries with exponential backoff
- Sequential sequence number
- reorder escrow
- Segmented packets
request response to application layer
Always include transaction id since multiple transactions on same port So get duplicate detection for free if keep transaction alive but if use
A) Maybe one or more B1) At Least One B2) Exactly One C) One of sequence D) End to End
A) Sender creates transaction id for number of repeats but receiver does not keep transaction alive
B1) Sender creates transaction id keeps it for retries. Receiver keeps it to send ack then kills so retry could be duplicate not detected
B2) Sender creates transaction id keeps for retries Receiver keeps tid for acks on any retires so no duplicates.
C) Sender creates TID and Sequence Number. Receiver checks for out of order sequence and can request retry.
D) Application layer sends response. So question is do we keep transaction open or have response be new transaction. No because then we need a rep-req ID so might as well use the same transaction id. Just keep alive until get response.
Little advantage to B1 vs B2 not having duplicates.
So 4 service types
Also multicast or unicast
Modular Transaction Table