implement sending a message for WS and add a websocketFrame class

[jodevsa]

nodejs#932

can be tested with:

const { WebSocket } = require('./lib/websocket/websocket.js')

const ws = new WebSocket('wss://echo.websocket.events/')

ws.addEventListener('message', (event) => {
  console.log('received:', event.data) // "echo.websocket.events sponsored by Lob.com"
})

ws.addEventListener('open', () => {
  let i = 0
  setInterval(() => {
    const text = `hello. This is message number #${i}`
    console.log('sending:', text)
    ws.send(text)
    i++
  }, 1000)
})

[KhafraDev]

This is great, thank you so much for working on this!

We are so much closer to finishing this now - this was one of the last hurdles that needed to be completed!

[lpinca]

Keep in mind that there is no guarantee that chunk is a complete frame. It might be just the first few bytes of a frame, a slice in the middle of a frame, the tail of frame and the beginning of another, or multiple frames.

[jodevsa]

Hi @lpinca, Thank you for your feedback. I was under the impression that any websocket server will flush the socket buffer after each complete frame and we'll always get a chunk with a full frame.

Do you know an easy way to spin up a ws server where I can test these cases?
1- buffer with incomplete frame
2- buffer with multiple frames
3. etc..

[lpinca]

I was under the impression that any websocket server will flush the socket buffer after each complete frame and we'll always get a chunk with a full frame.

This is outside of the control of any server. It depends on the OS, the protocol (TCP), the network, etc. When you call socket.write(data), there is no guarantee that the other peer receives all the data as a single TCP packet.

Do you know an easy way to spin up a ws server where I can test these cases?

It is easier to do it without a real server. Take a look at https://github.com/websockets/ws/blob/8.11.0/lib/receiver.js and https://github.com/websockets/ws/blob/8.11.0/test/receiver.test.js.

Keep also in mind that the WHATWG spec advertises support for the permessage-deflate extension, so if the server you are connecting to also supports permessage-deflate, you might receive frames whose payload data is compressed. If decompression is slower than incoming data, you also have to handle backpressure.

[jodevsa]

Thank you @lpinca