Me and my friend having a little bit of a problem using websockets, I'll quickly explain so we maybe could get it working.
We got a websocket server up and running and its doing fine, lisening to a specific port and connects all our clients as it should.
But we would like to have channels. For an example: http://www.example.com/channel/682831
And we can't figure out how to solve that, because right now its like "broadcasting" and we would more likely have "multicasting"
where we could say this message is going there and this message is going here.
So please help us.
Thanks!
WebSocket provides point-to-point raw messaging. What you describe usually runs under the term "Publish & Subscribe".
A subscriber signals it's interest in a topic, publisher send events to that topic, and a broker dispatches events to the right clients based on a book of subscriptions it maintains.
This needs to be layered on top of WebSocket. You might have a look at WAMP, an open standard WebSocket based protocol that provides Publish & Subscribe (as well as Remote Procedure Calls).
Disclosure: I am original author of WAMP (now an open community effort) and work for Tavendo.
Related
I would like to create a websocket server that receives the command and sends it back to all connected clients. Basically, it makes the programs able to communiciate with each other. Can you tell me where to begin?
Well there are many implemented solutions for that which provide the implementation like socket.io, Firebase Real time database, signalr and many other.
When taking a look at the Pusher Servcer and their Client / Server API I am having some problems trying to figure out how Pusher will help me allow bi-directional communication between devices / apps.
I am having multiple smaller devices / apps in the field that should return their status to a server or another client, which acts as a dashboard to browse all those devices and monitor status, etc.
In my understanding this can be done using traditional WebSockets and a cloud-server in between which manages all connections between those clients - something I though Pusher would be.
But after reading through the docs I can't really see a concept of bi-directional data communication. Here's why:
To push data to the clients I have to use one of Pushers Server Libraries
To receive that Data I have to use one of Pusher Client Libraries
This concept however does not fit into what I need. I want to:
Broadcast to Clients.
Clients can send Data directly to Clients (Server acting as Gateway / Routing).
Clients can send Data to Server.
Server can send / response to unique Client.
When reading about Pusher, they state: "Bi-Directional Communication" which I currently cannot see. So how to implement that advertised Bi-Directional Communication?
Pusher does PubSub only. Using this, you can simulate bi-directional communication: Both sides of the conversation each need to have a topic dedicated to the conversation, and you then publish to this.
This is not ideal. For something which is probably closer to what you seem to want, take a look at WAMP (Web Application Messaging Protocol), which has more than just PubSub. There is a list of implementations at http://wamp-proto.org/implementations. For a router I would recommend Crossbar.io (http://crossbar.io), which has the most documentation to help you get started. Full disclosure: I am involved both with WAMP and Crossbar.io - but it's all open source and may just be what you need.
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.
My company is working for a Telco who will allow us to send/receive sms using their gateway eventually but for now I need a sms gateway setup on my Win7 box that I can used to test and build an applicaton that sends and optionally receive sms messages.
I have had a look at Kannel but I cant seem to find a Win7 version or dont know how to compile and setup one on Win7.
If someone has any experience in this then please help me. Thanks
If you will be connecting to the telco it will probably be to their SMSC directly via SMPP or similar protocols, which means you will need to setup something to talk to that. Kannel is an excellent open source implementation of an SMS Gateway, and probably your best bet at this. It will take care of talking with the telco's SMSC, and will provide you with a simple HTTP based interface to submit messages to from your application.
In that case, you are better off trying to set it up sooner rather than later, because quite a bit is involved in Kannel's configuration. It requires linux based systems to run and there is no windows port.
However, in order to get started developing your application, you can look into a fake SMS Gateway that will accept the same HTTP interface as Kannel, and return back made up replies. A quick and dirty way would be to write a simple web page in any language you wish, that will accept a few parameters over a web request and print out "55124" for the new message id, or similar. Then your application can do a simple HTTP call to it to simulate sending an sms:
http://smsgateway.local/simulator.php?to=12345678&from=12345&body=hello+there
If you want something more realistic look at this list of software. There are some libraries for sending sms via mobile phone connected serially, and SMPPSim which looks like it could work for you for this.
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.