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: JavaScript, Library, Comet
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
-
);
-
}
-
Monday, February 18th, 2008
Category: JavaScript, Java, Library, Comet
Caplin Systems, creator of the Liberator Comet platform have announced a free version which can be used for non-commercial applications and for evaluation.
Liberator includes a high-performance Comet server, a JavaScript client library, and a Java server integration library.
There are many examples such as the subscriptions sample which shows a page with realtime updating information for a variety of equities and foreign exchange data.
This is how a subscriber looks in JavaScript:
HTML:
-
-
<script type="text/javascript" id="sl4b" src="/sl4b" rttpprovider="javascript"></script>
-
-
// class definition for SimpleSubscriber
-
function SimpleSubscriber(sObjectName)
-
{
-
// Store the object name as a member variable so it can be used later on; no subscription can
-
// take place until this object's ready() method has been called.
-
this.m_sObjectName = sObjectName;
-
-
// Invokes the initialise method on the base class (i.e. SL4B_AbstractSubscriber), this
-
// must be called within the constructor of all SL4B_AbstractSubscriber subclasses.
-
this.initialise();
-
}
-
-
// Defines SimpleSubscriber as a subclass of SL4B_AbstractSubscriber.
-
SimpleSubscriber.prototype = new SL4B_AbstractSubscriber;
-
-
// Overrides the ready() method from SL4B_AbstractSubscriber; once this method has been invoked
-
// it becomes safe to make object subscriptions.
-
SimpleSubscriber.prototype.ready = function() {
-
// Use the RTTP provider to setup the subscription; a reference to this object is passed in
-
// since it will be acting as the subscriber, and will receive the notification updates.
-
SL4B_Accessor.getRttpProvider().getObject(this, this.m_sObjectName);
-
};
-
-
// Overrides the recordUpdated() callback method from SL4B_AbstractSubscriber; this method will
-
// be invoked whenever new object data becomes available.
-
SimpleSubscriber.prototype.recordUpdated = function (sObjectName, sFieldName, sValue) {
-
// add code to process the record update here
-
}
-
-
// Creates a new SimpleSubscriber to receive streaming updates for /DEMO/YHOO.
-
new SimpleSubscriber("/DEMO/YHOO");
-
</script>
-
Tuesday, February 5th, 2008
Category: Dojo, Comet
Roberto Saccon has taken the Dojo example program sketch, which itself "fully implements the idea of pipelining the drawing process based on sequential commands for adding, modifying or deleting objects" and has Cometized it:
Very little additional code was necessary to combine the chat app and the drawing app into a collaborative example app. I added a single line of code to the drawing app to let it publish its demands using Comet. Another line was added to the chat app for sending incoming drawing commands to the drawing application (any additional code only served to make things prettier, more readable, or easier to extend).
The application has been tested on ErlyComet (and there is also the source code), but there are no server-side dependencies, so in theory it should run equally well on any Bayeux-compliant Comet server. And there is also a short screencast.
What is missing to make such an example application suitable for real life tasks? A lot, of course: the whole server-side logic, for one. And deciding (automatically or based on human interaction) which incoming changes should be applied to the master document (like conflict resolution in version control systems, just in quasi-real time).
Very nicely done.
Friday, January 18th, 2008
Category: Comet
As JavaScript developers, we are used to years of hacks, as we try to push forward without browsers updating and helping us out. We are so stuck in this pragmatic thinking that we sometimes forget to pick our heads up.
Kris Zyp has taken some time to think about Comet, and instead of thinking about the next good hack, he takes that step back and dreams:
What if I had commit privileges on all the major browsers, the competence to add functionality in all the code bases, and wanted to add native Comet support in a form that was easily accessible to developers?
He ends up with a proposal that adds to good ole XHR:
With only a few simple XMLHttpRequest API additions, Comet communication could be realized with a native implementation that supports fast and efficient standards-based two-way asynchronous communication, with true server-delivered HTTP streaming and simple subscription requests, with the added benefit of client-delivered streaming and cached resource until updated capability. Developers could create Comet applications with a standard API without hacks. Communication could be standards-based, allowing current servers to easily implement the necessary features to handle communication.
It would look something like this:
JAVASCRIPT:
-
-
var cometXHR = new XMLHttpRequest;
-
cometXHR.open('POST','comet',true);
-
-
var xhr1 = new XMLHttpRequest;
-
cometXHR.addHttpChunk(xhr1);
-
xhr1.onreadystatechange=function(){...}
-
xhr.open('GET','/ticker1',true);
-
xhr.send();
-
-
var xhr2 = new XMLHttpRequest;
-
cometXHR.addHttpChunk(xhr2);
-
xhr2.onreadystatechange=function(){...}
-
xhr.open('GET','/ticker2',true);
-
xhr.send();
-
Kris gets into many of the details, and makes me with that someone would implement this as a Google Gear, so it could get pushed into the fabric of the Web by being on all browsers.
Monday, January 7th, 2008
Category: Comet
Greg Wilkins is marching a long with better and more performant Comet support as shown in his piece 20,000 Reasons Why Comet Scales:
After some recent optimizations, the Dojo Cometd implementation of the Bayeux protocol running on the Jetty web server can now handle up to 20,000 simultaneous users per server while maintaining sub-second latency.
This was done on "mid-sized Amazon EC2 virtual servers: 7.5 GB of memory, 2×2 EC2 Compute Units, 64-bit platform running Ubuntu 7.10 and Sun JVM 1.5.0_13. A single virtual machine was used as the Cometd server and between 1 and 3 virtual machines were used to generate the load of 20,000 clients."
Zimbra recently posted about how they switched to Jetty and why continuations was a major reason:
Jetty uses the Continuation pattern to suspend a blocked polling request and free the worker thread. By using Continuation, Jetty keeps impact on existing Web applications and Servlet related technologies to a minimum. Applications written according to the current Servlet specs can take advantage of Comet with trivial changes, and the Continuation mechanism for suspending and resuming of a request is most straightforward. Although Continuation is hardly the only way to implement Comet support, it's worth noting that other approaches typically will require writing asynchronous code at the application level which carries a signification application development cost.
In summary, we chose Jetty not only because it supports Comet in a scalable manner, but also because the Continuation implementation of Comet is least disruptive to existing Servlet based technologies.
Thursday, December 27th, 2007
Category: Articles, Comet
Arena Albionu has written about Django and Comet using the Orbited Python event driven comet server.
The article walks through the hello world of Comet... a chat server. The JavaScript looks like this:
JAVASCRIPT:
-
-
function processGetPost()
-
{
-
var myajax=ajaxpack.ajaxobj
-
var myfiletype=ajaxpack.filetype
-
if (myajax.readyState == 4)
-
{ //if request of file completed
-
if (myajax.status==200 || window.location.href.indexOf("http")==-1)
-
{ //if request was successful or running script locally
-
if (myfiletype=="txt")
-
alert(myajax.responseText)
-
else
-
alert(myajax.responseXML)
-
}
-
}
-
}
-
-
-
function connect()
-
{
-
var nick = document.getElementById('nickname').value;
-
Orbited.connect(chat_event, nick, "/chat", "0");
-
ajaxpack.getAjaxRequest("/join/" + nick + "/", "", processGetPost, "txt");
-
}
-
-
-
chat_event = function(data) {
-
var chat_box = document.getElementById('box');
-
var div = window.parent.document.createElement('div');
-
div.className = "event";
-
div.innerHTML = data;
-
chat_box.appendChild(div);
-
chat_box.scrollTop = chat_box.scrollHeight;
-
}
-
-
function send_msg() {
-
var msg = document.getElementById('chat').value;
-
var nick = document.getElementById('nickname').value;
-
ajaxpack.getAjaxRequest("/send/" + nick + "/" + msg + "/", "", processGetPost, "txt");
-
}
-
Thursday, December 13th, 2007
Category: Comet
Jacob Rus keeps the run of great content on Comet Daily by talking about the the future of Comet: Part 1: Comet Today. Jacob discusses the hacks that we use for Comet, compared to the server-sent events and event-source specs that are finally getting implemented. He then goes through the current trade-offs behind current solutions:
- “Forever-frame” iframe streaming
- htmlfile ActiveX object
- XHR multipart
- XHR streaming
- XHR long-polling
- Script tag long-polling (“CometP”)
- Flash and other plugins
With this impressive list of transports, we can cover all recent browsers (IE 5+, Safari 1.3+, Firefox 1.0+; Opera 8.5+ as described next time) without unseemly side-effects, using our choice of streaming or long-polling, and can support browsers back much further than that, with a few usability niggles. Unfortunately, however, this requires careful implementation of our server code and browser-side JavaScript, which must coordinate to agree on a transport. This coordination problem, along with browser’s cross-domain security policies, prevent us from using real-time sources in the kinds of mashups built from other web services. The barriers to entry for Comet are much higher than for non-real-time content, and success relies on loopholes in existing browser objects. Wouldn’t it be nice if every browser used the same mechanism, which could stream events across domains securely and efficiently, and web authors could in turn write straight-forward HTML and JavaScript, and send but a single format from the server? Stay tuned for part 2, which plots a course to such a future.
Friday, December 7th, 2007
Category: Comet
Simon Willison was worried that the amount of complexity involved with Comet meant it was out of bounds to all but the most dedicated JavaScript hackers but after playing with it, concluded:
I’m pleased to admit that I was wrong: Comet is probably about 90% of the way to being usable for mainstream projects, and the few remaining barriers (Bayeux authentication chief amongst them) are likely to be solved before too long. I expect to see many more sites start deploying Comet powered features over the next twelve months.
For Simon's presentation he built the slideshow itself as a Comet app. He could move the slideshow forwards and backwards, and anyone connected would also see the slides move. A nice touch. He used Jetty as the web server, and Dojo as the client:
JAVASCRIPT:
-
-
dojo.require("dojox.cometd");
-
jQuery(function($) {
-
dojox.cometd.init("http://example.com/cometd");
-
dojox.cometd.subscribe("/slideshow/change", function(comet) {
-
$('#currentSlide').attr('src', comet.data.src);
-
});
-
});
-
-
function publishSlide(src) {
-
dojox.cometd.publish("/slideshow/change", {
-
'src': src
-
});
-
}
-
Wednesday, December 5th, 2007
Category: Security, Comet
In Cross Site Scripting Joy, Andrew Betts has taken the time to go into real detail on XSS and the fun and frolics that we have with the Same Origin Policy and beyond:
So the battle over XSS as a security problem has moved on from the same origin policy, but same origin remains a massive obstacle to development of useful non-malicious services, and that’s particularly true of Comet, because there are typically two servers involved in any comet setup: a web server like Apache, and a comet server like Meteor or Orbited.
There are essentially three choices for making these two servers play together:
- marry them: have one server that serves both your Comet connections and the standard ones (including any dynamically generated content);
- have a regular web server with a Comet server sitting in front of it, so all connections are made to the Comet server, and it proxies the non-comet connections to the web server;
- have both the Comet and the regular web server exposed to the web, and request applicable content from each one.
Andrew then decided to write a bunch of tests (38 in fact) to see how the SOP is implemented in various browsers, and ended up with the following thorough information:
Tuesday, November 27th, 2007
Category: Java, Comet
Jean-Francois Arcand of the Tomcat team has implemented DWR Reverse Ajax in Grizzly:
The Grizzly framework has been designed to help developers to take advantage of the Java™ NIO API. Originally developed under the GlassFish umbrella, the framework is now available as a standalone project. Grizzly goals is to help developers to build scalable and robust servers using NIO.
From DWR you can grab continuations in Grizzly via:
JAVA:
-
-
GrizzlyContinuation continuation = Continuation.getContinuation();
-
continuation.suspend(timeout);
-
Tuesday, November 20th, 2007
Category: IE,
