Tuesday 17 March 2009

COMET: The Bayeux Protocol and ASP.NET support

In my previous post I discussed the merits of the COMET technique for pushing data to the browser over standard web protocols.

The basic idea behind COMET is that the browser keeps an HTTP connection open and the server uses it to send data back.  This contrasts with HTTP’s Request/Response paradigm where the browser is specifically requesting data when it needs it.  There are two main types of COMET – Streaming and Long-Polling.  For Streaming COMET, the browser opens a single connection and keeps it open indefinitely, receiving events from the server when they are ready to be sent and immediately processing them.  With Long-Polling, a connection is opened and is kept open until the server has data to send to the browser (or data is sent immediately if waiting).  Once the data is received, a new connection is immediately opened which again blocks until data is ready to be received, and so on.

Over the last several years a protocol for COMET, known as Bayeux, has been formalised by the dojo foundation.  The protocol specifies the wire format for messaging between client and server as well as the transport mechanisms involved, and supports both streaming and long-polling over standard HTTP transports.  It’s essentially a specification for a pub/sub message bus, where clients can publish messages to channels and subscribe to messages on those channels.  A number of client libraries have support for Bayeux style comet messaging, most notably the Dojo Toolkit.

There are also a number of server frameworks for COMET out there, including one from Dojo themselves – cometd - which implements Bayeux and integrates with their client framework.  There are also commercial COMET servers out there, such as LightStreamer and Liberator, which actually offer .NET integration and support for integrating with enterprise messaging systems such as Tibco RV.  However, searching around I have been unable to find any that run within ASP.NET (well definitely not free ones anyway) and I think it’s a very important thing to support within ASP.NET - custom servers are fine, but you can’t exactly run them on shared hosting providers!

One of the main challenges to developing a COMET server which runs within IIS is the threading model of ASP.NET (I believe Apache has the same issues, but not sure).  With ASP.NET, each request is serviced by a single thread from the thread pool.  This basically rules out being able to support Streaming COMET, as we would have to keep a thread aside for each client, and there a limited number of threads in the thread pool.  So this leaves the Long-Polling option.  This is wholly possible within ASP.NET as it has support for asynchronous processing, meaning we can put the thread back on the thread pool until we actually have data to send back to the client.

And this is what I am working on now. The project is called AspComet and is available at the AspComet Google Code Website via SVN.  It’s pretty basic at the moment and it just supports a small test case, however it’s built against the Bayeux spec and therefore can be used with any client library which supports Bayeux (I am testing with dojo of course).

In the next post, I will describe a bit about how it works and walk through a sample simple chat application built using it.

26 comments:

Anonymous said...

Good work! I can't wait to see your progress on the topic

Regards

Greg said...

I'm sure you're right on your assertion that ASP.NET can't support streaming COMET; but I'm struggling to understand why.

My understanding is that with lp-Comet, the client opens a connection, and the server sends a response when it's ready then closes the connection. You indicate that you can release the thread between receiving the open request and sending the response.

With s-Coment, the client opens a connection, and the server sends a response when it's ready, and then doesn't close the connection. Surely you could still release the thread betwen receiving the open request and send the response?


Could you explain what I'm missing?

Thanks.

Neil Mosafi said...

Well quite simply ASP.NET's threading model doesn't allow you to do that. You have pre- and post- event handlers and once you write to the response in the post handler the connection is ended. Also afaik IIS will eventually time out the connection if it stays open too long. There may be a way but long polling seems much simpler

SinStereo said...

Neil, had you been able to progress with this project? I was starting to implement Bayeux, found your project, and I am now interested in knowing how is your project status.

Thanks!
Leandro.

Neil Mosafi said...

Hi Leandro


I have indeed - I am using aspComet for a small project I am working on and it's going well.

Please give it a go and let me know if you have any issues or questions!

Cheers
Neil

Kasper Veenvliet said...

Hey,

I was looking for Comet Bayeux implementation for usage with ASP.Net.
Your's looks the most clean way. Including the jQuery example.

I'd really like to use Comet with Database events (MS SQL Service Broker, WAITFOR and RECEIVE).

Herefor I need a thread waiting for this DB events and then push a message over the lp-comet tunnels that are present/ to the clients that has subscribed.

Can you give me a lead how to set this up? Where can I create this thread and publish the results to all subscribed clients?

Hope you have some time to help me. I'd like to show it to the rest of the company here. So they will be blown away :). (We still use ASP.Net 2.0 without any AJAX or what ever.)

Neil Mosafi said...

OK so it shouldn't be too hard to do that, all the infrastucture is there I believe.

You can create your background thread to cwait for callbacks from the database in the Application_Start event in your global.asax - same place where you set up the comet message bus.

Then, when you detect an event which you want to publish to clients, you can retrieve the clients using an instance of IClientRepository (perhaps create a channel for it and use the WhereSubscribedTo("mychannel") method. You can then call Client.Enqueue(messages)

Hope that answers your questions but if you have any more then please write back!

Good luck
Neil

Kasper Veenvliet said...

Great.
Thanks for your help!
I got it working (well for now with an Threading.Timer callback, but the concept works).

Now I just need to port your example to an ExtJS component and couple it with an DataStore. To update the grids etc.

Thanks again.

Denny Love said...

Kinda new to this and the samples are great for client-side but if I wanted to push a message from server to client how could I do that?

Neil Mosafi said...

@Denny I actually explained that in the response to Kasper's question earlier - 2 responses up. Do you need more info? Perhaps post a message with your exact scenario and I will do a post on it

Cheers
Neil

Denny Love said...

Neil, after playing with the library over the past few days I now have a much better understanding of how it works and was able to accomplish sending a message via the server. I initially didn't realize I had to Enqueue() my message to each client.

Thanks for the great work.

Greg said...

I can see how to post a message to a client (or clients), but is there a way to subscribe to messages /from/ clients at the server side? I don't see an API to do that server side - am I missing something?

e.g. client sends a message to a channel, we want to the server to respond based on the contents of that message, rather than having it broadcast to other clients.

Similarly, is there a way to prevent subscription to certain channels?

Thanks for any help offered,

Greg

Neil Mosafi said...

Hi Greg

Thanks for getting in touch... I guess I really need to make a small user-guide for the library with answers to all the questions I've received!

You want to be looking at the AspComet.Eventing.EventHub class... this allows you to be notified of various events coming into the message bus. I usually configure this in my Global.asax after configuring the message bus.

So to respond to messages being sent to a channel, you need to use the PublishingEvent. Call EventHub.Subscribe<PublishingEvent>(handler) and in your handler you can do as you please in there. You can also use this handler to prevent the message being delivered to the channel by setting Cancel = true if you want, although note that in the Bayuex protocol, messages which are intended to be sent to the server and not passed to clients should be sent to a /service/* channel.

There is currently no way to prevent a client subscribing to a channel. That is something I can add, shouldn't be too hard... we would need a similar cancellable SubscribingEvent which would be handled in the same way. If you want to send me a patch for that it would be more than welcome!

This is a fairly immature project and I welcome suggestions on how to improve the API or the code.

Cheers
Neil

Greg said...

Neil,

I'll certainly look at both the things you suggest; I think a patch should be quite easy from what I remember of the code (not to hand atm). Is there a way I can contact you off-blog, to stop filling it up with various discussion that probably don't belong there?

Tx,

Greg

Jerod Venema said...

ASP.NET does indeed allow you to build a comet server. Check out our implementation:

www.frozenmountain.com/websync

Neil Mosafi said...

Hi Jerod that looks very interesting! Have you guys considered open sourcing any of it?

Jerod Venema said...

The thought crossed our minds :) We're still discussing. If we did, it would be probably GPL + commercial licensing. Drop me a line sometime, I'd love to discuss it with you, and hear what you've worked on as well. You can reach me at jerod.venema at frozenmountain dot com.

Unknown said...

Just come across your blog - awesome work!

I've been looking to integrate Comet into an app that's been developing & maturing over the past year - around some collaborative tools...

I've just had a bit of a play with your sample chat app - one hing I've noticed is that with IE, messages are posted & pushed out in essentially real time. However with Firefox & Chrome there'a a delay of around 1sec. I haven't had a good look around the code yet, but do you have any idea why this is??

I've definitely be watching your progress with this - there's not many people working on asp.net Comet solutions that I can see,

Keep up the great work!

Joe

Neil Mosafi said...

@Joe thanks for the praise, it makes me feel good! Now that's the first ever time I've heard of IE behaving better than Chrome or Firefox. Off the top of my head, I am not sure what the problem can be. I will investigate when I get some time. If you do look into this and find anything out, let me know. Perhaps create an issue on our googlecode website to track this?

Thanks
Neil

Neil Mosafi said...

Hi Joe did you have any luck with aspcomet? Interested in your feedback

Unknown said...

Hi Neil

The latency issue I had seemed to be related to my dev server (using VS2010), when I ran a locally deployed site didn't have the same problem. Bit strange, but didn't worry too much about it after that...

I haven't had a lot of time to spend on this yet, but one thing I was planning on doing was porting it to an MVC app. I really like to MVC framework & find I write all my apps in this now.

Not sure if you would see value in this for your project??

Regards

Joe

Neil Mosafi said...

Yes, mvc is definitely the way to go. Aspcomet should already support this as its just an http handler. In fact I am using it in an mvc app of my own. What do you mean to port it to an mvc app?

Unknown said...

Neil,
any benchmarks/guestimates on the scalability of this (# of open connections)? i'm considering this for a project at work, but we need to support in the region of a few thousand.

Unknown said...

Hi,
we are evaluating the promising solution for usage in one of our projects.
We need to implement a chat functionality where a moderator has to evaluate and preselect the messages and to forward them to the channel.

How would a possible solution look like?

Regards
Stefan

Neil Mosafi said...

@elstefanito There's nothing especially difficult about that. Handle the Publishing event, from there, cancel it and store it.

Then, once a message is approved, you publish to the clients which are subscribed to the channel using clientRepository.WhereSubscribedTo("channel").Enqueue(message)

Rocky said...

Gi,

How can I reach the session id during handshake or subscription?