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.
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.
I have been studying web sockets recently and plan to use them in my application even though the app is not realtime. I am mostly doing this because I want to try it out and further down the line it might open more possibilites for the app's functionality. Also I am not bothered about having an API for mobile at the moment but think it would still be possible to have some kind of api over web sockets if I needed it in the future.
However for in-production apps are there any real reasons why somebody would consider implementing websockets if there is no real-time element?
Are there any benefits over HTTP requests other than the real timeness of it?
HTTP requests include the full HTTP headers. Depending on the cookie load, this may reach a couple of KB per request. WebSocket protocol headers are minimal compared to that. If you have a lot of requests and care about bandwidth then going with WebSocket makes sense.
Additionally a HTTP connection is (traditionally) negotiated for each request, which means you have overhead on each request compared to WebSocket, which has persistent connections. Connection establishment takes time (hence the advantage in real-time applications), but it also uses resources on the server. Again, depending on your app's communication patterns, using WebSocket may make sense.
Most examples I have seen are are just small demo's and not full stack applications and they use websocket for messaging, but for any chat application there is more data then just messages...suppose like user profile, his contacts etc.
So should I use websockets for all communication between server and client or just use them for sending messages and do other things through http? If I am to use websocket for all communication how do url design of the app...since websockets don't have have any different urls like http.
You might be interested in WAMP, an officially registered WebSocket subprotocol that provides applications with WebSocket based
asynchronous, bidirectional remote procedure calls
real-time publish & subscribe notifications
Disclaimer: I am original author of WAMP and work for Tavendo.
Pretty sure you'll get the usual "it depends" answer, because, well, it depends!
If you are going to build a large application, to be used by a number of different clients in different network arrangements etc then I personally wouldn't recommend using WebSockets for everything. Why?
It's a new standard, so not all clients support it
In some network configurations WebSocket traffic may be filtered out, meaning you end up with no communications - not great
If you end up exposing an external API then HTTP is much better fitted for the job and will likely be easier to code against. There are a lot more tools out there to help you with it and styles that everyone is familiar with, like REST, to follow.
Use WebSockets when you require data being pushed from the server without the client having to poll for it, or when HTTP header overhead becomes a problem. And if you still decide to use it make sure you have a fallback mechanism (e.g. longpolling) so you don't end up with no comms.
I'm afraid I can't help you regarding WebSocket API design... given it's a new standard I don't believe the community has settled on anything just yet so you'll have to come out with your own message-based scheme.
I am looking to build an web application using node.js and possibly socket.io but I am having a lots of confusion regarding whether to use socket.io or go with plain http. In the app the node.js server will be basically an api server which serves json to the javascript client or may be mobile clients too. The web app will also has chat messeneger for its users, this is where socket.io comes in.
I am not sure whether to use socket.io for the whole app or only for the chat part. Although my app itself could benefit from socket.io but its nothing that I think can't be done using plain http and client making more requests to the server.
I have read at several places that sometimes socket.io can be difficult to scale for more users.
Socket.io often crashes and specially creates probs when there are firewall in clients system.
More importantly.....I checked out socket.io user list and did not find many users, so was curious to know what kind of platform is more know chat network like facebook messenger, google talk etc are built upon, Are any built using http-ajax and continues querying to the server.
Please help me out in solving this question. Some might argue that this is a opinion based question. But what actually I am trying to figure out the implementation of socket.io and its limitation.
I would suggest serving your API over HTTP and leave the real-time business to Socket.io. If you are adverse to using Websockets, like #GeoPheonix stated, you can choose from a variety of transport methods using both socket.io and sockjs (https://github.com/sockjs/sockjs-node).
As far as scaling is concerned, I deployed a socket.io based real-time analytics/tracking service for a very large application with ana average of 400+ concurrent connections with no visible performance impact, but this may depend on the implementation and hardware.
Socket.io is faster than plain http. I recommend you to use it for all since you have to have a chat in first place.
In my case, real-time Texas Hold'em-like game can receive up to 2500 concurrent with one node process. However, if you change transport from websocket to xhr-polling, It can receive like more 10x than pure websocket. Your application is just chat so, I guess a little slow down wouldn't be a problem. If you sure you will exceed this number, yes, scale socket.io is a pain.
This problem will happen only if you open socket.io for port other than 80 and 443. If you have frontend web server with other language already, you can still use socket.io on another subdomain to be able to run on port 80 without conflict with your main frontend web server. Socket.io support cross-domain without a problem.
Have you used trello.com? If not, try it :). It's best for task management or even some Agile thing. They used socket.io. https://c9.io/ is another one. It's online IDE with google doc-like collaborative. One thing to note is xhr-polling trasport in socket.io is the same with http-ajax with long-polling (Better than general ajax). You can read more info at:
http://book.mixu.net/node/ch13.html
I am to build a chat platform over Node.js, that in core, must be able to to provide chat screens 1-1, much like Olark provides
The chat update rate is not priority, but scalability and browser compatibility are.
My question is: Which back-end strategy and which way to transmit, would be best?
EDIT:
Thanks, #Brandon_R. It is just that I am not sure if websocket is the way to go here, I am between it and AJAX.
I want my server to be able to host multiple calls, and websocket do keep a open connection for each client; isn't it limiting?
Socket.io falls back on ajax polling/other transports if websockets are not available and is probably the way to go. You can also disable websockets/other transports if you prefer not to use them.
socket.io 0.8 also has support for "rooms" which will namespace and multiplex your sockets.