understanding websockets on the server side

Question

I have a some questions in understanding websocket communication. AFAIU, in client side, it works like this:

1. From client, a new Socket handler is created using "new WebSocket('ws://blahblah')"
2. Then using onOpen() method its known that we are connected to WS server
3. Using onMessage() metthod, its known that a message has been received from WS Server
4. OnClose() method dictates the socket connection is closed

So from client perspective its clear. But from the server perspective how the flow goes (as above for client) and what is exactly mean by a websocket server process and what is exactly when we mean the communication happens on TCP and how do we check that (my aplologies if the question is very basic)

Can somebody please explain. Thanks in advannce

Answer 1

On server side it is really depends on implementation, language and API of websockets library or you own implementation you use.

This description is actual only for RAW implementation of WebSockets and is not based on use of any libraries to work with WebSockets protocol. Libraries, such as jWebSockets (Java), SignalR, socket.io and others will have absolutely another processes to work with WebSockets.

If we are talking about raw implementation on raw sockets, so process is like that:

1. Create server side TCP socket, bind to specific port and listen it, and then put on accepting state. Accepting can be blocking or non-blocking. I use .Net, and did asynchronous accepting, that way it will trigger method every time there is connection to server. 1b. Client called through JS: new WebSocket(...);
2. After accepted new socket, it have to start receiving data. TCP protocol is stream based, but not message based.
3. WebSockets protocol requires HTTP handshake for WebSockets to be done before you can communicate. So straight away after accepting new socket, you start receving data, and first what you will receive is handshake data - some lines of text.
4. Proceed through handshake process. It means read handshake data, and generate on server side response handshake data and send it over to WebSocket. 4b. If handshake data will be validated and verified by client side (browser), you will get callback "onopen", otherwise you will might get "onerror" and "onclose" after it.
5. After handshake is done, you can receive and send messages. Messages are dataframed (not raw) based on WebSockets protocol. And WebSockets are MESSAGE based protocol. So you have to make sure you read specific amount of message data before you proceed data for logical processing.
6. For receiving data on server side, if you use own implementation you have to implement reading from TCP socket stream. To do so, you will always want to read only 2 bytes, if there will be some (2 bytes) - this is header data, decode it based on protocol data framing specification, and keep reading rest of data to find out if there is masking then read masking bytes, and length. It is all in header. But header can be slightly different length. That is why you have to read only 2 bytes first, and then some after. After you get length, you have to read exactly this length of bytes from TCP socket stream. After all read, and actual data is demasked (if masking was enabled, for my experience it is always enabled), after that, you can put socket on reading some other data from the beginning. Do not start reading new message before finished reading current one.
7. After message is read and demasked, you will have raw data, in most cases it is just string that you sent from client using "socket.send("...");".
8. To send data, you have to take raw string data, then get bytes of string using UTF8 encoding, and after cover it with data framing, so it is inverse as reading, only difference is that you should not do masking. So from server to client data is not masked.
9. After you made binary and sent it, if everything is right you might receive on client side "onmessage" with data you sent.

Client will never receive part of data, or unordered data. It will always receive packets in order you sent, and always as you sent. Server might receive data partially based on low level TCP layer processes. But will receive always ordered.

This protocol is Reliable and Ordered.

Most popular specification of WebSockets protocol RFC 6455, bear in mind that iOS uses another specification and they might not be cross-compatible what means that you need to create another handshake functionality and data framing specifically for different protocol implementations.