Socket.io there have been some eternal confusions.
It is supposed to fall back to mechanisms that the browser supports. Does that mean on latest browers it will use websockets over anything else? or does it need to be specifically told to use websockets.
websockets by themselves do they use polling or any other method where other forms of messaging like MQTT excel?
With both these points in mind has anyone taken a note of how socket.io and its working impact the battery life of a device. Considering phongeap/cordova apps having socket.io running inside a embedded browser.
Related
I have built a multiplayer game with real time leader board. The game is in PHP(Backend) + Flex(Front end).
I have used socket.io for real time communication with a node.js server. But I am facing a lot of problem with respect to proxy settings on my client network configuration. Most of the time my application doesn't communicate with my node(socket) server. It is not able to establish a connection because of proxy configurations.
What alternatives can I go with? I tried to search a lot for alternatives. I came across services like pusher and pubnub, but those are little expensive. Have anyone tried Amazon SNS, is it suitable for this?
Thanks!
The reason that you cannot connect through proxies, is because socket.io is using web sockets. See Socket.io and firewall Software (that page also includes a link to test websocket connectivity). There are a number of ways you can mitigate this problem:
Use secure websockets (wss://)
But this does also not guarantee for 100% that it will work.
Use one of the fallback mechanisms of socket.io: Flash, Ajax, iFrame, JSONP, ...
For more information, see Configuring Socket.io.
There is SocketCluster: https://github.com/topcloud/socketcluster
It runs on multiple CPU cores and it's good with error-handling (workers auto-respawn). It has no identified memory leaks (just make sure you use latest version of Node.js).
I'm in the process of implementing a streaming protocol in JavaScript. The protocol is defined in terms of byte streams, not messages. I'd like to be able to talk to browsers using this protocol.
I've used Socket.io in the past for easy cross-browser full-duplex networking. However, in this case, I need BSD-style sockets. Ideally, I could code to the Node.js streams API and have the same (or very similar) code work in the browser.
Is there something like Socket.io for byte streams? ie Well tested, cross-browser, multi-transport, heart beating, etc.
So far, http://binaryjs.com/ is the closest to what I need. Unfortunately, the documentation suggests it is somewhat immature. I'd be very happy to find a more stable library with wider browser support.
Socket.IO uses lots of tech behind the scenes in order to make it very accessible and reliable. Lots of users will have Long Polling fallback, which is just pure HTTP protocol.
While WebSockets do support binary type of messages, it will be not the same as Long Polling or any other fallback tech, so Socket.IO will not support it as far as it is not something on all transports.
As well WebSockets and Socket.IO is purely Message Based communication protocol. In case with WebSockets it has framing around each message which will drive overhead for streaming.
What you need is Stream based communication, but not Message based. As I am aware this is long topic, and still not clear in web world.
Although you could look into WebRTC as future possibility for streaming data and it might meet your needs.
Some other options is to use plugins or extensions for browsers, like flash, unity, bespoke stuff and so on, in order to enable real streaming features.
I have been making a node.jss + express + socket.io application on Heroku. I recently realized they don't support websockets, which would be ideal for real-time communication. They force you to use long polling, which uses http instead. I want to do this the right way, but on the other hand, I don't want to go through setting up this project again since it's just a proof of concept/getting me used to node.js.
What's the right move here? continue on heroku and then possibly change the app later to work with sockets, or start over using a different service than heroku? Things to take into consideration here are the amount of code I would have to change, and the loss of functionality for sticking with long polling instead of websockets. I have no idea how either of these will be effected.
Thank you
socket.io works fine using xhr-polling instead of websocket. Performance will not be as good but very few cloud offerings support it for more than one instance today.
Now that nginx has support for websocket, this may change soon.
If you want to just mess around with sockets and node, I'd recommend nodejitsu instead. I used it and was very happy with it. I am now back on Heroku though since it suits my needs better (and the apps don't require real-time interaction and polling is sufficient). Nodejitsu supports actual websockets.
I got a server running SignalR and another server runing Node.js. I would like these two servers to communicate using SignalR. Is this possible?
I'm thinking I can use the SignalR client javascript library to connect to the SignalR server from Node:js but I can't find any good examples of how to do this.
Well the answer to can you do this is ultimately "yes" because there is nothing proprietary about SignalR communication. It's just variations of HTTP or WebSockets with a custom handshake/message framing protocol for Hubs on top of that.
So the how is the question we'd need to answer. Out of the box SignalR provides a client side JavaScript library based on the jQuery plug-in architecture, but that won't help Node.js. Someone has started a Node.js implementation here on GitHub, but according to the ReadMe it only supports HTTP long polling today. I'm unaware of any other implementations at this time, but obviously you start with that one and fork it to add support for the other transports if you wanted.
How can I send low latency data to a server and back with phonegap?
Considering I don't have access to php files locally, and don't have experience with node.js or WebSockets I don't know which ones I should use.
WebSockets aren't natively supported by the browsers in Android or older versions of Cordova under iOS, which means you'll need to use a PhoneGap plugin if you want to use them on the client.
There's more information at: http://remysharp.com/2010/10/04/websockets-in-phonegap-projects/
However, I'm not sure (even with the plugin) how resilient WebSockets are likely to be when the device moves between network connections (WiFi -> 3G -> WiFi), so using a simple polling web service may be a more reliable option if your app needs to continue receiving data as your users move around.
If you need to receive data initiated by the server, consider using push notifications instead: both iOS (APN) and Android (C2DM) provide APIs to do this which make more efficient use of the battery than having your app poll your server constantly.
You can use WebSockets in PhoneGap with iOS and Android. WebSockets are natively supported on iOS within Safari. For Android you will need to use a polyfill.
See: https://stackoverflow.com/a/13527585/39904
The answer above provides information about how to make a WebSocket object available within the Android WebView used by PhoneGap and also provides a link to a sample project which you can use to get started.
WebSockets were developed as a solution to 'Comet' hacks. As such they provide a very low latency solution for realtime bi-directional communication between a client and server. This means low bandwidth and low resource usage - battery on mobile - since you are holding a single connection open rather then opening and closing multiple HTTP connections. A polling solution which makes requests at regular intervals is likely to drain the battery much faster than a WebSocket solution. If you are polling at lower intervals then it may be fine - it depends on your use case.
In terms of WebSockets working as you change between network and network type (WiFi -> 3G -> WiFi) then if you are using WebSockets natively you need to detect the onclose and reconnect. You will also need to determine the best type of connection; unsecure (WS) or secure (WSS). I would highly recommend you use WSS for mobile since some mobile network providers use transparent proxies which interfere with WS connections. This might sound complicated but there are a number of libraries that handle this for you. Such as the Pusher JavaScript library (note: I work for Pusher). Libraries such as these also provide fallback to a less efficient HTTP-based solution when the environment will not let any WebSocket connection occur.
Also see: realtime web technology guide.
I'd agree with #rmc47 that you should consider native push notifications if it's for infrequent single notifications
Refer to this link to see WebSocket Support by Browsers and devices : html5test.com site - iOS 4.2+ already supports WebSocket
See this doc that explains how to develop a simple application with WebSocket.
Unfortunately the content is in the Portuguese (Brazilian) language but you can leave comments which I will answer.
I'm not sure what you mean by "access to PHP files locally". The use of node.js and web sockets is also not mutually exclusive.
If you have not made a decision on the server implementation you could go for either node.js or ASP.NET.
node.js has good support for sockets with Socket.io, which abstracts the client implementation for you. So it will use WebSockets if there is support, else it will fall back to long polling.
ASP.NET has a library called SignalR which does something similar for the .NET platform.