[whatwg] WebSocket support in HTML5

Hi Philipp,

> After all, more or less the only situation you'd want to use UDP

Wrong. But then personally, I'd use UDP for server-generated events, and
something other than a context-devoid, connection-less, session-hijackable,
bollocks protocol as my middleware backbone; I am clearly 180 degrees in the
minority :-)

> That out of the way, I think the "structure in content" approach is
> preferable because in the end it makes the whole feature easier to use
> and accessible to a much broader range of web authors. Because a WS
> stream has standardized metadata and delimiters, you can easily build
> a generic framework that processes those parts for you.

Fine, you want "structure in content" then you stick it on *afterwards*.
Please don't impose your particular views on what everyone else's data
stream should look like! Some might like chunking, record-type indicators,
or data-length sentinels, or something completely different; it's up to
them!

Anyway, I believe Shannon has come up with a very workable ws.read(bytes)
and ws.write(bytes) alternative.Spookily, just like a Socket - amazing. Well
done.

> Note that it was a conscious design decision to make WS incompatible
> with existing protocols, because the risk for misuse is too great.

Excellent, so WebSockets have been deliberately ham-strung by design? Now
that explains a lot :-(

Even if I was less paranoid I'd still smell a vested interest rat here "Yes,
you can have all the sockets you want as long as you are forced through our
HTTP servers to do it".

Cheers Richard Maher

----- Original Message ----- 
From: "Philipp Serafin" <phil127@gmail.com>
To: "Kristof Zelechovski" <giecrilj at stegny.2a.pl>; <whatwg at whatwg.org>
Sent: Monday, September 29, 2008 7:18 PM
Subject: Re: [whatwg] WebSocket support in HTML5


> On Sat, Sep 27, 2008 at 12:58 PM, Kristof Zelechovski
> <giecrilj at stegny.2a.pl> wrote:
> > If you are in control of the server, you can simulate datagram sockets
with
> > one-shot controlled sockets
>
> I do not agree with Richard at all, but I have to play devil's
> advocate here because I think such a simulation would be pretty
> useless.
> After all, more or less the only situation you'd want to use UDP
> outside a LAN is when TCP doesn't fit your needs, e.g. because the
> flow control does more harm than good to your use-case or because your
> peers have not enough processing power for a full TCP implementation.
> Simulating UDP via TCP would pretty much combine the disadvantages of
> both protocols.
> Also, you already need a full roudtrip to initiate a TCP connection, a
> second one to perform the WS handshake and a third one to close the
> connection. Data not taken into account. You can hardly repeat that
> for every datagram you want to send.
>
> That out of the way, I think the "structure in content" approach is
> preferable because in the end it makes the whole feature easier to use
> and accessible to a much broader range of web authors. Because a WS
> stream has standardized metadata and delimiters, you can easily build
> a generic framework that processes those parts for you.
> This is especially important if you DON'T have full control over the
> server, which I believe is the case for the majority of smaller sites
> that use a shared hosting solution. Those hosters usually don't give
> their clients access to the underlying processes at all. All the
> clients can do is upload static files and script files that get
> executed in a restricted environment. It's really hard to integrate
> pure, persistent connections into such a setup. With WS, a hoster
> could for example have a demon listen to all incoming WS connections
> and call the client's scripts whenever a data frame has been received.
> In short, it's much easier for them to manage persistent connections
> if there is a standardized structure. And if it's easier for them,
> hopefully the support for this feature will grow.
>
> As for the restriction of unicode data, of course we could just use an
> octet counting mechanism like HTTP does instead of a fixed delimiter.
> This would allow arbitrary data inside the WS frames. On the other
> hand, this might make it easier to spoof existing protocols. Would the
> benefits of this outweigh the risks?
>
> Note that it was a conscious design decision to make WS incompatible
> with existing protocols, because the risk for misuse is too great.
>
> If you need your web app to inerac with a specific service, it should
> be easy to write a generic proxy that does the handshake, strips out
> the frame marks and transforms the data.
>
> Also, it's not like the other technologies would vanish all of a
> sudden. If you have sufficient control over your server, you can STILL
> use Java or Flash sockets.
>
> Regards,
> Philipp Serafin
>

Received on Wednesday, 29 October 2008 02:47:45 UTC