[whatwg] Suggestion of an alternative TCPConnection implementation

> Correct me if I am wrong: no two-way TCP daemon like telnet, ssh, POP3, NNTP
> or IMAP allows reconnecting to an existing session when the connection drops
> and for UDP daemons this question is moot because the connection never drops
> although it can occasionally fail.  Why should a custom connection from
> inside the browser make an exception?

One of the suggestions is creating a special protocol for
bi-directional communications with the server. The other suggestion is
creating a pure TCPConnection.

The pure TCPConnection should not specify a protocol, and it should be
able to connect to any port, for example telnet, SSH, POP3 etc.

My suggestion should replace only the special protocol variant and be
based on http/xmlhttprequest like this:

1. Client connects to web server
2. Web server and client communicates and establishes communication
trough the same socket pairs as the web page itself was transmitted
trough.
3. The client can then continue communicating with the server trough a
singleton object document.webSocket.

What happens in the background is the following:

Server starts a new thread or forks a new process to handle the
communication trough the channel. The server use the Session ID header
to match the client with the correct process on the server.

If the client is disconnected, then the next communication
reestablishes the connection using the session id header to match the
client with the correct thread on the server. This will be transparent
to both the server side script and the client side script - and I
believe it will work trough existing proxy servers.


The same type of communication channel can then be established by
scripting, for example like this:

var socket = new WebSocket("http://url/path/to/script.php");


This has the following benefits:

1. No security problems to worry about: Server decides if the request
should be handled as a persisting socket . If the server side script
is not persistent - then the request will be handled as a normal http
request by the server and the WebSocket object should cast an
exception.
2. Use existing protocols (HTTP), in a backward compatible way.
3. Since it uses the existing communication channel, it will always
work trough firewalls.
4. It supports virtual hosting by default.
5. It supports full URLs, including the path by default.


The disadvantage is that to utilize the feature, web servers must be
updated to support WebSockets - but I do not think that's different
from requiring special servers anyway.

Frode

Received on Thursday, 19 June 2008 05:01:59 UTC