I need a websocket server in order to be able to deliver server side events to my web application. Is there any library to build a websocket server using scala, preferably akka?
The Play Framework (http://www.playframework.com/) has strong support for web sockets (http://www.playframework.com/documentation/2.2.2/ScalaWebSockets). Play also plays well with Akka (http://www.playframework.com/documentation/2.2.2/ScalaAkka).
Note: SSEs are not WebSockets. WebSockets are for duplex communication between server and client while SSEs are only server to client. Both can be done in Play. See http://matthiasnehlsen.com/blog/2013/05/01/server-sent-events-vs-websockets/ for an illustrative example.
Related
I have read up on web sockets providing full duplex connections over TCP which can be used in scenarios where long polling was used to get live updates to client from server. Now I have a Tomcat based application which serves multiple REST based web service response, and I want couple of API's to be implemented using web sockets say to render dashboard with latest data where multiple users are working on them concurrently, is that possible ? My concern here was even if the connection was upgraded to TCP from HTTP wouldn't web socket require a separate port to run than the default Tomcat port 8080. In that case should I house the Web Socket based endpoints separate to the Tomcat based application already running. Please do correct me if any of the above is wrong.
A couple of month ago, I wrote a small Spring Boot webapp with embedded Tomcat that provides both, REST endpoints and websocket support, and both via the same port. So, yes that works... if you wanna sneak a peek: https://github.com/tommybrettschneider/pinterest-boot
Besides that, this post should also clarify things:
Shall I use WebSocket on ports other than 80?
I have a game I am working on and I heard that UDP is superior for real-time games. I know that socket.io uses TCP and was wondering if there is some way to switch it to UDP. I tried looking it up but only found posts from around 2012 which said UDP is only experimental in browsers.
From a standard browser, it is not possible.
From a browser client, socket.io uses either the http or the webSocket transport. Both http and webSocket are TCP connections, not UDP connections. So the browser client socket.io does not use UDP - it uses TCP.
As best I know, there is no standard UDP support in browsers accessible from regular HTML page Javascript so you can't even really try to build your own layer that uses UDP.
Other references on the topic:
Why Can't I Send UDP Packets From a Browser
Reading from udp port in browser
Chrome Supports TCP and UDP Sockets
Write a chrome extension to support UDP in browser
How to send a UDP Packet with Web RTC - Javascript?
How to talk to UDP sockets with HTML5?
Reading from udp port in browser
UDP can be a desirable transport for some circumstances when you want the packet to be delivered as soon as possible, but if it can't be delivered immediately, then just drop it. This is sometimes useful in gaming or even video streaming where the next packet will just contain the next update so if the previous one didn't come through, then no big deal and you'd rather not have TCP try to retransmit the lost packet. But, browsers don't support using the UDP protocol from web page Javascript.
If you want to connect to a UDP device or server from a browser, you will have to use some sort of proxy so your browser code can talk to the proxy over TCP (either http or webSocket) and then the proxy can handle the actual UDP communication with the device.
It would be possible to use the socket.io library from node.js or some other non-browser platform and write your own UDP transport add-in for socket.io that is built on the native UDP support in your platform. I believe socket.io has a somewhat pluggable transport so you could try to make your own transport and then configure both client and server to use that transport. This is not possible from the browser (without a native code plug-in installed in the browser) because there's no underlying UDP support in the browser that you could build your transport on, but in non-browser environments like node.js, you could do that.
It might be a good idea to use webRTC in this case which is UDP in nature.
Although the question is already answered, I want to point out that there are ways to implement socket.io with UDP. For example dgram does exactly what you are looking for.
This is a tutorial for socket.io + UDP with dgram.
UPDATE:
Alexandre Lacheze developed a node.js package that brings UDP to browser. It also supports socket.io. So the answer is somehow obsolete now.
UPDATE 2:
It turn out it is just a simulated UDP. Not an actual UDP protocol running on browser.
Play documentation only describes changing the default 9000 port to some other by -Dhttp.port <port> argument.
Is it possible to use unix socket instead of port? Due to administrator's policy every application has to provide socket which is then used by nginx used as front end web server.
I've found a chapter in play docs about using nginx but again - it only covers app running at port.
I'm using play 2.2.0.
There is no support for listening to unix sockets in Netty which Play uses as http server. There is a third party library for Netty but you will probably not be able to plug it into Play without some serious messing around with the framework internals.
https://github.com/Flipkart/phantom/wiki/Unix-domain-socket-transport-for-netty
If answer is "using xmpp BOSH", then to use BOSH, we need to have in-between CM (Connection Manager) server that would interact with xmpp server. So that xmpp client to CM interaction will then happen over normal http protocol (which will be scalable), but again CM to xmpp server will happen using long-live tcp connection which will cause scalability issue.
How can we make xmpp client-server more scalable??
Bidirectional-streams Over Synchronous HTTP (BOSH) is basically a technology to keep the connection alive to allow the system to send and receive the data to and fro. To be able to use xmpp over the HTTP, you will have to use BOSH.
For you concern about the scalability, you can basically use components which are meant for scalability such as Nginx a component in place of Apache httpd, also there are many connection managers available with Punjab being the most scalable of all. If you are using Openfire as a XMPP server, it has a prebuilt connection manager which has proved scalability.
When deploying a web application running on a traditional web server, you usually restart the web server after the code updates. Due to the nature of HTTP, this is not a problem for the users. On the next request they will get the latest updates.
But what about a WebSocket server? If I restart or kill the old process all connected users will get disconnected. So my question is, what kind of strategy have you used to deploy a WebSocket server smoothly?
You're right, every connected user will be disconnected if the server restarts.
I think the less bad solution is to tell to the client to reconnect in the onClose method of the client.
WebSockets is just a transport mechanism. Libraries like socket.io exist to build on that transport -- and provide heartbeats, browser fallbacks, graceful reconnects and handle other edge-cases found in real-time applications.
In our WebSocket-enabled application, socket.io is central to ensuring our continuous deployment setup doesn't break users' active socket connections.
If clients are connected directly to sever that does all sockets networking and application logic, then yes - they will be disconnected, due to TCP layer that holds connection.
If you have gateway that clients will be connecting to, and that gateway application is running on another server, but will communicate and forward messages to logical server, then logical server will send them back and gateway will send back to client responses. With such infrastructure, you have to implement stacking of packets on gateway until it will re-establish connection with logical server. Logical server might notify gateway server before restart. That way client will have connection, it will just wont receive any responses.
Or you can implement on client side reconnection.
With HTTP, every time you navigate away, browser actually is creating socket connection to server, transmits all data and closes it (in most cases). And then all website data is local, until you navigate away.
With WebSockets it is continuous connection, and there is no reconnection on requests. Thats why you have to implement simple mechanics when WebSockets getting closing event, you will try to reconnect periodically on client side.
It is more based on your specific needs.