You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
[AIT-96] feat: RealtimeChannel publish over WebSocket implementation
Implemented Spec points:
## Message Publishing Specifications (RTL6)
### RTL6c - Messages published on channels in specific states
- Messages published when channel is not **ATTACHED** should be published immediately
### RTL6c2 - Message queuing behavior
- Messages can be queued when connection/channel is not ready
- Relates to processing queued messages when connection becomes ready
### RTL6c3 - Publishing without implicit attach
### RTL6c4 - Behavior when queueMessages client option is false
### RTL6d - Message bundling restrictions
#### RTL6d1: Maximum message size limits for bundling
- **RTL6d2**: All messages in bundle must have same clientId
#### RTL6d3: Can only bundle messages for same channel
- **RTL6d4**: Can only bundle messages with same action (MESSAGE or PRESENCE)
#### RTL6d7: Cannot bundle idempotent messages with non-idempotent messages
---
## Message Acknowledgment (RTN7)
### RTN7a
All **PRESENCE**, **MESSAGE**, **ANNOTATION**, and **OBJECT** ProtocolMessages sent to Ably expect either an **ACK** or **NACK** to confirm successful receipt or failure
### RTN7b
Every ProtocolMessage requiring acknowledgment must contain a unique serially incrementing `msgSerial` integer starting at zero
### RTN7c
If connection enters **SUSPENDED**, **CLOSED**, or **FAILED** state and ACK/NACK has not been received, client should fail those messages and remove them from retry queues
### RTN7d
If `queueMessages` is false, messages entering **DISCONNECTED** state without acknowledgment should be treated as failed immediately
### RTN7e
When connection state changes to **SUSPENDED**/**CLOSED**/**FAILED**, pending messages (submitted via RTL6c1 or RTL6c2) awaiting ACK/NACK should be considered failed
---
## Message Resending and Serial Handling (RTN19)
### RTN19a
Upon reconnection after disconnection, client library must resend all pending messages awaiting acknowledgment, allowing the realtime system to respond with ACK/NACK
### RTN19a2
In the event of a new `connectionId` (connection not resumed), previous `msgSerials` are meaningless and must be reset. The `msgSerial` counter resets to 0 for the new connection
---
## Channel State and Reattachment (RTL3, RTL4, RTL5)
### RTL3c
Channel state implications when connection goes into **SUSPENDED**
### RTL3d
When connection enters **CONNECTED** state, channels in **ATTACHING**, **ATTACHED**, or **SUSPENDED** states should transition to **ATTACHING** and initiate attach sequence. Connection should process queued messages immediately without waiting for attach operations to finish
### RTL4c - Attach sequence
- **RTL4c1**: ATTACH message includes channel serial to resume from previous message or attachment
### RTL5i
If channel is **DETACHING**, re-send **DETACH** and remain in 'detaching' state
0 commit comments