I was wondering if Foxx/ArangoDB supports Socket.io ? Or would I have to fire a separate Express.js server if I want to use sockets.io ?
closing this QA, found threads below.
https://github.com/triAGENS/ArangoDB/issues/602 - Add support for websockets
https://groups.google.com/forum/#!topic/arangodb/F4geU6_KI8M - ArangoDB and Web Sockets
Related
How to establish connection and send messages to remote WebSocket server from ASP.NET Core?
Is it possible now or I should wait for SignalR library to achieve this?
Sounds like you're looking for System.Net.WebSockets.Client. It's available, but not on all platforms (https://github.com/dotnet/corefx/issues/2486).
I have seen two implementation of websocket in dart:io and dart:html. Which one should I use? Currently I prefer more the websocket in dart:io since it seems to fit more naturally how dart handle streams and asynchronous programming.
The dart:html library is used on the client-side and can be compiled to JavaScript.
Use dart:io for server-side code.
In a typical setup, you have a web server listening to WebSocket connections from the client, in which case you would use the one from dart:html. But of course you can also initiate WebSocket connections at the server if you ever need :)
dart:io is only available on the server
dart:html is only available in the browser
I'm reading up on SockJS node server. Documentation says:
Often WebSockets don't play nicely with proxies and load balancers. Deploying a SockJS server behind Nginx or Apache could be painful. Fortunately recent versions of an excellent load balancer HAProxy are able to proxy WebSocket connections. We propose to put HAProxy as a front line load balancer and use it to split SockJS traffic from normal HTTP data.
I'm curious if anyone can expand on the problem that is being solved by HAProxy in this case? Specifically:
Why websockets don't play nice with proxies and load balancers?
Why deploying Sockjs sever behind Apache is painful?
1. Why websockets don't play nice with proxies and load balancers?
I'd recommend you read this article on How HTML5 Web Sockets Interact With Proxy Servers by Peter Lubbers. It should cover everything you need to know about WebSocket and proxies - and thus, load balancers.
2. Why deploying Sockjs sever behind Apache is painful?
There is a module for handling WebSocket connections but at present Apache doesn't natively support WebSocket, nor does it look like it will any time soon based on this bug filed on apache - HTML5 Websocket implementation. The suggestion is that it actually fits the module pattern better.
So, it's "painful" simply because it's not easy - there's no official support and therefore it doesn't have the community use that it otherwise may have.
There may also be other pains in the SockJS has HTTP-based fallback transports. So you need to proxy both the WebSocket connections (using the apache-websocket module) and also HTTP requests when fallback is used.
Related to this: Nginx v1.3 was released in February with WebSocket support.
I'm experimenting with mqttjs and websockets and I wish to be able to send messages from a webpage using websockets without a bridge to an MQTT broker that is run by mqttjs. I can't find any information if this is available or even possible.
I've looked at mosquitto and they have "experimental" websocket support and I would love to find a Node.JS MQTT broker which could offer the same.
Thus far I got the communication working with pywebsocket and Socket.IO. I would really appreciate pointers in any direction if it is possible to use websockets to mqtt without bridging.
Thanks.
Is old question but is good to share my findings.
You can use the mosca broker that is written in node.js and is using mqtt.js
The mosca is supporting classic mqtt connection and mqtt over WS :
MQTT-over-Websockets
Mosca can operate in two modes: Standalone and as a node.js module.
In general mosca can support many types of brokers:
Mosca-advanced-usage
HiveMQ supports native websockets, which means you can use any Javascript MQTT library (like Eclipse Paho.js with websockets. It's perfectly possible to connect some clients vie websockets and other clients via standard TCP connection. The websocket support is stable and used in production.
The only drawback for you could be that HiveMQ is not written in Node.JS.
Disclosure: I am one of the developers of HiveMQ.
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