I have VPS hosting for a business application. It has XMPP based chat with Openfire which is working fine.
I want a real time notification system as well in our system.
I have these options
Ajax Long Poll
PHP websockets
Node.js
Using XMPP(Not sure if applicable)
Among all the above. Which one would be the quickest one?
XMPP over websocket would be a good fit as it simply builds on your existing infrastructure.
Related
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 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 am going to build a web application to manage notes (think of something similar to Evernote). I have decided to use Backbone.js+JQuery client side.
Server-side, I haven't decided yet: either pure PHP (that I know very well) or Node.js+Socket.io (completely new to me).
I am considering Node.js+Socket.io because I would like to have my web application being real-time (i.e: if a user updates a note, that note gets updated instantly for a collaborator who shares that note, without reloading the page).
I was also considering, as a third alternative, to use Node.js and Socket.io for the UI and PHP for the REST API (I feel more comfortable to build an API with PHP). The PHP and Javascript code will share the MongoDB database.
My question is this: if I develop the REST API for my web application with PHP and a new note for the user gets created through the API (i.e.: the Android app sends an API request to create that note), will Node.js, Socket.it and Backbone.js be able to instantly update the UI of the user and show the new note on their screen? I think that can be called "push notification".
I hope I was clear enough.
Also, is there any alternative outstanding technology to build real time web applications?
Yes Node.js + Socket.IO will do a very good job of this. Node uses an event-loop, this means upon a request it is entered into a queue. Node deals with these requests one-by-one. Traditional web servers deal with a 'Thread-per-request' approach where a thread is created to handle that requests.
The benefit of Node here is that it doesn't need to context switch so often, this means it can deal with these requests very quickly... most likely faster than your PHP server. However Node runs as a single process, on a single CPU core. If your application is CPU intensive it could be that it blocks, meaning the time for each requests will be slower.
However it sounds to me like your application isn't CPU intensive, meaning Node.js will work well.
Decision
If your time is limited, and you don't want to learn a new skill (Node), PHP will be fine. If you have the time I recommend learning Node.js, as it is very strong when it comes to I/O intensive tasks such as a REST API for creating Notes.
Updating the UI
If your intended use is through a mobile device, I recommend using WebSockets but having a fallback such as long-polling. It is possible to update the Client UI using either Node or PHP. However from my experience it is much easier to do so using Socket.IO on Node.js.
Example Updating the client using Node.js / Socket.io
Client-side
socket.on('new-note', function (data) {
placeNewNote(data);
});
Server-side
socket.emit('new-note', data);
Getting Started With Node:
How do I get started with Node.js
Please also note, if you want to build a native Android mobile app which uses WebSockets... you will need to use: Java socket.io client
Using Node.js for both web server and push server is of course the best way. Especially since if you are going to use Node.js anyway then you have to learn it, so learning how to make a web server is only natural (I advice using the most famous Express framework).
Now you can use PHP for web server and Node.js for push server. To make them communicate with each other you would probably want to add Redis to your application. Redis will allow you to push notifications to any client connected to it, like PHP server or Node.js push server (and it scales well). From that point push server will push the data further to the client's browser.
Alternative technology would be for example Twisted server. Of course you'll need to learn Python in order to use it. And I don't know whether it supports WebSockets correctly. I think you should stick with Node.js + socket.io.
For a notification project, would like to push event notifications out. These are things like login, change in profile, etc., and to be displayed to the appropriate client. I would like to discuss some ideas on putting it together, and get some advice on the best approach.
I noticed here that changes made to a CouchDB can be detected with a _changes stream, picked up by Node, and a process kicks off. I would like to implement something like this (I'm using SQL Server, but an entry point at this level may not be the best solution).
Instead of following the CouchDB example (detecting database-based events, I think this just complicates things, since we're interested in client events), I was thinking that when an event occurs, such as a user login, then a message is sent to the Node server with some event details (RESTful request?). This message is then processed and broadcast to all connected clients; the appropriate client displays notification.
Proposed ecosystem:
.Net 4.0
IIS
IISNode
Socket.IO
Node.JS
SQL Server 2008
This will be built on top of an existing project using the .Net framework (IIS, etc.). Many of the clients' browsers do not support web sockets, so using Socket.IO is a good option (fallback support). However, from what I can see, Socket.IO only still only supports long polling through IISNode (which isn't really a problem).
An option would be to expose the Socket.IO/Node endpoint to all clients, so that client-based notifications can be sent through JS to the Node server, which broadcasts the message. (follows the basic chat-server /client/server examples).
Alternately, an IIS endpoint could be used, but could only support long polling (through Socket.IO). This would offer some additional .Net back-end processing, but may be over-complicating the architecture.
Is there SQL Server-based event notification available for Node?
What would be the best approach?
If I didn't get the terminology ecosystem configuration right, please clarify.
Thanks.
I would recommend you check out SignalR first before considering adding iisnode/node.js to the mix of technologies of your pre-existing ASP.NET application.
Regarding websockets, regardless if you use ASP.NET or node.js (socket.io), you can only use HTTP long polling for low latency notifications, as websockets are not supported by HTTP.SYS/IIS until Windows 8. iisnode does not currently support websockets (even on Windows 8), but such support could be added later.
I did some research lately regarding MSSQL access from node.js. There are a few OSS projects out there, some of them use native, platform-specific extensions, some attempt implementing TDS protocol purely in JavaScript. I am not aware of any that would enable you to access the SQL Notifications functionality. However, the MSSQL team itself is investing in a first class MSSQL driver for node.js, so this is something to keep an eye on going forward (https://github.com/tjanczuk/iisnode/issues/139).
If you plan to use SQL Notifications to support low latency notifications, I would strongly recommend starting with performance benchmarks that simulate the desired level of traffic at the SQL server level. SQL Notifications were meant primarily as a mechanism to help maintain in memory cache consistent with the content of the database, so it may or may not meet the requirements of your notification scenario. At the very minimum these measurements would help you start with a better design.
I would highly recommend using Pusher. That is what we use and it makes it easy to implement as it is a hosted solution. So plugging it and making it work is really easy. It doesn't cost much unless you are going to push a crazy amount of messages through it on a massive scale.