From b6fd298ed90e09b3edbb3097f4e53ecb0443c388 Mon Sep 17 00:00:00 2001 From: Sasha Koshka Date: Thu, 9 Jan 2025 02:40:06 -0500 Subject: [PATCH] design: Better explain METADAPT conversion of stream-oriented protocols --- design/protocol.md | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/design/protocol.md b/design/protocol.md index d1a0b5c..599db26 100644 --- a/design/protocol.md +++ b/design/protocol.md @@ -136,7 +136,8 @@ that persists for the duration of the connection. All transactions are multiplexed onto this single stream. Each MMB contains a 12-octet long header, with the transaction ID, then the method, and then the payload size (in octets). The transaction ID is encoded as an I64, and the method and payload size are -both encoded as U16s. The remainder of the message is the payload. +both encoded as U16s. The remainder of the message is the payload. Since each +MMB is self-describing, they are sent sequentially with no gaps in-between them. Transactions "open" when the first message with a given transaction ID is sent. They "close" when a closing message is sent by either side. A closing message @@ -147,7 +148,8 @@ METADAPT-B requires a transport which offers multiple multiplexed full-duplex data streams per connection that can be created and destroyed on-demand. Each data stream is used as an individual transaction. Each MMB contains a 4-octet long header with the method and then the payload size (in octets) both encoded -as U16s. The remainder of the message is the payload. +as U16s. The remainder of the message is the payload. Since each MMB is +self-describing, they are sent sequentially with no gaps in-between them. The ID of any transaction will reflect the ID of its corresponding stream. The lifetime of the transaction is tied to the lifetime of the stream, that is to