logos-messaging/specs
1
0
Fork 0
mirror of https://github.com/logos-messaging/specs.git synced 2026-05-18 19:09:33 +00:00
Code Issues Packages Projects Releases Wiki Activity

improve RequestId definition

Browse Source
This commit is contained in:
Ivan FB 2026-04-28 23:27:22 +02:00
parent 33f89ccbd8
commit dba72eb697
No known key found for this signature in database
GPG Key ID: DF0C67A04C543270
1 changed files with 14 additions and 8 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

22
standards/application/reliable-channel-api.md
View File

@ -190,8 +190,8 @@ functions:
type: array<byte> type: array<byte>
description: "The raw message payload to send." description: "The raw message payload to send."
returns: returns:
type: result<ReliableSendId, error> type: result<RequestId, error>
description: "Returns a `ReliableSendId` that callers can use to correlate subsequent `MessageSentEvent` or `MessageSendErrorEvent` events." description: "Returns a `RequestId` that callers can use to correlate subsequent `MessageSentEvent` or `MessageSendErrorEvent` events."
onMessageReceived: onMessageReceived:
description: "Subscribes a callback to be invoked when a complete message has been received and reassembled." description: "Subscribes a callback to be invoked when a complete message has been received and reassembled."
@ -313,7 +313,7 @@ types:
For end-to-end confirmation, listen for `MessageDeliveredEvent`." For end-to-end confirmation, listen for `MessageDeliveredEvent`."
fields: fields:
requestId: requestId:
type: ReliableSendId type: RequestId
description: "The identifier of the `send` operation whose segments have all been dispatched to the network." description: "The identifier of the `send` operation whose segments have all been dispatched to the network."
MessageDeliveredEvent: MessageDeliveredEvent:
@ -322,7 +322,7 @@ types:
This event is fired asynchronously after `MessageSentEvent`, once the SDS layer receives explicit acknowledgements from the recipient." This event is fired asynchronously after `MessageSentEvent`, once the SDS layer receives explicit acknowledgements from the recipient."
fields: fields:
requestId: requestId:
type: ReliableSendId type: RequestId
description: "The identifier of the `send` operation confirmed as delivered by the recipient." description: "The identifier of the `send` operation confirmed as delivered by the recipient."
MessageSendErrorEvent: MessageSendErrorEvent:
@ -330,7 +330,7 @@ types:
description: "Event emitted when a message send operation fails after exhausting retransmission attempts." description: "Event emitted when a message send operation fails after exhausting retransmission attempts."
fields: fields:
requestId: requestId:
type: ReliableSendId type: RequestId
description: "The identifier of the `send` operation that failed after exhausting retransmission attempts." description: "The identifier of the `send` operation that failed after exhausting retransmission attempts."
error: error:
type: string type: string
@ -339,15 +339,21 @@ types:
- `dispatch_failed`: the network layer rejected or could not dispatch the segment (e.g. lightpush returned `is_success: false`, or no relay/lightpush peers were reachable); propagated from the underlying [MESSAGING-API](/standards/application/messaging-api.md) `MessageSendErrorEvent` error field. - `dispatch_failed`: the network layer rejected or could not dispatch the segment (e.g. lightpush returned `is_success: false`, or no relay/lightpush peers were reachable); propagated from the underlying [MESSAGING-API](/standards/application/messaging-api.md) `MessageSendErrorEvent` error field.
- `channel_closed`: the channel was closed before the recipient confirmed delivery, leaving one or more segments unacknowledged." - `channel_closed`: the channel was closed before the recipient confirmed delivery, leaving one or more segments unacknowledged."
ReliableSendId: RequestId:
type: string type: string
description: "Unique identifier for a single `send` operation on a reliable channel. description: "Unique identifier for a single `send` operation on a reliable channel.
It groups all segments produced by segmenting one message, so callers can correlate It groups all segments produced by segmenting one message, so callers can correlate
acknowledgement and error events back to the original send call. acknowledgement and error events back to the original send call.
Internally, each segment is dispatched as an independent [MESSAGING-API](/standards/application/messaging-api.md) call, Internally, each segment is dispatched as an independent [MESSAGING-API](/standards/application/messaging-api.md) call,
producing one `RequestId` (as defined in [MESSAGING-API](/standards/application/messaging-api.md)) per segment. producing one `RequestId` (as defined in [MESSAGING-API](/standards/application/messaging-api.md)) per segment.
A single `ReliableSendId` therefore maps to one or more underlying `RequestId` values, A single `RequestId` therefore maps to one or more underlying [MESSAGING-API](/standards/application/messaging-api.md)'s `RequestId` values,
one per segment sent." one per segment sent.
For example, the `RequestId` `Req_a` yields these MESSAGING-API requests:
`Req_a:1`, `Req_a:2`, ..., `Req_a:N`, where `Req_a:k` represents the k-th
MESSAGING-API segment `RequestId`.
That is, `Req_a` is the `RequestId` from the RELIABLE-CHANNEL-API spec PoV,
whereas `Req_a:k` is the `RequestId` from the MESSAGING-API spec PoV.
"
SegmentationConfig: SegmentationConfig:
type: object type: object