[whatwg] General TCP connections API?

Thu May 26 13:19:46 PDT 2005

Charles,

You state the need for real asynchronous communications between server  
and client, and you are absolutely right that it is critically  
important to have that for real web applications.  However, I believe  
it would be shortsighted to solve the problem by creating an API to  
make TCP connections from within a web application.  Aside from  
security concerns, there are three major issues I see with that  
solution.

Firstly, it exposes a very low level protocol to the programmer of the  
web application, forcing them to code higher-level protocols themselves  
from within ECMAScript.  While certainly this would allow a high degree  
of freedom on web application programmers, it would also put an  
unnecessary burden on them when a higher-level, simpler solution would  
have sufficed.

Secondly, it probably wouldn't work in all cases -- for example clients  
that require the use of a proxy server to access the network, or are  
behind a firewall that allows only HTTP connections.

Finally, it assumes that TCP connections are the best way to get data  
from the server to the client.  While this is almost certainly the case  
for desktop computers, it may not be a good assumption for mobile  
terminals.  Operator networks might in the future have built-in  
eventing protocols that can more efficiently dispatch data  
asynchronously to client devices without the need for the overhead of  
maintaining many virtually unused TCP connections.

Luckily, there is already a proposed solution, part of which is  
included in the Web Applications draft.  In section 9.1 of the draft  
(http://www.whatwg.org/specs/web-apps/current-work/#server-sent) a  
framework is proposed that allows for asynchronous communications from  
server to client by way of server-sent DOM events.  Basically, the  
server-sent DOM events would allow a web applications programmer to  
make an API call to register for a remote event located at a particular  
URI (on a server), and to subsequently receive DOM events when they  
arrive from that server.  The details of the low-level connection are  
left up to the user agent and the server to manage, rather than  
requiring scripted code to handle them.  And, while the section in the  
current draft shows examples using event sources at HTTP URIs, it  
leaves the door open for them to be located at other URIs as well.

Do you see any reason why you couldn't achieve everything you needed  
using this method rather than by having low-level TCP connections  
exposed in the API?

I did notice that, while the server-sent DOM events described in the  
current draft address by first two concerns, the third one has not been  
specifically handled, although I suppose it is left open by allowing  
other non-HTTP protocols.

However, since ideally the same web application code would work on all  
platforms and networks, it would be better if there was a way to  
negotiate the low-level transport between the client and server rather  
than have it hard-coded into the script.  For example, a web  
application showing real-time stock prices wants to get an event stream  
that updates the stock prices from a server, let's say stockserver.org.  
  For most desktop clients, using the event-source URI  
"http://stockserver.org/stockprice" would be fine.  However, a mobile  
client using the same page would waste a (relatively) lot of bandwidth  
just by keeping that HTTP connection alive, and it so happens that the  
particular (and fictitious) mobile network has low-level support for  
SIP events (could just as easily be XMPP or perhaps even SMS or  
WAP-Push).  Therefore, for that client it would be advantageous to use  
a URI such as "sip:stockserver.org;subscribe?event=stockprice" instead  
of HTTP since there would be significantly less network overhead that  
way.  However, it is undesirable for the web application developer to  
have to provide a separate version of the page for the mobile user on a  
SIP-capable network, so it would be advantageous to have an option for  
the server and client to negotiate the low-level transport.  Perhaps  
this could be done using an extension to the proposed baseline  
HTTP-based implementation?

Ian, perhaps we could add to section 9.1 a header that can be sent by  
the user agent along with the initial request to the event-source URI  
that specified a list of event protocols that the user agent supports?   
Perhaps something like "capabilities"?  Then, the server, knowing what  
the client support was, would have the option of returning a 3xx  
redirect to the other protocol URI instead of opening the event stream?  
  If for some reason the user agent was unable to establish the event  
stream using the new protocol, it could re-contact the server but  
remove the failed protocol from it's list of capabilities.  This seems  
to me to be the least obstrusive way of adding basic protocol  
negotiation to the server-sent DOM events -- do you see any reason why  
it shouldn't be in there?

josh.

On May 26, 2005, at 3:08 PM, Charles Iliya Krempeaux wrote:

> Hello,
>
> (Please excuse me if this has already been discussed.  I'm still
> working my way through the mailing list archive.  Also, I hope I'm not
> out of place by just interjecting myself.)
>
> Are there any plans to add an API to create TCP connections?
>
> IMO, this is very necessary for creating "web applications".  And it
> would be unfortunate if it wasn't included.
>
> Right now, there seems to be a new fad revolving around
> XmlHttpRequest.  It has been nicknamed AJAX by many.  And heralded as
> a means of asynchronous communication for the Web.  However, AJAX only
> gives the illusion of asynchronous communication between the server
> and client.  The client is polling the server.  And often a new TCP
> connection is created (and later tore down) each time the server is
> polled.  (Which, IMO, is bad.)
>
> The nice thing about XmlHttpRequest is that it makes it so you can
> "update" a webpage without having to reload it.  Which improves
> usability.  However, because of the polling, performance is adversely
> affected.  Not to mention that polling is not the optimal mode of
> communication.
>
> One could come up with a new protocol for asynchronous communication.
> (Maybe as something to accompany HTTP.  Or maybe even as an extension
> to it -- HTTP 1.2?)  Which may solve this problem.  But other
> "problems" could arise in the future.  It would be good to provide
> developers (of web applications) the building blocks to solve a wider
> set of problems.  And to me, I think having an API to create TCP
> connection is one of these building blocks.
>
> Some might say that letting the client create general TCP connects
> would bring up all sorts of security concerns.  However, I think these
> security concerns can be dealt with by making it so the API would only
> allow the client to create a TCP connection to the "host" that the
> client -- the webpage (or web application) -- came from.
>
> Or, alternatively, we could allow the host that the webpage (or web
> application) came from to specify a list of domains (or IP addresses)
> that clients could connect to.  (Of course, there would be
> restrictions on this.  The hosts in that list would need to "allow"
> the original host to do this.  A mechanism for this would need to be
> created.)
>
> There could even be other restrictions.  For example, a host could
> specify what ports it allows webpages (and web applications) to
> connnect to.
>
>
> So,... are there any plans to add an API to create TCP connections?
>
>
>
> See ya
>
> --  
>      Charles Iliya Krempeaux, B.Sc.
>
>      charles @ reptile.ca
>      supercanadian @ gmail.com
> _______________________________________________________________________ 
> ____
>   Wikibooks, Free Open-Content Books                   
> http://wikibooks.org/