Re: [hybi] WS framing alternative

[Greg Wilkins <[e-mail]>]

Ian Hickson wrote:

> The server will know what the clients will generally be sending -- e.g. a 
> chat client is going to be expecting messages in the range of half a 
> kilobyte or less, generally.

Why will the server know what the client will be sending?

The application built on top of the server might well know what
it is expecting, and maybe that will be of a size within a know
range and maybe that wont be able to be influenced by users doing
silly things etc.

but the application knowing and the code that implements the protocol
knowing are two entirely separate issues.

The application could tell the server implementation what size
to expect - but insert all your arguments against buffer size
negotiation on the wire here as arguments against passing
buffers sizes from app to server.

Besides, you keep saying that the people programming this don't
know how to calculate their own messages sizes - so they don't
know the length and couldn't tell you anyway.



> On Fri, 30 Oct 2009, Greg Wilkins wrote:
>> I think having the ability to negotiate such parameters is a good way to 
>> fail fast if a server and client are not compatible (eg client needs to 
>> send larger messages than server is willing to receive).
> 
> How could that ever happen? A client isn't ever going to just randomly 
> connect to a WebSocket server and start sending messages -- it's only 
> going to send messages the server wants to support.

People write new versions of software
Utilities and debugging tools can be written to talk to more than one server.
Mysterious intermediaries are inserted between you and the server.
Layered protocols are written on top of websocket that have options.
Programmers make mistakes



>> However, the problem with making this kind of negotiation optional (and 
>> this goes for my earlier examples of a load balancer communicating SSL 
>> info and/or node stickyness), is that the current WS protocol has no 
>> place for meta data to be added in an optional manner - so that it can 
>> be ignored by implementations that don't care.
> 
> Sure, you just put them in the frames, as part of the higher-level 
> protocol.

But unless you allocate a standard flag for meta data, then
implementations that don't implement these optional features will
crash because they don't understand these injected frames.

If a ws client connects to a ws server, and neither knows if
the other supports some layered protocol - how do they discover
that? neither one can just send a message asking, because it
will break the other end if they don't support it!


>> This limitation of no standard meta-data paths, means that it is nigh 
>> impossible to introduce features like multiplexing, load balancing, 
>> fragmentations, HTTP transport etc. as optional additional 
>> specifications built on top of ws.  Because there is no meta channel, 
>> simple implementations will treat everything as a message and break if 
>> there is any new protocol layered on top.
> 
> This is either completely false, or we have dramatically different goals.

Let's say that we have dramatically different goals.... sometimes that
happens and the sort of changes I'm minimally asking for are absolutely
trivial to the protocol and you can meet your goals and I can meet mine.



> Given the goal of just providing TCP for Web pages, it doesn't really make 
> sense to have a more involved protocol.

I'm not asking for a more involved protocol.
I'm asking for 1 bit to be allocated to indicate that a frame
contains mime-encoded data.    That is mostly sufficient
for layered protocols to be built on.



> It *would* make sense if your goal is something else, like tunneling 
> Jabber over HTTP or something. But that's a different project than 
> WebSockets. It's probably a perfectly reasonable thing for Hybi to work 
> on, but it should be articulated as its own project.

The sensible way to proceed would be to develop a simple but
extensible protocol that provides bidirectionality over the
web for all types of clients.

This can then be extended and/or layered upon for each type
of client.   So browsers could add on their origin security model
for example.

>From a servers/intermediaries point of view, browser are just
not that special that they deserve their entirely their own
protocol.




> I think you are misunderstanding the point of the frame types.

yes - kind of on purpose.

The WS Frame "byte" is really a frame bit, which is also
used indicate content-type (or at least content-encoding).

There are  7 unused bits in that byte. Allocating 1 of them
to indicate a meta data frame seams an entirely simple and
reasonable way to address one of the major concerns raised
by many people on this list.

Are you really saying you need to reserve space for 254 more
types of framing?

It's not like you are suggesting alternative ways to solve
the issues that we are raising.  You just keep saying "these
are not the droids that you are looking for....".  ie you
just say that the problems we raise are not problems for
you, so you don't care about them.


regards