Wednesday, December 31st, 2008
Category: Comet
How about if all you needed to do was:
JAVASCRIPT:
-
-
var server = new Addressable.Server({ useGears: true });
-
-
server.onmessage = function (message) {
-
log(message)
-
}
-
-
server.connect(function (id, url) {
-
log("Connected. Messages will appear here.")
-
$("#clientId").html("Client-Url: "+url)
-
$("#testForm").attr("action", url)
-
})
-
-
function log(msg) {
-
var log = $("#log");
-
log.html(""+msg + "<br />" + log.html())
-
}
-
And you would have Comet end points to play with?
That is what Malte has given us with a proof of concept called UniversalComet:
I have developed a JavaScript library that makes it extremely easy to incorporate "comet" or server-push technology into any web application without need for special programming or any special support on the server. Ressources needed on the server are also practically zero.
When you use the JavaScript library, you will receive an URI that identifies the client. Now you can make simple HTTP-GET requests to that URI with a message parameter and the client will receive the message immediately. Because only your application will know the un-guessable URI, the client should be save from unwanted messages. The use of HTTP-GET messages also allows sending messages in a "P2P"-fashion from client to client using JSONP cross-domain-messages.
The function that is passed to the connect-method receives the URI of the client and as soon as messages arrive they will be send to the onmessage-callback.
The JavaScript application uses "channels" to differentiate between different windows that the same client has open at any given time. These are cached in window.name. If you set window.name yourself this value is used. You can also set server.setChannel("myChannel") before you connect to name the channel yourself.
You can check out the demo.
Monday, December 29th, 2008
Category: Comet
Kaazing keeps on moving with its Java Comet server, and just released a new version. It will be interesting to see if real-time connections take off in 2009.
Kaazing is happy to announce the second major release of its Kaazing Gateway, an open source HTML 5 web server, which includes support for HTML 5 WebSockets. With the 8.12 release of Kaazing Gateway delivers even more HTML 5 features such as Server-sent Events, more advanced security services, and extended support for XMPP (Jabber) and STOMP (e.g. ActiveMQ, RabbitMQ, or OpenMQ).
Server-sent events make a substantial contribution to the HTML 5 specification; however, Kaazing Gateway makes that contribution even greater by enabling Broadcast Notifications, which makes it possible to send messages from a TCP-, UDP-, or Multicast-origin and deliver simultaneous updates to tens of thousands of end-users. Applications of Server-sent event broadcasting include sporting event updates, system notifications, financial market updates, and much more.
Kaazing Gateway's HTML 5 emulation libraries also include a number of updates. The libraries now enable any modern browser to support HTML 5 Server-sent Events, and introduce support for HTML 5 postMessage, which facilitates cross document messaging. Kaazing's HTML 5 libraries also include support for HTML 5 Offline Storage, which provides simple DOM-based storage solution. Kaazing Gateway and its client libraries also now provide support W3C Access Controls for Cross-Site Requests, which is a mechanism to enable client-side cross-site requests, better known as Cross-site XmlHttpRequests.
Beyond extended support for HTML 5, Kaazing Gateway 8.12 also provides more advanced XMPP features such as group chat. This release also introduces STOMP-JMS Adapter, which allows you to adapt any existing Java Message Service (JMS) services (e.g. JBoss Messaging, Tibco EMS, OpenMQ, SwiftMQ, WebSphere MQ, etc. ) for use with Kaazing Gateway.
Friday, October 31st, 2008
Category: Comet, HTML
Kaazing has released Kaazing Gateway, an open source HTML 5 WebSocket Server.
The HTML 5 WebSocket specification is a standard that attempts to simplify much of the complexity around achieving bi-directional communications between browsers and servers. The specification provides a simple JavaScript interface that enables developers to open a full-duplex socket connection and connect directly to any TCP-based back-end service (for example, JMS, JMX, IMAP, Jabber, and so on).
Kaazing Gateway makes it possible for developers to take advantage of WebSockets today by providing a JavaScript library that emulates the HTML 5 WebSocket, making it possible to build applications that leverage the WebSocket interface and that can be deployed to both modern and future browsers.
The ultra high-performance server behind Kaazing Gateway can support tens of thousands of concurrent connections on a single node. Multiple instances can be clustered with traditional HTTP load-balancers or DNS round robin, making it possible to support any number of persistent client connections. In addition to large numbers of connections, Kaazing Gateway can also handle high data throughput thanks to its high-performance, staged event driven architecture (SEDA).
The Atlantis release of Kaazing Gateway also comes prepackaged with JavaScript clients for popular message services such as Apache ActiveMQ and RabbittMQ as well as clients for XMPP services such as OpenFire, Jabberd, and other popular chat servers. This makes it easy for you to quickly build web-based chat applications or messaging applications such as stock matrixes, online trading platforms, or online games.
What is the WebSocket API?
JAVASCRIPT:
-
-
interface WebSocket {
-
readonly attribute DOMString URL;
-
-
// ready state
-
const unsigned short CONNECTING = 0;
-
const unsigned short OPEN = 1;
-
const unsigned short CLOSED = 2;
-
readonly attribute int readyState;
-
-
// networking
-
attribute EventListener onopen;
-
-
attribute EventListener onmessage;
-
attribute EventListener onclosed;
-
void postMessage(in DOMString data);
-
void disconnect();
-
};
-
Wednesday, October 29th, 2008
Category: Comet
Comet is starting to gain steam, although mainly through the term "real-time Web." A couple of the Comet folks posted at the same time, both talking about the technology in different ways.
Ted Goddard answered a bunch of questions in WebSocket is neither Web nor Socket.
- Does WebSocket use TCP ports 81 and 815?
- How does WebSocket make use of an HTTP connection on port 80?
- Does WebSocket obey the same origin policy?
- Is WebSocket restricted to the two-connection limit of HTTP?
- Can WebSocket read and write arbitrarily as with low-level socket APIs?
- How does WebSocket delineate messages?
- How are function call semantics implemented over WebSocket?
- Is WebSocket easy to implement?
- Can we just upgrade HTTP?
Michael Carter had a fun little spin on things in HTML5 WebSocket and WebJneering.
I want to tell you about HTML5, specifically about the advances in bi-directional, asynchronous communication. But I’m troubled. Consider two propositions that I didn’t come up with: 1) Nothing is new, 2) Everything Sucks. Let these simple truths cast a shadow upon the tale you are about to read…
HTML5 provides a new thing called a WebSocket. I’m pretty sad that its not a TCPSocket, but alas, it was easier to throw in a handshake for security than to set up some out-of-bound security method, such as flash’s cross-domain policy files. We can’t connect to existing TCP servers, so we’ll just have to start over and write new WS/TCP servers. No problem. WebSocket will still be our salvation, leading us towards our stateful future.
I was at first overjoyed at the prospect of the World Wide Web’s new status as a real boy. But such feelings were just a precursor to the greatest technology-driven depression of my life. You see, as recently as twenty years ago the world was brimming with real programmers, who knew how to do such amazing things as write programs that conversed with far-away computers by using bsd sockets. We’ve traded those programmers, by and large, for JavaScript kiddies. Its not that the real programmers all died, retired, or gave up with programming; rather, every new programmer of the past decade is a bright-eyed 22 year old who thinks he’s the best thing since Google, what with his domination of rails (, java, or php) and javascript.
Both Michael and Ted will be joining myself, Alex Russell, Dylan, John Fallows, and others at an event tonight in Mountain View covering Comet. If you are in town, join us!
We are using the Google Moderator to help answer questions you want heard, so
add your questions too.
Friday, October 17th, 2008
Category: Comet
Richard Jones has started an interesting series to talk about scaling comet web applications using MochiWeb:
In this series I will detail what I found out empirically about how mochiweb performs with lots of open connections, and show how to build a comet application using mochiweb, where each mochiweb connection is registered with a router which dispatches messages to various users. We end up with a working application that can cope with a million concurrent connections, and crucially, knowing how much RAM we need to make it work.
In part one:
- Build a basic comet mochiweb app that sends clients a message every 10 seconds.
- Tune the Linux kernel to handle lots of TCP connections
- Build a flood-testing tool to open lots of connections (ye olde C10k test)
- Examine how much memory this requires per connection.
Future posts in this series will cover how to build a real message routing system, additional tricks to reduce memory usage, and more testing with 100k and 1m concurrent connections.
Richard walks through the code and setup, step by step and measures the scalable performance, leading too:
That was a reasonable first attempt. 45KB per-connection seems a bit high - I could probably cook something up in C using libevent that could do this with closer to 4.5KB per connection (just a guess, if anyone has experience please leave a comment). If you factor in the amount of code and time it took to do this in Erlang compared with C, I think the increased memory usage is more excusable.
In future posts I’ll cover building a message router (so we can uncomment lines 25 and 41-43 in mochiconntest_web.erl) and talk about some ways to reduce the overall memory usage. I’ll also share the results of testing with 100k and 1M connections.
Monday, October 6th, 2008
Category: Comet, JavaScript, Library
Michael Carter et al have been working on js.io, a client library that gives you networking, including Comet like support, via JavaScript.
The low level work can sit upon Comet APIs, and in the future, Web Sockets, and you get high level APIs to protocols such as:
- amqp
- imap
- irc
- ldap
- smtp
- ssh
- stomp
- telnet
- xmpp
There are some demos such as LiveHelp that uses Orbited as the backend.
Thursday, September 18th, 2008
Category: Announcements, Comet, Framework
ZK 3.5, the latest version of the server-side Ajax framework, is out with a raft of new features. Three of those features really stand out for me:
- Comet server push
- Customization of look and feel
- Performance monitoring
Server push via polling has been available in ZK for a while, and Comet in the ZK "Enterprise Edition," but now it is available to everyone. And it is pretty easy to use: "The implementation of server push is transparent to developers. ZK chooses which implementation to use according to the edition of ZK automatically, but it is configurable."
Customization of look and feel has gotten much easier. ZK has followed the example of a number of other frameworks in styling its widgets with predictably named CSS styles. Changing the look and feel of an application is now as easy as changing the ZK widget style sheet. Styles can further be overridden on a widget instance-by-instance basis.
Performance monitoring is perhaps the most exciting new feature. Client-side tools such as YSlow can guide optimization efforts and give you point in time performance snapshots. But critical applications need to be monitored and tracked end to end over their lifespan. With ZK 3.5, you now have the plumbing to instrument your application to capture five data points for each request:
- T1, the time browser sends a request to server
- T2, the time server receives a request
- T3, the time server sends a request to browser
- T4, the time browser receives a request from server
- T5, the time the browser finishes processing a request
ZKStudio 0.8.2
There's also a new version of ZKStudio for Eclipse out. The major change is that it now supports auto update via http://studioupdate.zkoss.org/studio/update
Tuesday, September 16th, 2008
Category: Comet, DWR
Joe Walker of DWR fame on Comet at @media Ajax.
Motivation for Comet
Interested in what our friends are up to, even if no-one else cares (as twitter illustrates). And also interested in what systems/things are doing, not just people. Chat (meebo), collaborative editing (google docs), streaming financial data (lightstreamer), async updates (yes.com), online gaming, async server processing (polar rose, i.e. shift processing complexity to the server - note this could be seen as an alternative to Gears-style local processing in some situations).
The web was designed to be connectionless - Comet blatently aims to make it connected.
Performance
Actually does scale. Joe shows the following graph:
Technical
Seven ways (!) to implement Comet.
Long polling - "slow" XHR request. Server doesn't answer immediately. Special part of HTTP to do this - chunked mode. However, IE "lies to you" - keeps saying it's got something, but you can't actually inspect it.
Forever frame - Send text/plain and 4k whitespace to flush IE's buffer. Flush with script tag for each data block. Must keep restarting to avoid memory leak.
Script tags - Dynamic script blocks, can point to any domain.
WebSockets - HTML 5 standard. Cleaner solution.
ActiveXObject("htmlfile") - htmlfile is an activeX control similar to XHR. Normally causes "clicking" noise in browser, but there's a hack to turn it off in most cases. Obviously, this only works in IE. Most bizzare thing is you get 49 Javascript before garbage collection, leading to hair-pulling moments when you try to work out why your 50th command isn't executing!
Mime messaging - "What push was built on 11 years ago" - x-multipart-replace. Works really well, though with memory leakage issues, but not in IE and historically not in the other browsers either.
Flash remoting
Forever GIF (bonus technique) - keep sending out new slices of an animated GIF!
Technical Issues
Co-ordination when browser has multiple tabs open to the same server - using window.name or cookies, but better solution is multi-home DNS - each call points to the server using a different name (1.example.com, 2.example.com etc all pointing to the same IP address).
Issues detecting when browser or connection has broken.
Proxies which don't let the stream go through in real-time - hold on to the chunks for a while before releasing them all at once. Can detect if this is happening from the browser using a timestamp technique.
... so just like with Ajax, we have to come up with hacks, likewise with Comet. Facebook and GMail show it's possible to work around these problems and get Comet working at scale.
API Styles
e.g. with WebSocket you're simply posting and receiving data. Event handlers for onOpen, onRead etc. Joe says this will be too low-level in many cases, hence the following styles.
PubSub - e.g. cometd. Low coupling (server-browser separation - Joe describes demo where servers hot-swapped without affecting client), inter-language interop. Good analogy to SOAP, which has gradually shifted from RPC to document exchange.
API - this looks to me like Ruby's remote JS - server controls what's happening on the browser. e.g. Effect.shake("price") on the server will make the price div shake on the client.
Data Syc API - Keep changing/updating data store. Simplest to understand.
Tuesday, July 8th, 2008
Category: Comet
JAVASCRIPT:
-
-
var conn = new WebSocket("ws://www.example.com/livedemo");
-
-
conn.onopen = function(evt) { alert("Conn opened"); }
-
conn.onread = function(evt) { alert("Read: " + evt.data); }
-
conn.onclose = function(evt) { alert("Conn closed"); }
-
-
conn.send("Hello World")
-
What if that code was part of an HTML standard? Would that make you feel better about Comet-style applications? Well, Michael Carter has pointed us to the HTML 5 discussions that give us WebSocket:
The HTML5 specification now offers WebSocket, 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:
- Seamlessly traverse firewalls and routers
- Allow duly authorized cross-domain communication
- Integrate well with cookie-based authentication
- Integrate with existing HTTP load balancers
- Be compatible with binary data
He goes on to discuss how WebSocket is not the same as a TCP socket itself, and what that means as we develop real-time applications.
Tuesday, July 1st, 2008
Category: Comet
Michael Carter of Orbited has written about how he now likes to call Comet sockets in the browser, and has an implementation available that looks like this:
JAVASCRIPT:
-
-
var conn = new TCPSocket(hostname, port)
-
-
conn.onopen = function() { alert('connection opened!') }
-
conn.onread = function(data) { alert('RECEIVE: ' + data) }
-
conn.onclose = function(data) { alert('connection closed!') }
-
-
conn.send('Hello World');
-
The above code code is all you need to know. It will open a TCP connection to hostname:port, and will send the data “Hello Worldâ€. Any data the server sends back will be alerted with the onread handler.
The exact mechanism behind this innovation is pretty straightforward: Orbited is a router and firewall for incoming TCPSocket connections from the browser. It uses Comet techniques to establish bi-directional communication with the browser, then forwards all data over a raw TCP socket to the end point. Configuration allows access control enforcement so that the TCPSocket can only be connected to pre-approved end-points, so that the Orbited server isn’t an open relay.
While this presents a paradigm shift in the way developers are tackling real-time, web-based applications today, it’s actually a return to the original method of writing network applications. Instead of writing applications based on web frameworks and throwing a Comet server in the mix, you can simply use the client-server architecture where the browser is the client, and the server is an arbitrary TCP server.
Monday, May 12th, 2008
Category: Comet, Games
Piotr Dachtera took his 64pola.pl, and created a scalable version using Comet. Dylan reports it as "a Jetty-powered Comet app that uses dojox.cometd on the client-side. It’s a solid implementation that shows chess moves in real-time, and to date is the best all-around Comet game I’ve seen that is live to the world."
Mathieu Nouzareth then commented that Cafe.com, a Flash based gaming platform also uses Jetty and Comet techniques (compared to AMF etc).
Friday, March 28th, 2008
Category: Comet
There has beern a lot of great Comet content recently, especially from Comet Daily of course :)
First, they gazed at their own Comets talking about maturity, together with a maturity grid. Since the project leads and vendors are grading themselves, you have to do due diligence :)
Joe Walker has written up 3 styles of API that are relevant when considering Comet services, which are:
- Traditional API Style. This API is the most obvious. If you want to set the text of a button, you call
field.setValue(43.5) or something similar. It’s possible to imagine complex APIs like the SWT library made available remotely. This type of API does not need Comet, unless the trigger for wanting to alter the UI is asynchronous.
- Message Passing Style. This API style is very simple—typically just a
subscribe() method to declare an interest in some topic, and a publish() method to declare some information to a topic. Some messaging APIs (notably JMS) add a large number of classes around this simple concept, however at its core, it’s as easy as those 2 methods.
- Synchronized Data Style. This style involves some data cache on the server that is synchronized with a similar data cache on the client (or clients).
Joe then walks through the pros and cons, and includes information on how DWR does its thing.
Colliding Comets: Battle of the Bayeux
The entire crew has a series of back and forth opinion pieces on the Bayeux protocol:
Martin Tyler of Liberator has a nice piece talking about benchmarking Comet servers which concludes:
Benchmarking Comet servers is not easy. There are lots of variables which impact the results, often in an unexpected way, so the only way to be sure is devise and run the appropriate tests. Making assumptions while testing is not good; if you need to know something it should be measured and recorded.
It is possible to achieve high numbers of users with high update rates and relatively low latency. However, a project needs to understand the implications, such as bandwidth, which are inherent in the requirements rather than the technology. A serious project should also perform benchmark tests themselves, with test scenarios similar to expected usage, rather than just looking at some headline figures from the Comet server vendor.
Finally, Zaid Al-Timimi has released XML Studio 7.3 which has Comet developer support.
Developers can now build and test real-time streaming mash-up applications. Version 7.3 embeds a copy of the upcoming <alt> Dynamic Mashup Server which uses a custom version of Grizzly, the Comet technology from Sun.
Tuesday, March 18th, 2008
Category: Comet, JavaScript, Library
Azer Koçulu thinks that you can create a comet application in 3 minutes with his new library pi.comet. It provides realtime data transfers between client and server.You can use pi.comet with any server side language.
The usage is very simple indeed:
JAVASCRIPT:
-
-
var request = new pi.comet();
-
request.environment.setUrl("push.php");
-
request.event.push = function(RESPONSE){
-
alert(RESPONSE);
-
};
-
request.send();
-
And the style of client side comet depends on the type of browser:
JAVASCRIPT:
-
-
scope.comet.constructor = function(){
-
this.environment.setName("piComet");
-
this.environment.setType(scope.env.ie?3:scope.env.opera?2:1);
-
this.environment.setTunnel(
-
this.environment.getType()==3?new ActiveXObject("htmlfile"):
-
this.environment.getType()==2?document.createElement("event-source"):
-
new scope.xhr
-
);
-
}
-
