Discussion: Reliability in unreliable networks

[dlqqq]

Description

@ellisonbg and @Zsailer pointed out that the design proposed in #3 may lead to issues in unreliable networks. Specifically:

• What happens if a brief disconnect occurs while a message is moving through the WebSocket? Does that message always get lost?

• Is it possible for a message to be "dropped" while the connection is still alive?

We should look into what transport-layer guarantees are offered by TCP, and whether they address these questions.

[3coins]

What happens if a brief disconnect occurs while a message is moving through the WebSocket? Does that message always get lost?

Yes, that message is usually lost, WebSockets inherently won’t take care of this scenario.

• Once the connection breaks (even briefly), in-transit messages that haven't been fully received by the other end are lost, unless application-level logic is added to detect and recover them.
• There is no automatic retry for WebSocket messages. If the connection drops mid-message, it’s like pulling the plug, unless the application has a custom acknowledgment system, the sender won't know whether the message was received.

Is it possible for a message to be "dropped" while the connection is still alive?

This is very rare, as TCP ensures message delivery if the connection is active.

Some possible reasons this can happen:

• Network issues or congestion: Sometimes, underlying issues in routers or firewalls can silently drop packets.
• Server/client buffer overflow: If the client or server receives messages faster than it can process them, buffers might overflow and messages could be dropped.
• Application bugs: Logic errors in how messages are handled, such as parsing or discarding malformed messages.
• Protocol misbehavior: Misconfigured proxies or intermediaries (especially in browsers or mobile networks) can interfere with WebSocket traffic.