I'm working on a robotics web application that connects to the server using Websocket. Server is built on RosBridge and implemented with Tornado Web.
For the web UI, use can have the websocket disconnected for the following 3 reasons.
- Server is down.
- Another user has kicked you out of the session.
- Session token has expired.
The best way for the server to convey this information to the UI is to set the close reason and/or code (only need one of the two) to the UI. My understanding is that websocket protocol allows for that, but the option seems to be missing from the Tornado API.
The "close reason" field is not currently supported in Tornado. See https://github.com/facebook/tornado/issues/890
Related
I'm building a chat application with a custom web socket controller and I want to establish a two way communication between different clients with the server in the middle in such a way that whenever a client sends a request, it gets updated on the server and the server emits a response to all the clients.
Note: I've tried using IHP's Auto Refresh but using that is turning out to be quite expensive for my use case so that's why I'm trying to set up a custom web socket controller.
Check out the new IHP DataSync API: https://ihp.digitallyinduced.com/Guide/realtime-spas.html
It's higher level than websockets but likely can help you implement the chat app.
I am building an app in which I provide functionality X, Y and chat.
Lets say that X and Y are non-interactive eg. reading articles - which will work fine with REST (on a node.js server) while chat is obviously interactive so it will work best with socket.io!
Questions: 1. Is it possible for me to 'switch on' a socket between the server and the user when the user navigates to the chat part of the application? 2. Can I open up a socket inside a GET request for the url: example.com/chats/usr_id on the node.js server?
3. How can this be accomplished inside a Backbone routing framework?
Yes. Just initialize the connection when the view is rendered (via a controller or script). See socket.io client documentation. You can just connect when the view is rendered and disconnect when the view is terminated. http://socket.io/docs/client-api/
You cannot open sockets with a GET request. Socket.io has it's own build in mechanisms for connecting to a socket server. It will start with Web Socket protocol and fall back to Long Polling. You can however use custom url's for unique things. One again, consult the socket.io documentation: http://socket.io/docs/client-api/
http://www.sitepoint.com/chat-application-using-socket-io/
p.s. I'd suggest reading up on how Web Sockets work, as you don't seem to have a very strong understanding.
I am writing a game in node.js with socket.io library. It has a server to whom 2 clients connect and play. My game is working fine, but there is a problem.
If a client that is already connected connects again to the game it is considered as 3rd connection request which messes things up.
This usually happens when I restart my node server when client browsers were not closed. I do I get around this.
You can use cookies. There are modules for this: Socket.IO Authentication
But you can also do it manually, as it is a simple cookie:
When a user connects, add a step to identify the user before starting the game. This step should create a cookie or use the existing one and send it to the server for authentication.
It's not difficult, you can read and write cookies with javascript, and sending a String/number to the server is not a problem either (websocket.emit('auth',whatever)).
Based on this example, it looks like its possible to use cookies to identify sessions in socket.io, but you may be better off using query string values to identify a particular browser or computer:
https://www.exratione.com/2013/05/the-use-of-cookies-versus-query-string-tokens-to-identify-sessions-in-socketio/
Background: I am building a web app using NodeJS + Express. Most of the communication between client and server is REST (GET and POST) calls. I would typically use AJAX XMLHttpRequest like mentioned in https://developers.google.com/appengine/articles/rpc. And I don't seem to understand how to make my RESTful service being used for Socket.io as well.
My questions are
What scenarios should I use Socket.io over AJAX RPC?
Is there a straight forward way to make them work together. At least for Expressjs style REST.
Do I have real benefits of using socket.io(if websockets are used -- TCP layer) on non real time web applications. Like a tinyurl site (where users post queries and server responds and forgets).
Also I was thinking a tricky but nonsense idea. What if I use RESTful for requests from clients and close connection from server side and do socket.emit().
Thanks in advance.
Your primary problem is that WebSockets are not request/response oriented like HTTP is. You mention REST and HTTP interchangeably, keep in mind that REST is a methodology behind designing and modeling your HTTP routes.
Your questions,
1. Socket.io would be a good scenario when you don't require a request/response format. For instance if you were building a multiplayer game in which whoever could click on more buttons won, you would send the server each click from each user, not needing a response back from the server that it registered each click. As long as the WebSocket connection is open, you can assume the message is making it to the server. Another use case is when you need a server to contact a client sporadically. An analytics page would be a good use case for WebSockets as there is no uniform pattern as to when data needs to be at the client, it could happen at anytime.
The WebSocket connection is an HTTP GET request with a special header requesting the server to upgrade it to a WebSocket connection. Distinguishing different events and message on the WebSocket connection is up to your application logic and likely won't match REST style URIs and methods (otherwise you are replication HTTP request/reply in a sense).
No.
Not sure what you mean on the last bit.
I'll just explain more about when you want to use Socket.IO and leave the in-depth explanation to Tj there.
Generally you will choose Socket.IO when performance and/or latency is a major concern and you have a site that involves users polling for data often. AJAX or long-polling is by far easier to implement, however, it can have serious performance problems in high load situations. By high-load, I mean like Facebook. Imagine millions of people loading their feed, and every minute each user is asking the server for new data. That could require some serious hardware and software to make that work well. With Socket.IO, each user could instead connect and just indefinitely wait for new data from the server as it arrives, resulting in far less overall server traffic.
Also, if you have a real-time application, Socket.IO would allow for a much better user experience while maintaining a reasonable server load. A common example is a chat room. You really don't want to have to constantly poll the server for new messages. It would be much better for the server to broadcast new messages as they are received. Although you can do it with long-polling, it can be pretty expensive in terms of server resources.
I had a use case where i was planning to poll from browser to server to check any updates for a given customer.Then i thought
of exploring push approach where webserver(in my case tomcat) can do it automatically whenever servlet running on webserver
gets any update from thirdparty.First question came to my mind how javaclass will know to which browser client it has to send
update.Then i came across the link at http://www.gianlucaguarini.com/blog/nodejs-and-a-simple-push-notification-server/.
This is the amazing link that demonstrates how push approach can be supported.But i came up with some basic question to go
ahead with this approach. These are:-
1)Does browser internally uses the websockets only to communicate with webserver or they just used TCP for that?
As per my understanding browser uses only TCP protocol though it is supported by some brosers like chrome,mozilla
2)Does the websocket (provided by io.connect('url')in the example) supported by all browsers specially IE7,IE8
As per my understanding
3)To support the push approach on browser, websockets are the only way to go?
As per my understanding, websockets are mainly used to push the data from webserver to browser(only those that support websockets)
For this first browser needs to make the websocket connection to webserver.Now server will use the created websocket to emit any
data to browser.Right?
4)Is there a possiblity when websocket get automatically disconnected like in case request gets timeout or response is awaited for long time?
5)Do we need to disconnect the socket explicitly or it will be closed automatically when browser is closed?
It would be really helpful if reply is pointwise.
WebSocket protocol is TCP protocol. It's just that it starts as HTTP and then it can be upgraded to TCP.
Internel Explorer is supposed to support WebSockets in version 10. The other major browsers (Chrome, FireFox, Safari, Opera) do fully support it.
There are many other possibilites. Simply polling, long polling ( where you make one ajax request and server responds only when he has new data ), hidden infinite iframe, use of flash, etc.
Yes.
Once an application which is using a port ( in that case a browser ) is killed, then all connections are terminated as well.