Server-to-Client-Style notifications

[Helge Lenuweit]

I'm currently looking at adding some sort of notification mechanism server-to-client style to a ServiceStack based web service. My solution is based on HttpListener and so far it's also perfectly able to run on mono, so ideally I'm looking for options that preserve this.

Some suggestions that I have come across were the following:

- implement long-polling or comet-style requests that keep the response open to allow to push information bits down to the client

- integrate SignalR into the solution, which seems a little difficult but would match the problem

- bundle the service with a node.js server that handles only this type of notification.

Most of it has been discussed here: https://groups.google.com/forum/?fromgroups#!topic/servicestack/F3ooNvvZM8E

Now I'm looking for the easiest solution for this. Demis mentions that long-polling will happily serve in the 100s of concurrent connections which would be perfectly sufficient (unless it doesn't block these user's "normal" operations). However I have no clue how to go about to implement something like this. Is there any example available or how would I go build this?

SignalR as the second option looks tempting. However if I were to host this in the same process (and also http port), I would need the respective HttpListeners filter by a virtual directory, which I couldn't get to work with ServiceStack (I have fiddled around ServiceStackHttpHandlerFactory.GetHandlerForPathInfo but to no avail so far). However I would get back to this option if (1) is not the way to go. Integrating node.js at the moment isn't really an option as it would complicate deployment a lot not, to mention development itself.

I'd be happy to hear how others have solved this and what would be the best option to choose.

Best regards,

Helge

[Demis Bellot]

Hi,

Long-polling is when a client makes a request, if there are notifications already available for it, return immediately otherwise hold the request open for about 30-60s by doing something like 

do {
   if (hasNotifications?) return notifications;
   Thread.Sleep(100); 
} while(TimeElapsed < 60to30s);

return emptyNotifications; 

  

On the client side it continually makes a request to this service - if notifications are returned it processes all of them, then goes back straight away to make another (which if there were no notifications the request would last 30to60s) in this way it is effectively always maintaining a connection to the server.

Cheers,

--
- Demis

http://twitter.com/demisbellot

http://www.servicestack.net/mythz_blog

[Helge Lenuweit]

Hi Demis,

ok what should I say... I had been digging into some really serious stuff the last few days and it's so obvious and easy :-)

Cheers and thanks for your quick + helpful answer,

Helge

Am Donnerstag, 19. Juli 2012 16:44:14 UTC+2 schrieb mythz:

Hi,

Long-polling is when a client makes a request, if there are notifications already available for it, return immediately otherwise hold the request open for about 30-60s by doing something like 

do {
   if (hasNotifications?) return notifications;
   Thread.Sleep(100); 
} while(TimeElapsed < 60to30s);

return emptyNotifications; 

  

On the client side it continually makes a request to this service - if notifications are returned it processes all of them, then goes back straight away to make another (which if there were no notifications the request would last 30to60s) in this way it is effectively always maintaining a connection to the server.

Cheers,