What are the security issues for the socket io in nodejs
Which one is better for real time updation using node js. Either socket io or long polling.
Socket.io is a websocket. If you deploy your code in a shared hosting environment or if you are going via a firewall the websocket protocol might not work.
You can configure socket.io to default to a long-polling strategy in that case (which uses XHR requests). You will send your data normally to the websocket API, and it will decide which strategy to use. Long-polling is more cpu-consuming and it uses 2 sockets as it stablishes a 2 ways communication with the server.
Related
When I read about how to create chat applications in Node.js, I found out that the recommended way to do so was to use Socket.io and websockets.
I also read that we can regularly send requests using AJAX and wait for responses from the server.
So my question is: Can AJAX serve the same purpose as WebSockets, and use AJAX for chat applications instead of WebSockets?
You don't have to use websockets for chat applications, there is actually a wide range of technologies you can use.
AJAX: AJAX, or long polling can be used for web chats, but is considered a primitive and inefficient way to get updated chat information. The client listens for a change on the server-side, then when it get's a response from the server, it then makes another request to listen for requests. The reason this is looked down upon is because they client could be listening for a long time, without a response from the server.
WebSockets: Websockets is a protocol that runs over HTTP that facilitates bi-directional data. Similar to the TCP websocket protocol, there is a 3-way handshake involved in order to make a connection. Socket.io aids in the use of websockets by abstracting a lot of the raw websocket functions. The truth is that Socket.io actually provides backwards compatibility with browsers that only support long-polling or Flash for chat communication. Unlike WebRTC, there is a man-in-the-middle (server) to facilitate who is chatting with who.
WebRTC: WebRTC is a free, open project that provides browsers and mobile applications with Real-Time Communications (RTC) capabilities via simple APIs. These protocols allow peer-to-peer communications (chat included) with little use of a middle-man, or server. To address your question, it's great for "private-chats".
Flash: It is possible to use Flash for chat communications over the web. This is severely outdated, as Flash is slowly dying from the web.
Normally i use ajax http requests to get/post data. Now i have thoughts like why shouldn't i replace all the ajax get requests with socketIO?is there any disadvantage in following this approach?
I understand that session cookies via http headers will be sent between client and server during every http requests, during client<=>server interactions using sockets, will the session cookies in browser automatically sent to the server via socket headers(if that exists)?
In which usecases should i prefer SocketIO over Http?(if you consider this as a question that demands broad answer then you can link me to some relevant articles)
WebSockets are useful when the server needs to push some real time information to the client about some events that happened on the server. This avoids the client making multiple polling AJAX calls to verify if some event has occurred on the server.
Think of a simple chat application. If the client needs to know if the other participant in a chat session has written something in order to display it, he will need to make AJAX calls at regular intervals to verify this on the server. On the other hand WebSockets allow the server to notify the client when this even occurs, so it is much more efficient in terms of network traffic. Also the WebSockets protocol allows the server to push real time information to multiple subscribed clients at the same time: for example you could have a web browser and mobile application subscribed to a WebSocket and talking to each other directly through the server. Using AJAX those kind of scenarios would be harder to achieve and would require much more stateless HTTP calls.
I understand that session cookies will be sent between client and server during every http requests, is this case the same during client<=>server interactions using sockets
The WebSockets protocol is different from the HTTP protocol. So after the initial handshake occurs (which happens over HTTP), there are no more notion of HTTP specific things such as cookies.
There's one important thing that you should be aware when using WebSockets: it requires a persistent connection to be established between the client and the server. This could make it tricky when you need to load balance your servers. Of course the different implementations of the WebSockets protocol might offer solutions to this problem. For example Socket.IO has a Redis implementation allowing the servers to keep track of connected clients through a cluster of nodes.
I would like to code a performance test creating hundreds of concurrent websocket connections to a vendor's server, that will randomly send/receive messages and then hangup.
Can I use Websockets with nodejs to do this and will this be considered event driven?
To be clear, I am not building a websocket server. I basically want to use nodejs as a client to connect to an outside websocket server but create hundreds of concurrent connections that it will respond to.
Thanks.
Yes you can use node.js and yes it will be event driven. All network I/O in node.js is exclusively asynchronous and event-driven.
Be aware substack's rant in the hyperquest README about node.js core http module's connection pooling, which you will want to make sure you bypass. Presumably you'll be using a helper library such as socket.io or sock.js. Just check that they will create the number of connections you want to a single server without any pooling or throttling.
I have a SPA application (Backbone on client and node.js on server). It all communication in both directions is through via websockets. Now I wondered - it's a good idea? What are the cons before approach: the client sends data to the server via the REST API, and server sends data to client via websockets?
thanks.
UPD:
I have websockets in any case because my app is multiroom chat.
Even if you only consider RPC ("Remote Procedure Calls"), REST is less capable than WebSocket.
REST, since it runs over HTTP, cannot pipeline RPCs. Each HTTP connection can only serve 1 RPC synchronously. And browsers limit the number of parallel HTTP connections to a given origin.
With RPC over WebSocket, you can fire off 100 RPCs pipelined, and process RPC returns asynchronously as they come in.
Then, with WebSocket, you can have server-initiated notifications as well. E.g. you can have full-flavored Publish & Subscribe.
WAMP ("The Web Application Messaging Protocol") runs over WebSocket and was designed exactly for this: SPAs that need 2 messaging patterns in 1 protocol - RPC and PubSub.
Disclaimer: I am original author of WAMP and work for Tavendo.
If server needs uncertain time to prepare data, it may be a good idea though
basically there is no reason to use websocket(socket.io) for REST API.
because of what REST API stands for,You don't have to keep connection stablished nor don't have to wait for someones action like broadcasting server.
EDIT answering the comment
even if you already used websocket,it doesn't mean you can't handle normal req/res.
RESTapi with websocket is like
get request -> server response -> client try io.connect(); -> connection established -> server send data to the client thru websocket
and normal REST API is like
get request -> server responce
which do you choose?
I want to use dotcloud with node.js + socket.io for realtime applications.
But they don't support websockets.
Will there be noticeable bandwidth or performance degradation by relying purely on fallbacks?
Is it worth it to use my own server? Linode or aws or whatnot.
Thanks.
I'm implementing an instant messaging system which depends completely on websocket. As the web is evolving quite fast and websocket was in the web standard, I decided to use flash websocket fallback for any browser that don't support it by default (Firefox, Opera). Here is what you may want to know:
I use websocket. I use a pure websocket server. I don't use any other protocols. I don't use socket.io. I must say that if you decide to use only websocket, you won't have benefit from socket.io lib, even the development time. It only adds unnecessary overhead to your server because of multiple transportation layers support.
At client side, I use websocket + flash websocket fallback which implements websocket specs using flash socket and I would say that there's no noticable difference. The only thing you should know that is due to the "same origin policy", you may need to serve flash socket policy request your own (run on port 843 by default) to allow the flash socket to connect in.
We're currently using private server because we have a dedicated sysadmin. However, it's better if you can just focus on doing what you intended to do, and not on unwanted things. Oh, and sometimes, it's better if you have complete control of your own server :-).
Hope it helps.