WebSocket framing
Martin Sustrik
What follows are some thought on SP running on top of WebSocket protocol
as defined here:
http://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol-12
First, the intended purpose of WebSockets is outlined as follows (seem
my comments inline):
o adds a Web "origin"-based security model for browsers
I have no opinion on this one. I guess that if it's useful for the web
applications in general it would be useful for web/SP applications as well.
o adds an addressing and protocol naming mechanism to support
multiple services on one port and multiple host names on one IP
address;
We've seen this requirement quite often with 0MQ. When topology is
deployed in such a way that it crosses enterprise boundaries, users
often want to funnel all the traffic through a single port so that
network admins don't have to be engaged and burocracy associated with
opening new ports in the firewall can be avoided.
However, in case of WebSockets (port 80/443) the SP connections would
have to coexist with standard HTTP connections. Combined with the fact
that only one application can listen on a particular TCP port it means
that either:
1. SP application has run inside the web server.
2. There should be a connection mutliplexer that listens on a port and
dispatches new connections either to web server or to one of other
SP-based services.
Experimental implementation of such multiplexer can be found here:
https://github.com/sustrik/vtcp
o layers a framing mechanism on top of TCP to get back to the IP
packet mechanism that TCP is built on, but without length limits
Yes. This is an explicit requirement for layer underlying the SP. The
WebSockets I-D doesn't mention message atomicity requirement, but that
can be easily addressed in the implementation.
o includes an additional closing handshake in-band that is designed
to work in the presence of proxies and other intermediaries
This improves the reliability somewhat, but is not crucial for SP to
work as expected.
---
Some more comments:
While WebSocket fragmentation can be used to allow for proper handling
of pings, SP/WebSocket framing should take care of never using WebSocket
fragmentation to do multiplexing as suggested in the section 5.4.
(Multiplexing on top of TCP breaks the semantics of TCP pushback mechanism.)
The SP frames should be marked as binary (opcode 0x2) so that SP layer
-- and application layer -- data won't be interpreted as text.
While it may be tempting to use WebSocket extension mechanism (section
9) to do things like distinguishing messages from commands via different
opcodes, we should make it clear that SP is a layer on top of WebSockets
and not an extention. The framing should be designed accordingly.
Thoughts?
Martin