I'm currently looking into using the WAMP-protocol to synchronise between server and clients of my future web-applications.
They recommend using crossbar.io as the router but since Autobahn supports all four roles (publisher, subscriber, caller, callee) itself I'm wondering why I would need another router framework like crossbar.io at all?
I'd like to use node.js with Autobahn|JS as the router and Autobahn|JS in the web-browser as the client. Is this feasible or am I missing something here?
Autobahn(JS/Python/CPP) supports all four client roles, but since WAMP is a routed protocol, you still need a WAMP router. Autobahn does not provide that, and there's now way in which you could use AutobahnJS to create a WAMP router on Node.js.
The WAMP router is not a framework - it's a component which you configure (authentication, authorization, transports etc.) and then just leave running. When everything is configured properly, this is completely transparent for your application.
I'm part of the Autobahn and Crossbar.io projects - so my recommendation is Crossbar.io, but there are other WAMP routers out there. These differ e.g. in regards to the amount of features they implement and their performance. As long as you don't rely on the features of a particular router, you can swap out the WAMP router at any time.
Related
I am surprised that I need third-party services such as Pusher or Redis to have a bidirectional communication from my server to my clients through WebSockets.
What are the advantages of Pusher over Redis or simply a socker.io server aside from nginx? I see many disadvantages:
Rely on a third-party service
Pricy above 200k messages a day
Cannot work on LAN without Internet
From my understanding, they are only two possible solutions with Laravel:
Laravel Echo + Redis
Pusher
Laravel Websockets
Pusher Php Server
Is there a third alternative?
There is a clone of pusher server available on laravel, have you checked it?
https://beyondco.de/docs/laravel-websockets/getting-started/introduction
You can use this on LAN.
This runs a php-socket server on some port
like 5000
Just use Laravel Echo or Pusher SDK for mobile apps and
connect it to your server on 5000 port.
You don't have to pay anyone, it runs clone of pusher server on your
server.
The benefits of using a third party solution are different per use case and per person. However, broadly speaking there are a couple of benefits that haven't been mentioned here that are worth highlighting:
Hosted solutions do not require you to implement your own infrastructure to manage the websocket connections. This means you don't need to worry about the uptime, security, provisioning or maintenance of the infrastructure, this is done for you.
Hosted solutions scale seamlessly. As your app user base grows and your connections grow, you no longer need to provision more infrastructure and load balance/route connections.
Hosted solutions such as Pusher have dedicated support teams to help during implementation/troubleshooting.
Hosted solutions often have round the clock server monitoring, ensuring the platform is available 24/7 without the need for you to respond to server alarms in the early hours.
A lot has been said about build vs buy over the years, and there are many resources that discuss the merits of both (in fact Pusher has a resource for this). Ultimately this is not a decision that can be made for you, you will need to assess your application requirements and then look at what best fits your use case.
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 had a huge confusion in WebSockets. I read some blog about WebSockets and it requires node websocket server, I downloaded the demo files and the chat application didn't seem to work. To summarize this, what do I need to use WebSockets? Do I need to download node server or something? And what is something to relate with socket.io to one another?
WebSockets?
WebSockets is a standard for implementing socket communication (to a server) over the web.
Is node required?
Now this server which the socket communication prevails between can be implemented in any way whatsoever. Node is surely a popular option to implement the server side in however its not the only, you can use python, erlang, ruby, or any other language where you can bind a socket connection.
What is socket.io?
socket.io is javascript library which makes it possible for socket OR socket-like connections over the web. See the WebSockets is a recent standard, not all browsers support it, only the modern ones do (proof: http://caniuse.com/#search=websockets). What makes socket.io so popular, rainbow and fairy tale like (and one of the main reasons why you happened to stumble upon it while researching WebSockets) is that it will make socket/socket-like communications possible in all browsers.
socket: when socket.io detects a browser supporting WebSockets, in which case it uses this WebSockets implementation for the socket communications.
socket-like: however when socket.io detects a browser which does NOT support WebSockets it will still provide you with socket-like communication. Tid bit: the internals of this feature use AJAX polling.
Node is a good place to start for websockets, but by no means the only place.
I would probably start here:
http://www.html5rocks.com/en/tutorials/websockets/basics/
sorry for my dumb question, now that i got that i must use Javascript to use Websocket, this is client-side, but what about Serverside, why do i find people talking about RabbitMQ, Stomp, SocketIO, Tornadio
in the Tornado example, no one of them exists, so i said that Tornado is enough, but i found that people use them even with Tornado, here and here.
So what do i use? and for what?
Actually Tornado is a web-server and it supports web-sockets. Other things in your post are not webservers.
RabbitMQ is a message queue service, it's used to communicate between different services on the server
STOMP is a protocol to work with message queues.
Socket.IO is a framework that allows you to use websockets easily. But it requires Node.JS server on the server side. Socket.IO provides you some fallbacks if browser do not support WS protocol. Tornadio is a port of Socket.IO to Tornado. So you can use the same client framework (in web-browser) but on server-side you use Tornado instead of NodeJS.
So Tornado is enough for websockets. But if you'd like to create more complex apps you'll have to use other tools for other tasks. From your list - you can use Tornadio to deal with legacy browsers and RabbitMQ for interprocess communication on your server