Service Bus Websockets
Service Bus support for Websockets would be awesome, allowing us to build really scalable real-time web apps.
Chats & Games
Thanks for this suggestion, we have been considering adding this support and need a few pieces of underlying platform to be in place. Couple of considerations we would like to get your input on, is this only for non-durable messaging scenarios? Per the examples provided these would not require the durable messaging that Service Bus Queues/Topics provide today.
Phil Carbone commented
This seems like it needs to be revisited or re-opened
What happened to this? I'd like this just now and as it's marked as completed can i use it?
Gerald Wiltse commented
This says complete, is there an article or document where accessing service bus over websockets is explained?
Kurt Pattyn commented
I would like it for all kind of scenarios. Currently we need to use HTTP long polling to fetch messages from the service bus (and HTTP Rest calls for pushing to the queue).
The reason for HTTP is firewall restrictions. Maybe AMQP over WebSockets could be a solution.
It was such a great opportunity to visit this site,you can gain new interesting topics.I want to stick on this one so that I can update more details about this one.
Martin Svensson commented
Nice! I’m really glad over the increased activity on the site :)
Josh: Yes, it would be nice to be able to consume relayed services through web api in the scenarios where a Service Bus is necessary or the overhead of using one not a problem. Good usages may be message broadcasting and exposing firewalled stuff.
I haven’t used relays so I won’t try to answer your question on targeting clients.
What I most of all want to see is a way to leverage Service Bus’ infrastructure in scenarios where server logic is passive or not real time like in the example of an unmonitored chat where the users of a room could occupy a single topic and not having to go through a web role for example (in a scaled up version you’d need to sync data between instances and all of a sudden there’s quite some infrastructure just for a simple chat). If you still wanted to monitor the chats you could still just create a subscription for that.
Abhishek: I definitely think some durability is wanted in for example the chat scenario where you would be lost in the conversation if you’d drive through a long tunnel for example. I can imagine there are better examples of this though :)
I'm sensing there might be more to your question so I would like to add that when it comes to durability I for one could live with having to make a HTTP REST call once in a while in between the sessions to get any messages missed.
I’m not building a chat btw :)
Ben Adams commented
Kind of like this, but raw browser HTM5 rather than Windows 8 app HTML5 (using WinJS):
Ben Adams commented
Websockets to Topics is what I'd most be interested in.
Connect to a topic and when a new message comes in it sends it to the subscribed sockets (browsers), and you'd send messages to the topics via the socket also.
Thanks for the feedback Martin. I assume you're thinking with respect to the relay? How would you imagine this working - each client connects to a single listener via a relay and the server can target specific clients? Some more details would be great... and I'd love to hear what others think of this scenario.