Does the WebSocket object abstract away frames?

Question

The WebSocket API object has an onmessage property and emits message events. However, there are no mentions of frames . Is that because it is abstracted away?

Answer 1

The frame is header + “payload” of the response. Basically, WebSockets communicates with each other in the form of these "frames". We have 3 control and non-control frames. So they are just written "over" by API's which we use. We need a handshake and data frames are exchanged every time anything is emitted so they are being sent by the API's.

They are not abstracted away. Because of the idea of sending a server request from scratch which is purely constant in nature can be made easy by just adding a layer on it. Same goes for data-frames. You don't have to decode things again and again just to read a "Hello, World".

A typical frame looks like this

Frame format

  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-------+-+-------------+-------------------------------+
 |F|R|R|R| opcode|M| Payload len |    Extended payload length    |
 |I|S|S|S|  (4)  |A|     (7)     |             (16/64)           |
 |N|V|V|V|       |S|             |   (if payload len==126/127)   |
 | |1|2|3|       |K|             |                               |
 +-+-+-+-+-------+-+-------------+ - - - - - - - - - - - - - - - +
 |     Extended payload length continued, if payload len == 127  |
 + - - - - - - - - - - - - - - - +-------------------------------+
 |                               |Masking-key, if MASK set to 1  |
 +-------------------------------+-------------------------------+
 | Masking-key (continued)       |          Payload Data         |
 +-------------------------------- - - - - - - - - - - - - - - - +
 :                     Payload Data continued ...                :
 + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
 |                     Payload Data continued ...                |
 +---------------------------------------------------------------+

These operations are handled by the API you use and most of them are written on top of them to make things easy. To go in-depth, I suggest you visit this blog post about Websockets from scratch . Here you'll notice some ruby code that you don't have to understand but just get the idea that the bytes are being decoded from the frame and then being read. There's also some code that tells how do you initiate a web socket response from scratch by sending a response to the server like this.

"HTTP/1.1 101 Switching Protocols\r\n"
"Upgrade: websocket\r\n"
"Connection: Upgrade\r\n"
"Sec-WebSocket-Accept: #{ws_accept}\r\n" // some off-topic ruby code

You cannot use WebSockets without sending this first so this javascript code does this for you

const socket = new WebSocket('ws://localhost:8080');
socket.addEventListener('open', function (event) {
    socket.send('Hello Server!');
});

My point is that these are not hidden away but they are just written over. It's like you don't have to write assembly code to write a "Hello, world" program you can use C or C++ to do that too.

Extensions

Think of an extension as compressing a file before e-mailing it to someone. Whatever you do, you're sending the same data in different forms. The recipient will eventually be able to get the same data as your local copy, but it is sent differently. That's what an extension does. WebSockets defines a protocol and a simple way to send data, but an extension such as compression could allow sending the same data but in a shorter format.

Same goes for a POST request or a web server of any sort. They make our lives easy

POST /somescript.cig HTTP/1.0
From: JohnDoe@servername.com
User-Agent: HTTPTool/1.0
Content-Type: application/x-www-form-urlencoded
Content-Length: 32