Practice: What Each Protocol Sends for One Chat Message

One user sends "hi"; write what crosses the wire over WebSocket, SSE with a POST, and a data channel.

Describing what one message looks like on the wire, in each protocol, is how to check the profiles have stuck. A chat app sends the text hi from one user to another, and is built three ways.

WebSocket. The sender's browser already has an open WebSocket to the chat server. What does it send, and what reaches the other user?
SSE with a POST. Both users have an EventSource open to the server. How does the sender's message travel, and what does the other user's stream receive?
WebRTC data channel. The two browsers already have a data channel open between them. What crosses the network, and does the chat server see it?

For each, name who sends what, and describe the bytes or lines.

Show the answers

WebSocket. The browser sends one masked text frame to the server: 81 82, then four mask bytes, then the two letters mixed with the mask. With the RFC's example mask 37 fa 21 3d, the data bytes are 5f 93, eight bytes in all. The server sends the other user an unmasked frame on their connection: 81 02 68 69, four bytes, where 68 69 is "hi".
SSE with a POST. The sender cannot write to its event stream, so it makes a separate request, POST /messages with a body such as {"text":"hi"}. The server then writes an event into the other user's open response: an id line, data: {"text":"hi"}, and an empty line.
Data channel. One UDP datagram from one browser to the other, holding a DTLS record that wraps an SCTP message whose content is hi. On the wire it is encrypted and unreadable. The chat server sees nothing, unless the path runs through its TURN relay, which forwards the datagram without being able to read it.

The bytes in answer 1 follow RFC 6455's frame format and are worked by hand, not captured.

← → move through sections and cards