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).
Related
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.
I am implementing a product that will be accessible via web and mobile clients, and am doing thorough research to make sure that I have chosen a good set of tools before I begin. For front-end, I am using AngularJS (Angularjs + angular-ui on web, ionic + cordova on mobile), and because I want to have a single backend serving all types of clients, I plan on implementing a RESTful service (likely one that accepts and returns JSON data). I am leaning towards using Mongo, Node, and Express to create this RESTful API, but am open to suggestions on that front.
But the sticking point for me right now is this: certain parts of the application (including, for example, a live chat/messaging section) need to be real-time. I am aware of the various technologies and protocols for implementing real-time web services (webhooks, websockets, long polling, etc.) and the libraries and frameworks that implement them and expose that functionality (SockJS, Socket.io, etc.) and I want to be clear that I am not asking one of those "what is the best framework" types of questions.
My question is rather about the correct way to implement these two kinds of services side-by-side. Should I be serving the chat separately from the rest of the application? Or is there a clean way to integrate these two different protocols into the same application?
The express framework is quite modular so it can sit side by side with a websocket module if you so wish. The most common reason for doing this is to share authentication routines across http and websockets by using the same session store in both modules.
For example you would authenticate a user by http with the express framework when they login, which will allow access to your chat application. From then on you would take advantage of the realtime and speedy protocol of websockets and on your server code you will check the cookie that the client sends with the socket message and check that the request corresponds to an authenticated session from before.
Many websites use websockets for chat or other push updates, and a separate RESTful API over AJAX, delivered to the same page. There are great reasons to leave RESTful things as they are, particularly if caching is an issue--websockets won't benefit from web caches outside your servers. Websockets are better suited for chat on any modern browser, which trades a small keep-alive for a reconnecting long-poll. So two separate interfaces adds a little complexity that you may benefit from, when scaling and cost-per-user are considered.
If your app grows enough to require this scaling, you'll find this actually simplifies things greatly--clients in the same chat groups can map to the same server, and a load balancer can distribute RESTful calls appropriately.
If you are looking for one communication protocol to serve both needs (calling the server from the client, as well as pushing data from the server), you might have a look at WAMP.
WAMP is an open WebSocket subprotocol that provides two application
messaging patterns in one unified protocol: Remote Procedure Calls +
Publish & Subscribe.
If you want to dig a little deeper, this describes the why, the motivation and the design. WAMP has multiple implementations in different languages.
Now, if you want to stick to REST, then you cannot integrate push at the protocol level (since REST simply does not have that), but only at "framework level". You need a 2nd protocol. The options are:
WebSocket
Server Sent Events (SSE)
HTTP Long-Poll
SSE in a way could be a good complement to REST. However, it's unsupported on IE (not even IE11), and it's unclear if it ever will be.
WebSocket obviously works, but then why not have it all running over WebSocket? (This line of thinking leads to WAMP).
So IMO the natural complement for REST would be some HTTP Long-poll based mechanism for simulating push. You can make HTTP Long-poll work robustly. You'll have to live with the inefficiencies and limitations of HTTP (for use cases like this) with this solution then.
You could use a hosted real-time messaging (and even storage) service and integrate it into your frontend apps (web and mobile). These services leverage the websocket protocol and normally include HTTP Comet fallbacks.
The cool thing is that you don't need to manage the underlying infrastructure in terms of high-availability and unlimited scalability and focus only on developing a great app.
I work for Realtime so i'm a bit biased but I think the Realtime Framework could help you. More at http://framework.realtime.co
I have been tasked to develop a mobile chat app that will run both on Android and iPhone devices. I will be developing the respective clients in their native languages. Where I am a bit confused is in the development of the server.
My intended approach is to use 'long polling' to retrieve messages from the server and a separate connection to send messages to the server using GET/POST (obviously, there is no need for this to be long polled). My initial intention was to use Apache & PHP?MySQL for the server, but after a bit of reading, I learnt Apache won't be able to survive when there are lots of concurrent connections. I also learnt Node.js can survive where Apache failed by its capabilities to handle a lot of concurrent connections. Though, I don't have any knowledge about Node.js but if it will work, I am willing to do a crash course on it.
I know 'long polling' isn't the best method, but I can't seem to understand how XMPP can work for me on this project.
Thanks a lot in advance.
XMPP is the best way. You can install openfire on server side and for android you can use asmack. For Ios you can use xmpp lib.These are best combination. Communication with server is done through ssl connection.
I have built a little system that uses dnode, shoe and browserify on the client, and NodeJS and dnode/shoe on the server end. I'm wondering if it is a good idea to use dnode (RPC) as the sole protocol for a real-time web application.
Let's look at the benefits of DNode or any other RPC interface. I like being able to call functions remotely (RPC). It definitely beats Ajax because you get a consistent interface for communicating from the client to the server and server to the client. I'm also betting that you get a small measure of performance over Ajax because of the HTTP overhead involved with Ajax.
However, using RPC, you have to deal with load balancing and the client connections on the server. But this goes with any websocket implementation. But, with other websocket implementation, you have a more traditional event based system, where the client listens to events from the server and responds to those events. I tried replicating this sort of interface using EventEmitters, but it's awful, and I keep getting warnings about too many handlers. Ugh!
I'm looking to achieve a lightweight, clean, interface that I can use to develop my application with. One that feels robust and is able to scale to many clients. It needs to feel solid.
I'm not really sure what my question is in writing this post. I'm tasked to update this codebase I wrote so that connections aren't lost, and it's overall more robust. I guess I'm just desperate for advice or consulting with my application. Is there someone so willing as to go face-to-face with me on discussing this topic (RPC and real-time web applications)?
Thanks for reading.
I have been investigating some of the same topics as it seemed to me than some of the RPC libs were very cool, but not altogether practical for large scale apps. I actually started with NowJS, realized it was a dead project, moved to DNode/Shoe/Browserify, and finally have moved on to SocketStream in an attempt to offload some of the dirty work to a project that has a unified goal. I really didn't want rewrite what others had already done on this subject and socketstream makes that easy. To get back to your question, as you can see on their page, SocketStream uses sticky sessions. This is a big assumption but one that probably can't be worked around at the moment without further developments. The reason I mention it is that they talk about some of the things they are working on as far as scaling goes. Might we worth a read or reaching out to the developer to see if you could talk things over with him. Good luck!
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.