While I'm reading this article from the Socket.io documentation
I found that the following two packages #socket.io/redis-adapter and #socket.io/redis-emitter are used to emit data to the clients that are on the other servers.
Are these two packages different? And if yes what is the difference? And when to use one instead of the other?
The short answer from Damien — a core committer of Socket.io
The adapter is a component inside the Socket.IO server, while the emitter can be used in another process/service.
And there are two diagrams in the documentation explaining the duties of each package
The long answer
They are pretty similar with the following two differences:
#socket.io/redis-adapter
Must be linked with a socket.io server, And you must provide it a publish and subscribe redis client. like the following:
io.adapter(createAdapter(pubClient, subClient))
Responsible to send/receive socket.io commands to/from other servers.
#socket.io/redis-emitter
Can't be linked with a socket.io server, And you must provide it a publish redis client. like the following:
const emitter = new Emitter(pubClient);
Responsible only to send socket.io commands to the other servers (that has #socket.io/redis-adapter adapter with the same redis database connection and channel key configuration)
Note: These differences applies to all socket.io adapters and emitters (e.g. #socket.io/mongo-adapter and #socket.io/mongo-emitter)
Related
I have a concox GT06 device from which I want to send tracking data to my AWS Server.
The coding protocol manual that comes with it only explains the data structure and protocol.
How does my server receive the GPS data collected by my tracker?
Verify if your server allows you to open sockets, which most low cost solutions do NOT allow for security reasons (i recommend using an Amazon EC2 virtual machine as your platform).
Choose a port on which your application will listen to incoming data, verify if it is open (if not open it) and code your application (i use C++) to listen to that port.
Compile and run your application on the server (and make sure that it stays alive).
Configure your tracker (usually by sending an sms to it) to send data to your server's IP and to the port which your application is listening to.
If you are, as i suspect you are, just beginning, consider that you will invest 2 to 3 weeks to develop this solution from scratch. You might also consider looking for a predeveloped tracking platform, which may or may not be acceptable in terms of data security.
You can find examples and tutorials online. I am usually very open with my coding and would gladly send a copy of the socket server, but, in this case, for security reasons, i cannot do so.
Instead of direct parsing of TCP or UDP packets you may use simplified solution putting in-between middleware backends specialized in data parsing e.g. flespi.
In such approach you may use HTTP REST API to fetch each new portion of data from trackers sent to you dedicated IP:port (called channel) or even send standardized commands with HTTP REST to connected devices.
At the same time it is possible to open MQTT connection using standard libraries and receive converted into JSON messages from devices as MQTT in real time, which is even better then REST due to almost zero latency.
If you are using python you may take a look at open-source flespi_receiver library. In this approach with 10 lines of code you may have on your EC2 whole parsed into JSON messages from Concox GT06.
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 have to set sails app where I can have socket.io connections on multiple ports - for example authentication on port 3999 and data synchronization on port 4999.
Any way to do so ?
I asked a similar question yesterday and it seems that yours is also similar to mine, here's what I'm going to implement.
Given that you will have multiple instances that are going to work on different ports, they won't be able to talk to each other directly and that breaks websocket functionality.
It seems that there are multiple solutions to this (sticky sessions vs using the pub/sub functionality of Redis), I chose Redis. There's a module for that called socket.io-redis. You also need emitter module, it's here.
If you choose that route, no matter how many servers (multiple servers with multiple instances) OR many instances on a single server you run your app on, it will function without a problem thanks to Redis.
At least that's what I know for now, been searching for a few days, haven't tried it yet.
Not to mention, you can use Nginx for load balancing, like below. (Copied from socket.io docs)
upstream io_nodes {
ip_hash;
server 127.0.0.1:6001;
server 127.0.0.1:6002;
server 127.0.0.1:6003;
server 127.0.0.1:6004;
}
I'm currently using Socket.IO with redis store.
And I'm using Room feature with it.
So I'm totally okay with Room join (subscribe)
and Leave (unsubscribe) with Socket.IO.
I just see this page
http://www.rabbitmq.com/blog/2010/11/12/rabbitmq-nodejs-rabbitjs/
And I have found that some people are using Socket.IO with rabbitMQ.
Why using Socket.IO alone is not good enough?
Is there any good reason to use Socket.IO with rabbitMQ?
SocketIO is a browser --> server transport mechanism whereas RabbitMQ is a server --> server message bus.
The two can be implemented together to create a very responsive system in scenarios where a user journey consists of a message starting life on a browser and ending up in, say, some persistence layer (such as a database).
A message would be transported to the web server via socketIO and then, instead of the web server being responsible for persisting the message, it would drop it on a Rabbit queue and leave some other process responsible for persisting it. This way, the web server is free to return to its web serving responsibilities and, crucially, lessening its load.
Take a look at SockJS http://sockjs.org .
It's made by the RabbitMQ team
It's simpler than Socket.io
There's an erlang server for SockJS
Apart from that, there is an experimental project within RabbitMQ team that intends to provide a SockJS plugin for RabbitMQ.
I just used rabbitMQ with socket.io for a totally different reason than in the accepted answer. It wasn't that relevant in 2012, that's why I'm updating here.
I'm using a docker swarm deployment of a chat application with scalability and high availability. I have three replicas of the chat application (which uses socket.io) running in the cluster. The swarm cluster automatically load-balances the incoming requests and at any given time a client might get connected to any of the three replicas of the application.
With this scenario, it gets really necessary to sync the WebSocket responses in the replicas of the application because two clients connected to two different instances of the application wouldn't get each other's messages because they've been connected to different WebSockets.
This is where rabbitMQ intervenes. It syncs all the instances of the application and whenever a message is pushed from a WebSocket on a replica, it gets pushed by all replicas.
Complete details of the project have been given here. This is a potential use case of socket.io and rabbitMQ use in conjunction. This goes for any application using socket.io in a distributed environment with high availability and scalability.
I want to create a messaging service that uses the XMPP protocol. How would I implement the server-side as well as the client side aspects of this service? I know I would need a server (like Jabberd 2) that runs the messaging framework. How hard would this be to set up and get running? Also what would be the best way to hook up a client program into this service? How would i start pushing messages from one client, through the server, to another client?
Server: there are many out there, see http://xmpp.org/software/servers.shtml for a list.
I've used OpenFire in the past, it's fairly straightforward to set up.
You can add a library like xmppframework to your Cocoa project to make it a client, and configure it to talk to your XMPP server.
Each client gets an identifier (called a 'jid') of the form: uniquetext#xmppserver.name, and you send messages from one client to the other by addressing them to the jid of the intended recipient.
If you want to play around with simple examples in a scripting language, you can use something like the examples in the python xmpp library to see how it all works. Use an xmpp client like psi to connect as one jid and use the examples to connect as another jid to send/receive messages through the server.