Can websocket messages get lost or not?

Question

I'm currently developing a Java WebSocket Client Application and I have to make sure that every message from the server is received by the client. Is it possible that I lose some messages (once they are sent from the server) due to a connection interruption? WebSocket is based on TCP so this shouldn't happen right?

Soilure

Either you receive the message, or you lose the connection entirely. – Geek

But after I lost the connection entirely the websocket clientEndpoint wouldn't work anymore right? That's why i built a reconnect-handler which sends a ping/pong message each 30 seconds to check if the connection is still up and if not it tries to create a new connection to the server. – Soilure

received does not mean it was read – Unrefined

Answer 1

It can happen. TCP guarantees the order of packets, but it does not mean that all packets sent from a server reach a client even when an unrecoverable trouble happens in an underlying network. Imagine someone pulls out your LAN cable or switches off your WiFi access point at the worst timing while your application is communicating with your server. TCP does not overcome such a trouble.

To ensure that every WebSocket message sent from your server reaches your client, you have to implement some kind of SYN/ACK in the application layer.

Hoskins

it looks like you are suggesting that TCP packets that don't arrive can go unnoticed. isn't the problem in the application layer, where the hardware has already sent an ACK but the application crashes before reading the received message? – Unrefined

Is application-layer ACK enough to ensure exactly 0% loss packets? We are developing an application where even 0.001% loss will cause serious trouble. Thanks! – Flofloat

@Unrefined That's exactly what I thought as well, afaik TCP does guarantee delivery and this answer suggests it doesn't, my understanding is that due to the async (fire and forget) communication model used by websockets it can't guarantee delivery at the application layer but the OS/hardware will still retransmit the packet/frame if it gets lost midway (provided the TCP connection is still open) – Ferryman

Answer 2

TCP is a guaranteed protocol - packets will be received in the correct order by the higher application levels at the far end (this is as opposed to UDP which is a send and hope protocol).

Generally speaking TCP should be be used for connections where all the data must arrive correctly at the far end. UDP is used where a missing packet can be dropped without significant issue (e.g. streaming services, NTP updates)

Woolson

Answer 3

In my game, to counter missed web socket messages, I added an int/long ID for each message. When the client detects that something is wrong in the sequence of IDs it receives, the client will request for new data from the server to be able to recover properly.

Millais

are you thinking of web rtc? web sockets should be delivering messages in order, within the socket. – Rabassa

Websockets use TCP as a transport and that ensures correct delivery and ordering of packets. Did you mean some kind to mechanism in the application layer to find out which response was intended for which request? – Gaming

Answer 4

TCP has something called Control Flow- which means it provides reliable, ordered, and error-checked delivery. In other words TCP is a protocol that checks constantly whether the data arrived.

This protocol has different mechanisms to ensure that. You can see the difference between TCP and UDP (which has no control flow) in the link below.

Difference between tcp and udp

Macfadyn