[whatwg] General TCP connections API?
Charles Iliya Krempeaux
supercanadian at gmail.com
Thu May 26 14:26:29 PDT 2005
Hello,
Before I reply, first let me say that "asynchronous communication" is
only one problem (that needs to be solved). And my argument to
allowing TCP connections goes beyond this. And is wanted so that
other problems (besides "asynchronous communication") can be solved.
On 5/26/05, Joshua RANDALL FTRD/DIH/BOS
<joshua.randall at francetelecom.com> wrote:
> 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.
I think allowing the (client) developer to create TCP connections in
addition to other methods of doing asynchronous communications would
be good. Let me elaborate.
I do agree that if we forced the developer to use raw TCP connections
to do asynchronous communication, it would be bad. I agree that there
should be a method that integrates seamlessly with the "system".
(This ensures good "developer usability".)
However, sometimes a developer gets a problem where the current
technologies are all inadequate. A developer then has to work at a
"lower level" to create a system to solve his problem.
If we also allowed developers to create TCP connections, then, if the
need ever arised, they would have the option to use them.
> 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.
That's a good point.
However, I think that we should allow TCP connections, even if it
won't work in some cases.
For example, often people access the web on a computer at a cafe or
school that does not have an e-mail client. In these cases the
"mailto" URL will not work. However, we still allow the "mailto" URLs
in webpages.
Also, it could be the case that a network (on an office) bans outgoing
connects on any port other than 80 (for HTTP) and 443 (for HTTPS).
This would stop FTP URLs from working. However, we still allow "ftp"
URLs in webpages.
In other words, "let me use it when I can use it". (Since we are
already following this principle on the web.)
> 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.
That's a really good point. Perhaps I should explain my motivation.
What I want is better "building blocks" for building web applications.
There have been times when what I want to do can't be done with HTTP,
JavaScript, CSS, XML, HTML, etc.
Doing asynchronous communication is only one problem. However, my
argument for TCP connections is NOT only for asynchronous
communication. But to let (client) developers solve a larger set of
problems.
For example, let's say I want to stream images, or video, or audio,
from the client to the server. (Let's ignore where these are coming
from for now.) And that there were some high "performance" demands
for this that HTTP couldn't meet. (Like, for example, if I wanted to
push 24 frames per second from client to server.)
What do I do? HTTP isn't sufficient. server-event won't help.
Creating my own custom protocol would.
> 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?
If the only problem I was trying to solve was asynchronous
communication, then I would say that this is sufficient. However,
this is not sufficient for all problems. (See my example above.
Although maybe I don't understand server-event well enough. If I
don't seem to understand it. and it does solve the problem, please
explain it to me.)
See ya
> 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/
>
>
--
Charles Iliya Krempeaux, B.Sc.
charles @ reptile.ca
supercanadian @ gmail.com
___________________________________________________________________________
Wikibooks, Free Open-Content Books http://wikibooks.org/
More information about the whatwg
mailing list