

Comet Breakthrough: Socket for JavaScript in the Browser - jacobolus
http://cometdaily.com/2008/07/01/sockets-in-the-browser/

======
nirmal
So this is just a better framework on top of HTTP Bind? It's not true sockets
because I still can't open up many simultaneous connections. The max-
persistent-connections-per-server was what always annoyed me when it came to
using this type of architecture.

Has anyone seen code that manages to multiplex a single connection of this
type across multiple tabs within a browser? Is that even possible?

From: <http://www.orbited.org/wiki/CherryChat>

_"Then point your browser at<http://localhost:4700/static/chat.html>, and then
open a second browser window and point it at
<http://127.0.0.1:4700/static/chat.html>, and test the application. It’s
important to use the two different hostnames localhost and 127.0.0.1 because
some browsers limit the number of open connections you can have to each
hostname to two. With this limit it is impossible to run two instances of the
chat application on the same host. Of course, 127.0.0.1 and localhost should
refer to the same local machine, so its a good way of tricking the browser
into thinking its talking to separate servers."_

------
axod
Misleading title. Not a breakthrough, no new technology, just a different way
of explaining it.

~~~
brooksbp
Can't stand crap like this. People who reinvent the wheel (poorly), or try to,
make the world a worse place... something related to 'visualization' --
psychological stuff. People who fail to visualize and truely, intimately
understand things will often invent breakthrough technology as JavaScript
'sockets.'

~~~
franksalim
Hi, Many of the comments here are negative, probably due to the overly
sensational title ;-) Since this is a project I have been working on, however,
I will do my best to clarify and respond candidly.

This is clearly not a breakthrough. Sockets (or socket-like interfaces) are
the most obvious way to communicate a bi-directional stream of bytes. This has
been true for decades. The problem is that everybody has been trying to
reinvent the wheel for AJAX. So yes, this is not new, just something that had
been missing from the web for a long time!

We have been very mindful of the security implications. Orbited uses a strict
whitelist and will not allow outgoing connections to addresses (hostname:port)
that are not listed in the access configuration.

Feel free to ask me any questions.

-Frank Salim

------
heyadayo
This isn't new technology, but its a more reasonable way of thinking about
real-time communication in a browser. Developers know how to use sockets, so
we give them a socket.

In a years time this will be native in all browsers anyway:
<http://www.whatwg.org/specs/web-apps/current-work/#network>

------
dhotson
I wonder if this could be combined with this javascript jabber library to make
a fully fledged chat client: <http://zeank.in-berlin.de/jsjac/>

.. currently that library is restricted by the same domain policy. I wonder
how this Comet library manages to get around it.

Anyone here care to explain?

~~~
Tichy
I think it proxies through a server, it is not a real socket.

~~~
jherber
this is exactly what it is doing. it's a javascript lib that exposes an ajax
connection (fancifully named "TCPSocket") that is proxying a socket connection
through the Orbitd server. if there isn't strict control of client IP
addresses and outgoing IP/port at Orbitd, then you should expect folks are
going to abuse/hack your server for proxying who knows what from where.

~~~
apgwoz
This is going to be a giant security nightmare.

~~~
SwellJoe
This seems to be the instinctive response of developers in other areas when
exposed to a new client-server system...particularly a proxy or relaying
system.

But is BIND and the DNS system a "security nightmare"? Is Squid a security
nightmare? Apache's mod_proxy, a security nightmare? Postfix or Sendmail or
Qmail or Exim, all security nightmares? IRC? OK, maybe SMTP and IRC are
security nightmares...but, one could easily argue that it's because their
goals include "many-to-many open communication", and not because securing them
would be difficult. After all, IMAP/POP3 moves mail around, just like SMTP,
and it manages to be locked up nice and tight without even trying very hard.

I'm not saying Orbited _isn't_ a security nightmare. I'm just saying that it's
a client-server proxying and/or relaying system, just like all of the systems
listed above, and that does not, by definition, make it a security nightmare.
If the developers have experience building proxy systems and/or take the time
to understand the security requirements of such a system, it'll be just fine.
Just because securing a particular technology is sorta hard, doesn't mean you
shouldn't build the technology. It just means you need to allocate some of
your development resources to solving those security problems.

~~~
notauser
This is a bit different to normal applications though.

Normal apps: Developer writes application. Code is installed via user
engagement with a package management or installation system.

Comet apps: Developer writes application. Code is pulled and executed by
(almost) every vistor to the website it is deployed on.

If the code could open sockets to arbitrary destinations then a high traffic
site could be used to spawn a very effective DDOS or distribute hacking
attempt.

Of course for Orbited this isn't relevant as the browser security model limits
connections to the originating host. So you can't, say, embed javascript into
Slashdot.org that does:

End users >>> DDOS attack target.

Instead you get:

End users >>> Slashdot.org proxy >>> DDOS attack taget.

(Which is obviously a total waste of time as any attack via this method would
be predicated on having control of Slashdot.org in the first place.)

------
tlrobinson
Ok, neat, but this has ridiculous security implications. Anyone can now open
up a socket on my server for any purpose they want (hax0ring, etc)

At the very least there should be ways to limit the hosts and ports of the
sockets, but even then I'd be very cautious about using this.

------
bsaunder
I can't wait for UDP over HTTP in Cometd 0.6 ;)

~~~
axod
In case this wasn't obvious, but UDP is simple as it's sent from the server,
not the browser.

