tags:

views:

72

answers:

2

I need a reliable messaging framework that runs over http/https (due to client security requirements) and that doesn't use MSMQ (because some clients will use Windows XP Home). The clients only need to be able to receive messages, not send them.

We already have a message queue on the server for each user, and the receivers have been getting messages by connecting to an HttpHandler on the server and getting a Stream from

WebResponse.GetResponseStream()

We keep this stream open, and pull messages off of it using Stream.Read(). This MOSTLY works, but Stream.Read() is a blocking call, and we can't reliably interrupt it. We need to be able to stop and start the receiver without losing messages, but the old stream often hangs around, even after we call Thread.Abort on its thread.

Any suggestions?

+1  A: 

About the locking problem, have you considered the WCF framework?

Single. One thread at a time can access the service object. This is the default value for this property. Reentrant. One thread at a time can access the service object but the thread can exit and reenter. Multiple. More than one thread at a time can access the service object.

http://msdn.microsoft.com/en-us/library/dd936243.aspx

It allows a lot of control on how the service behaves with multiple calls and works with both http and https.

GenEric35
+3  A: 

I would use WCF. It supports the WS-ReliableMessaging standard. You can configure it so that messages are guaranteed to arrive, and in the correct order.

John Saunders