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?
"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."
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.'
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.
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.
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.
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.
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.)
Your average web programmer doesn't even check for SQL injection or XSS attacks. Your average web programmer though, likes to adopt new technologies because of some "buzz." Your average web programmer will read the basic tutorial, which will cover examples, which are not to be used in a production environment. However these examples will make their way into production environments and we'll see a bunch of attacks pop up. I hope I'm wrong, but we'll have to wait and see..
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."