Changeset 310 for branches/0.5/articles/mcarter/0.5_world_announcement

Show
Ignore:
Timestamp:
06/24/08 15:39:27 (7 months ago)
Author:
heyadayo
Message:

Updates to firewall description, various announcements, and removal of the JSNAP announcement

Files:
1 modified

Legend:

Unmodified
Added
Removed

  • branches/0.5/articles/mcarter/0.5_world_announcement

    r309 r310  
    99I say we've been selling ourselves short. All this time pushing for a native server->client streaming transpor, but we still lack client->server streaming, and anything resembling a standard transport for bi-directional comunication. The Holy Grail of Comet development has always been native browser support of a full-duplex, single-connection communication's channel, otherwise known as a TCP socket. But we've been mired down in hacks so long that we've lost the vision. 
    1010 
    11 No Longer. I am excited to announce that the HTML5 specification now offers [WebSocket](http://), a full-duplex communications channel that operates over a single socket. I have been working closely with the specification authors to ensure that WebSocket will: 
     11No Longer. The HTML5 specification now offers [WebSocket](http://), a full-duplex communications channel that operates over a single socket. I have been listening closely, and in some cases contributing, to the process of ensuring that WebSocket will: 
    1212 
    1313    - Seamlessly traverses firewalls and routers 
    … …  
    4040Q: Is there planned support for Binary data transport once future javascript specifications include native byte data types? 
    4141 
     42 
    4243WebSocket in a browser is terrific because it drastically cuts down the complexity of the Comet server by an order of magnitude. Whats more though, it provides a straightforward, understandable API to javascript developers. The most important part of the specification is that *developers can wrap their heads around the api in about five seconds.* Thats because it looks so much like a socket. 
    4344 
    … …  
    4748--------- 
    4849 
    49 The single most voiced criticism to this specification has been that a WebSocket isn't quite the same as a raw TCP socket, and as such a WebSocket can't connect to existing servers. This is very deliberate though, as it secures an otherwise major security hole. A malicious site could cause any visitors to open up a tcp connection to an smtp server, for instance, turning a casual web visitor into a spambot. There are many variations on this scenario, but the general problem is that browsers have been historically unable to connect to arbitrary servers. We need to therefore make this an opt-in process or we'll catch existing servers off-guard. Furthermore, very few protocols have any kind of cross-domain authorization or security mechansisms built in. If we were to allow raw TCP, then we would be opening all manner of cross-site security holes. We could fix these by limiting TCP connections to the origin domain and port, (meaning a direct sockets back to the webserver only) but that would limit any usefulness the TCP socket could provide. 
     50The single most voiced criticism to this specification has been that a WebSocket isn't quite the same as a raw TCP socket, because a WebSocket server needs to understand a specific handshake in order for browsers to connect directly, and as such a WebSocket can't connect to existing servers.  A malicious site could cause any visitors to open up a tcp connection to an smtp server, for instance, turning a casual web visitor into a spambot. There are many variations on this scenario, but the general problem is that a raw socket connections in a browser will allow any sites that a user visits to access network services as if they were the user, in the same network security context as the user. We need to therefore make this an opt-in process or we'll catch existing servers off-guard. Furthermore, very few protocols have any kind of cross-domain authorization or security mechansisms built in. If we were to allow raw TCP, then we would be opening all manner of cross-site security holes. We could fix these by limiting TCP connections to the origin domain and port, (meaning a direct sockets back to the webserver only) but that would limit any usefulness the TCP socket could provide. 
    5051 
     52I fully understand the criticism though; if we could use existing network servers in browser applications, formerly difficult problems vastly simplified. Lets take Gmail as a brief case study. The gmail application features a nice gui that clearly took some time to build. The real trouble with building Gmail is figuring out a way to bridge email notification to the browser. You could create a server that uses IMAP to discover the new messages, then use a Comet transport to push those messages to the browser. You also need to write a similar adapter for XMPP. That means you'll need a server that acts as an XMPP client for each user and transcodes the XMPP protocol to something JSON-based for easy access in the browser. While this isn't rocket science, its damn hard. 
    5153 
    52 I fully understand the criticism though; if we could use existing network servers in browser applications, formerly difficult problems are a snap to solve. Lets take Gmail as a brief case study. The gmail application features a nice gui that clearly took some time to build. The real trouble with building Gmail is figuring out a way to bridge email notification to the browser. You could create a server that uses IMAP to discover the new messages, then use a Comet transport to push those messages to the browser. You also need to write a similar bridge for XMPP. That means you'll need a server that acts as an XMPP client for each user and transcodes the XMPP protocol to something JSON-based for easy access in the browser. While this isn't rocket science, its damn hard. 
     54On the other hand, assume that your base tools include a pure-Javascript IMAP and XMPP client in the browser. On page load the browser can ask the IMAP server directly for the 20 most recent emails, including their send times, read status, and subject. Next, the browser can issue an IDLE command which will cause the IMAP server to send immediate notification of any new mail. The browser also can connect to the XMPP server and send/receive presence information to/from the user's buddy list. Message dialogs and typing notifications are all handled by callbacks attached the XMPP client, and sending messages to buddies is a trivial one-liner. There's not a whole lot else to do besides make a great GUI, which can take as much time as you can give. 
    5355 
    54 On the other hand, assume that your base tools include an IMAP and XMPP client in the browser. On page load the browser can ask the IMAP server directly for the 20 most recent emails, including their send times, read status, and subject. Next, the browser can issue an IDLE command which will cause the IMAP server to send immediate notification of any new mail. The browser also can connect to the XMPP server and send/receive presence information to/from the user's buddy list. Message dialogs and typing notifications are all handled by callbacks attached the XMPP client, and sending messages to buddies is a trivial one-liner. There's not a whole lot else to do besides make a great GUI, which can take as much time as you can give. 
     56I'm not trying to cast a shadow on the engineering behind Gmail -- its a brilliantly engineered product. We've been stuck with web application servers (read, jumped up HTTP servers) for so long though, that we take complicated architecture for granted. I'm just pointing out that you don't need to be a brilliant engineer to create gmail if you have the right tools. The right tools aren't web application servers, they're sockets and clients, and with those tools we could put together a tutorial titled "How to write your own Real-time Email/Chat application in 20 minutes." 
    5557 
    56 I'm not trying to cast a shadow on the engineering behind Gmail -- its a brilliantly engineered product. We've been stuck with web application servers (read, jumped up HTTP servers) for so long though, that we take complicated architecture for granted. I'm just pointing out that you don't need to be a brilliant engineer to create gmail if you have the right tools. The right tools aren't web application servers, they're sockets and clients, and with those tools we could put together a tutorial titled "How to write your own Email/Chat application in 20 minutes." 
     58We have a clear problem then: Direct access to existing network servers could greatly simplify application architecture, but due to security restrictions its a non-starter; we absolutely must retrofit each network server with the new WebSocket protocol first. I hope that happens, but we can't count on it, at least not for years. What we really need is a way to allow the server to opt-in without putting it in the protocol, a way to seamlessly layer access control in front of the back-end server. It turns out that this problem has already been solved for traditional networks. That is, if we have two end-points  communicating over tcp,  and we need transparent access control in between, then we can use a well known device: A firewall. The beauty of a firewall is that server behind it requires no re-programming, or even re-configuration, yet gains all of the access control/security benefits. What we really need in the browser case, is a custom firewall that can listen for WebSocket connections from the browser, enforce access control, and relay tcp to a back-end server. 
    5759 
    58 We have a clear problem then: Direct access to existing network servers could greatly simplify application architecture, but due to security restrictions its a non-starter; we absolutely must retrofit each network server with the new WebSocket protocol first. I hope that happens, but we can't count on it, at least not for years. What we really need is a way to allow the server to opt-in without putting it in the protocol, a way to seamlessly layer access control in front of the back-end server. What we really need is a firewall that can speak WebSocket protocol to the browser, enforce access control, then speak tcp to the back-end. 
    59  
    60 I am again proud to announce that Orbited supports this feature under the api name TCPSocket. Orbited is the firewall that sits between the back-end server and the browser. It understands WebSocket protocol for browser communication, and uses whitelist security to accept or reject requests to proxy tcp data to and from a back-end server. Thats right, you can fire up a stock XMPP server, and Orbited, and write the XMPP client entirely in javascript. This works cross-browser this very day. We also offer a BinaryTCPSocket that uses an intermediate encoding to allow the browser to read raw bytes (in the form of javascript integer arrays) from a remote server. 
     60I am proud to announce that Orbited supports this feature under the API name TCPSocket. Orbited is the firewall that sits between the back-end server and the browser. It understands WebSocket protocol for browser communication, and uses whitelist security to accept or reject requests to proxy tcp data to and from a back-end server. Thats right, you can fire up a stock XMPP server, and Orbited, and write the XMPP client entirely in javascript. This works cross-browser this very day. We also offer a BinaryTCPSocket that uses an intermediate encoding to allow the browser to read raw bytes (in the form of javascript integer arrays) from a remote server. 
    6161 
    6262The Future 
    6363---------- 
    6464 
    65 Once you have a tcp socket in the browser, no web application architecture is impossible, or even that hard. Only now its apparent how far javascript is behind all other programming languages for networking support. We need to start developing every major protocol in javascript. For now, Orbited ships with STOMP, IRC, and XMPP implementations, but we plan on soon shipping a Daemon capable of serving implementations of all major communication protocols. 
     65Once you have a tcp socket in the browser, no web application architecture is impossible, or even that hard. Only now its apparent how far javascript is behind all other programming languages for networking support. We need to start developing every major protocol in javascript. For now, Orbited ships with STOMP (ActiveMQ and RabbitMQ), IRC, and XMPP implementations, but we plan on soon shipping a Daemon capable of serving implementations of all major communication protocols. 
    6666 
    6767These developments will transform the way we think about the web. Many thick-client systems don't have to be re-engineered for the web -- its just a matter of writing a GUI. Its conceivable to write a fully featured browser application with no web application server whatsoever. All the applications that use the complicated architectures to bridge various protocols to the browser over HTTP are simplified many times over. Javascript developers are now able to create complex application without any server-side programming whatsoever.