Description
WebSocket Message Handling Fragility
Hello,
During the short period of testing for my PR, I noticed that the current WebSocket message handling strategy is quite fragile. Let me elaborate:
Currently, the message read from the WebSocket is passed directly to a callback function called handler
:
for {
_, message, err := c.ReadMessage()
if err != nil {
if !silent {
errHandler(err)
}
return
}
handler(message)
}
From my limited understanding, any operation that takes even a few seconds—over a span of 23 hours (assuming the connection is renewed before the 24-hour deadline)—could add up and create a backlog of messages. This is especially problematic during high market volatility, where PING messages sent by the server might exceed the 1-minute threshold required for responding with a PONG message.
Potential Improvement
It might be useful to review and devise a new strategy for parsing messages. Some possible approaches:
- Priority Queue: Introduce a priority queue to handle messages, ensuring that PING/PONG messages are always processed promptly.
- Message Router with Deadline: Send all messages (excluding PING/PONG frames) to a message router. This router could enforce a deadline—if no message is consumed within a 120-second window (or even lower), the channel/buffer is flushed, and the connection is closed.
- This approach would prevent backlog accumulation and avoid disconnections due to timeouts.
Would love to hear thoughts on this! Let me know what you think.
Thanks!