Why does Websocket RFC allows control frame interleaved with multiframe

Question

From the Websocket's RFC6455, it's possible that control frames interleave with fragmented frames.

I don't understand the need for it, as it makes the design more complex for both sending and receiving part.

Currently, control frame can be "Close", "Ping" and "Pong" (everything else is reserved).

If the control frame is "Close", then receiving the end of the fragmentation is useless, so no interleaving would be required (the fragmenting side could just send the "Close" opcode and stop sending any more fragment, since you are not supposed to send anything after a "Close").

If the control frame is "Ping" or "Pong", it does not make any sense. The fragmenting side is sending data to the client, so why would it ask for pinging the client if it's alive (it has this information in the send system call already) ? Or reply to a ping immediately, since it's actually sending data to the client ?

So, why do we need this mechanism (of interleaved control frame) at all ?

Answer 1

It is to detect half open connections: http://blog.stephencleary.com/2009/05/detection-of-half-open-dropped.html

The other side could be sending you data, but unable to get your data. So being able of interleave pings and pongs, it is possible to check that at least the other end can understand your messages and reply to them.

It does not make it much more complex. You have to read delimited frames anyway, when you find a control frame, take action and continue reading more frames.

http://www.whatwg.org/specs/web-apps/current-work/multipage/network.html#ping-and-pong-frames

.3.4 Ping and Pong frames

The WebSocket protocol specification defines Ping and Pong frames that can be used for keep-alive, heart-beats, network status probing, latency instrumentation, and so forth. These are not currently exposed in the API.

User agents may send ping and unsolicited pong frames as desired, for example in an attempt to maintain local network NAT mappings, to detect failed connections, or to display latency metrics to the user. User agents must not use pings or unsolicited pongs to aid the server; it is assumed that servers will solicit pongs whenever appropriate for the server's needs.