- From: Victor Boivie via GitHub <sysbot+gh@w3.org>
- Date: Sun, 20 Jun 2021 18:50:30 +0000
- To: public-webrtc-logs@w3.org
It's an interesting idea. I have been considering the same for the purpose of monitoring some signaling messages that are sent unordered with partial reliability, where it's hard to create a good higher level protocol. With the current events from rfc6458, I think it would be hard to make something easily. With a custom implementation, it wouldn't be hard to the SCTP implementation to provide message lifecycle events, if requested. A message that is sent on a socket would have a state diagram with states: * Queued (in send buffer, not yet assigned a MID to, and no fragment put on the wire) * Partially sent (for multi-fragment messages where at least one fragment has been put on the write) * Fully sent (all fragments have been put on the wire, but not yet acknowledged) * Acked (received has sent a SACK including it. Here, if we assume all SACKs are non-renegable, this is straightforward) * Lost (Message expired with not all fragments ever put on the wire) * Probably lost (Message expired before acked, but with all fragments sent at least once, so received _may_ have received it) All states are not applicable for all messages, and all states may not be interesting to inform the upper layer about, but it is possible. In `dcsct::SendOptions`, I thought about adding a new parameter, e.g. `uint64_t client_message_id`, which if non-zero, would trigger callbacks whenever the message changes states, and using `client_message_id` to identify the message. I might prototype it, and see if there are pitfalls. Partial reliability is one, of course, but also stream resetting (which may throw away messages) and if an association detects that the peer has restarted (receives an INIT, and restarts the association), as that may trigger resending of messages and reset their states. If you are only interested in knowledge if a message was successfully received, I do agree that doing that in a higher layer protocol would be the reasonable choice. The other states may be harder or even impossible to find out without information from the SCTP socket implementation. -- GitHub Notification of comment by boivie Please view or discuss this issue at https://github.com/w3c/webrtc-extensions/issues/50#issuecomment-864596385 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Monday, 21 June 2021 05:01:23 UTC