What's the reason for not seeing even a handful of "useful" and publicly available websocket based services out there?
RESTful services are plenty like the one below which is weather forecast related.
http://api.openweathermap.org/data/2.5/forecast?q=chicago,us&mode=json
However, why aren't there services like
ws://api.openweathermap.org/...
with some documentation about what messages a websocket client can expect to send and receive bi-directionally over a single connection?
What's the reason for not seeing even a handful of "useful" and publicly available websocket based services out there?
Maybe because websockets were not created for that? They came from the HTML5 initiative and were created to replace Ajax interaction between a browser and a web site for real time web applications. No more polling, long-polling, streaming, flash sockets, or any other HTTP hack to make a server push data to the browser. Webocket is the real thing.
Most web services now follow a request/reply pattern while the websocket is still a maturing technology. Give it time and services will appear, services that actually need the capabilities of websockets and not use them just because "there is a new kid in town".
As a final note, here is something for websockets emerging from Microsoft.
Related
I'm currently using RabbitMQ via EasyNetQ to communicate between a Windows service and numerous clients. The communications are a mix of requests from the clients and push notifications to all of the clients. I'm very happy with the performance, scalability, and security of the current solution, but want to ensure I'm not missing out on something in the latest technologies. What advantages, if any, does Web API + SignalR have for this scenario?
From the what I can tell at this point, SignalR has the potential to be much more performant when web sockets is available, but is slightly more complex from the start and will become significantly more complex if we need to scale out because of the need for a backplane.
Any other insights anyone could share?
It's apples vs. oranges.
As lukegf puts it in the question comments: SignalR is push server notification solution.
RabbitMQ is a message broker, and though there is edge cases in which it could directly interact with your web clients, it is mostly suited for server to server communication.
I'm new to ServiceStack and want some validation on a pattern we're thinking about using.
We want to use ServiceStack with Xamarin and Message Queues. While I understand how REST works under the covers, I'm not sure how the Message Queues on ServiceStack work and if its appropriate for mobile devices.
Specifically we know that all mobile devices are essentially behind a NAT firewall setup by the Telco. Meaning Clients can talk to servers, but servers cant talk directly to clients, without the client talking first.
While the concept of a ServiceBus is designed specifically to handle this case, i'm not sure if its "mobile network friendly".
I would assume that the client side implementation, would need to work in one of two ways: polling, blocking get.
Polling would have the client side frequently runing a Http GET to ask the server if anything is available on a queue. A Blocking Get would, perform a Http GET but have the server return nothing until data is ready. Or is there another technique that i'm missing?
If it is a poll, is there any way to control the Poll frequencies in service stack. If its a blocking get how is this configured..
What happens when the app goes to the background, do we need to cancel the connections manually. etc.etc.
We tool an old version of the ServiceStack client library and ported them to xamarin. We now see that the latest ServiceStack client side library is Xamarin compatible.
So, basically my question is: Had anyone used Message Queues from a Xamarin Mobile to ServiceStack with RedisMQ or other server side message queue.
I built a realtime application that, thanks to Socket.IO, can serve a lot of different client types (C#, Java, Browser, ...)! I know that there are a lot of Socket.IO alternatives, but from my understanding, everything is more or less based on WebSockets. (I know that Socket.IO has fallbacks if WebSockets are not working, but that they are more less "inferior workarounds" so to speak...)
My question is: Is there any comparable real-time engine available that is NOT based on WebSockets, but can still serve all those different clients?
You don't say what your endpoints are. If one of the endpoints is a browser with purely the built-in capabilities of the browser and Javascript, then a webSocket is your only way to get a continuous connection from the browser to some other destination.
If a webSocket is not supported (in an older browser), then the other socket.io fallbacks (such as xhr-long-polling) are the next best alternatives. As the browser has limited communication capabilities, if you can't use a webSocket, then an ajax call is your only other generally supported option without requiring plug-ins on each browser (such as Flash or Java or something like that). socket.io already supports the next-best options that are available in a browser - you can't do better than that if you're talking about a standard browser with no custom plug-ins.
If your endpoints don't necessarily include a browser and you can use any language or library you want, then you can use plain TCP sockets and then use whatever protocol you want over a TCP socket.
The WebSocket protocol establishes a bidirectional communication channel between server and client; they kind of speak more naturally with each other. The server can just send something to the client and the other way around. In http it just goes in one direction, there's a request and a response and everything needs to be initiated with a request from the client.
From my experience, realtime webApps like a multiplayer game or a chat become easier to develop and it apparently creates less overhead than using http - but still you can do the same things more or less elegant with http as well (see e.g. long polling).
Look at gmail or other existing webApps, they all use http (so does Socket.io as a fallback) and it works quite well.
I would like to see if someone can clarify me some concepts I still don´t get about integration of web applications. Up until now, I´ve been working with CometD and Activemq in a project that´s been there for several years but, for what I´ve seen, there are other options out there much more simpler and supported by the community but I still don´t get the whole picture of options available.
So, for what I understand, at the moment, the most common way of getting server pushed events to a client is using websockets. The implementation is server specific and the most used one seems to be the Jetty one. But, because it requires a websocket compatible browser, there are some frameworks that are able to provide websockets and fall to reverse ajax techniques in case this is not an option, like SockJS, that has an implementation for client and for server side. Based on this, as of spring 4 there are templates that allow you to use SockJS behind the scenes and just provide the client implementation of the code using SockJS and letting the programmer to handle the server side in a more easy way.
Apart from this, brokers can understand the websocket protocol so a broker can receive a message from a web browser and then send a message back directly. There is also the STOMP protocol that brokers also implement that allows the system to send/receive messages through websocket to/from the web browser.
One question I have about this is, is STOMP the protocol always used by the broker to send or receive a message to or from a web browser? Or is just one alternative? What is the difference if it´s the later?
Yet another option I´ve seen is using a framework like camel. In this case, the web browser would talk to the websocket component of camel and from there it could be routed directly to the broker using jms. The benefit I see on this is the possibility of introducing processors as part of the route from the browser to the broker, allowing further security processing and reducing the traffic the broker would have to handle in case of not valid/unauthorized messages. Camel would even be able to listen to messages using the STOMP component what would be yet another routing option.
So, to this point, I don´t know if my understanding is correct or if I miss or misunderstand something. If everything is right, it seems that using a framework like SockJS is the best option available at the moment. The use of Spring 4 to simplify things is an option but not really necessary. If the project requires the integration of different systems using a jms broker, the implementation then falls to use SockJS to send messages to the server side and then just route the messages to the correct system. But at this point, there are the options mentioned before like using camel to route the messages or directly send messages to the broker. What would be the best option, or what would be the differences? If I add STOMP to the problem, what does this protocol give me that I can´t handle just with websockets or camel?
I hope I made myself clear. I think this topic includes several technologies and frameworks and it´s quite difficult to express all my concerns without extending the post to much.
Thanks in advance.
In a nutshell, if you want messaging semantics, you should use a messaging protocol such as STOMP. WebSockets sure can handle communication to browsers just fine, but that's just "any custom communication".
The system design may be cleaner if you design around the convention of topics and messaging. The server backend processes can easily push data to a topic that is propagated to all clients, ideally with no further customization.
Aside from STOMP, there is a similar protocol, MQTT which also can run over websockets. A chat demo is provided by ActiveMQ distribution. MQTT is very hot in the Machine2Machine world "internet of things", but I have used it with success in web-deployments too. MQTT should, at least in theory, run pretty good, with low overhead in phone apps, should you ever consider writing one side by side with your website. Then it can be good to use a single setup to communicate "push" data with your clients. Otherwise, your app may have used MQTT, your browser app would have used plain websocket, your backend would have needed another way to pass async events to clients (via some Camel router or similar) and so forth.
I've implemented a web chat system using Jabber, with the Tigase server and an Ajax-based client communicating over BOSH using JsJac, with Apache mod_proxy forwarding the HTTP traffic to Tigase. This works reasonably well, but I've noticed one major gap in performance versus a desktop Jabber client (like Exodus), particularly when joining a multi-user chat with a long history of messages.
Specifically, from monitoring HTTP traffic, it appears that the server can only send one XMPP message per HTTP request-response cycle. For normal usage this is fine (we're getting roughly 80-100msec round-trip times, which isn't too bad), but when loading MUC history it can be a real drag.
So my question is: does Jabber or BOSH provide any mechanism for bundling or streaming messages that might apply to this use case? Are any clients and servers out there implementing something like this already? Or would I have to modify Tigase and JsJac myself (which is certainly possible, but not ideal)?
Actually, the BOSH server can collect as many responses from the Jabber server and send them as one single response to the client. I am the author of one such BOSH library: http://code.google.com/p/node-xmpp-bosh/.
The response body has nothing to do with the request body in case of BOSH. I mean that the response could and mostly will be a response to an unrelated request (mostly a later request).
I have implemented a BOSH communications solution with Java on the server and GWT on the client (a browser). A C client implementation has also been made. Presently, I am in the process of making the solution available online for tests. Please take a look at the following Google presentation to see if my solution is relevant for your business:
https://docs.google.com/present/edit?id=0AUPL-u98h45WZGQzNWNjOGhfMGd6bWI1NmNk&hl=en&authkey=CPTzrWc
To see the speaker notes, make sure you hit the "View Speaker Notes" button in the bottom-right corner of the page.