[whatwg] web-apps - TCPConnection

[Ian Hickson]

On Mon, 17 Oct 2005, S. Mike Dierken wrote:

> > On Sun, 16 Oct 2005, S. Mike Dierken wrote:
> > >
> > > http://whatwg.org/specs/web-apps/current-work/#network
> > > 
> > > My only question is - why?
> > 
> > Imagine trying to play a game like Quake implemented in a Web 
> > page. You need bidirectional communication. 
>
> Okay. Outbound messages are obviously not a problem. Accepting 
> unsolicited inbound messages isn't feasible (& the unsolicited part is 
> an invitation to spam). Having the client initiate the connection & then 
> receiving/responding to inbound requests is what it sounds like you 
> would need. If the browser had an HTTP daemon built-in, would that work?

No, since you can't guarentee that incoming connections will connect (e.g. 
because you are behind NAT with no port forwarding, a very common case).

Also, requiring that UAs implement HTTP servers, as opposed to just 
implementing the simple TCPConnection protocol described at the moment, 
seems like a significantly more expensive way of solving this problem.


> > Another example would be something like an IM or chat client. All the 
> > current implementations of that are huge hacks that would be much 
> > simpler to implement if they could just open a TCP connection and send 
> > free-form data back and forth.
>
> I've implemented IM and chat applications with just HTTP, HTML and 
> Javascript. In a browser. Without plugins.

Yes, lots of people have. It would be a lot simpler with a bidirectional 
asynchronous text-based messaging protocol, though.


> The DOM Event portion of the specification is very similar & more than 
> sufficient for chat and IM.

That's one way of receiving messages, but it isn't as good for sending 
them. Using HTTP to send them requires some acrobatics on the server side. 
Using TCPConnection would just mean one process server side.


> It's unfortunate that port 80 would be needed to 'tunnel out', but I 
> realize that's the situation most people are in. But I really recommend 
> that a port 80 outbound tunnel use the protocol assigned to that port - 
> via the HTTP Upgrade header.

That would require that the Web author implement HTTP on his side (or at 
least a simple version of an HTTP server) which seems like undue work. 
What would the advantage be? We're not connecting to an HTTP server. 
Upgrade makes sense if you are upgrading from HTTP to something, but here 
we're not expecting HTTP to ever be used over the connection.


> > We don't want to require that authors implement an entire HTTP server 
> > just to be able to switch to a proprietary protocol.
>
> Nobody has suggested requiring an entire server. Two messages is all it 
> takes. Not only does HTTP scale up well, it scales down too.

No, because you have to implement correct handling of everything _other_ 
than Upgrade: as well, even if it is to return "Not Supported" each time. 
You have to parse headers, etc. Nobody is going to actually bother to 
correctly implement that, and if they don't, what's the point in 
pretending that they do? It would just make matters worse, with obscure 
per-server/client pair bugs for browsers to work around.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'