I want to build a instant messaging application using Ruby on Rails but I'm confused about the implementation.
How is a IM application (like the one on Facebook) usually implemented? I think we can use a push server (server pushes to client) or polling (client asks the server), but is there any other ways? And what are the corresponding advantages of these two approaches? Which one is usually more efficient and less demanding?
Thanks in advance.
Polling: In case of Polling, browser makes the request to server at a regular interval to check for updates. It will increase your server load.
Server Sent Events: server sent events.
Server-Sent Events have been designed from the ground up to be efficient. When communicating using SSEs, a server can push data to your app whenever it wants, without the need to make an initial request.
WebSockets: WebSockets on the other hand, require full-duplex connections and new Web Socket servers to handle the protocol.
For IM best suited is websocket, as using websocket you can do bi-directional communication.
A similar example of IM using websocket is Applozic chat SDK. It Uses web sockets for Real Time Messaging.
I don't know specifically how Facebook implements their IM service, but most web-based IM clients use either a push server or a Jabber client. Jabber is good if you want the users to be able to communicate with the service through their own IM client, and not just through the web frontend; push is good if you're doing something interesting with the received messages on the server-side. Polling isn't used anywhere near as widely nowadays. It requires the same JavaScript support as server push, but is much more resource-intensive for your server.
For getting started with push, I would recommend looking into Faye or Juggernaut.
If you're interested in Jabber options, check out the JavaScript Jabber Client Library.
Related
A web application acts as a backend to process request coming from the iPhone. To send messages to iPhone from web application while processing a request(e.g., for payment), I want to send messages to iPhone when something interesting happens on the server or else if everything is successful, sending them transaction details. Which one is better to use PushSharp or SignalR? Does they both serve the same purpose? Either way, enlighten me on this topic. Its confusing to me.
SignalR is a great way to send real time information to a web client, essentially having server-side code push information to the client and call client-side code (i.e. javascript) in realtime.
PushSharp is a great way to send push notifications to native mobile apps. For iOS, this means using Apple's infrastructure. It also means that the message will be shown as a notification in the iPhone and not just inside the browser.
Essentially, if the iPhone request you mention is coming from a native app, try PushSharp. If it's a web app running in a browser, use SignalR.
PushSharp appears to leverage the native messaging for each platform. Azure Notification Hubs provide native messaging similar to what PushSharp appears to do. The native messaging platforms scale out very well, but do not give you direct access between client/server code, and messages can be delayed in some cases up to minutes. Messaging like this works really well when you want to send messages to millions of devices. Example: all users who want an alert when their favorite sports team wins a game - not time sensitive to the minute.
If you want your push message to be strictly between your server-side code and your client-side code, SignalR can achieve that. SignalR also has a .Net implementation, so it isn't just for javascript/web pages. SignalR is will leverage approaches like web sockets / long polling / etc. If you are sending a response to tell your client that a query has finished, or that a message was received, and it doesn't help to have that message arrive minutes later... SignalR may be a better approach.
I just wonder why and for what kind of application or case we need the Socket.IO.
I am the iOS developer of a known open source project socket.IO-objc
Usually, we need HTTP or HTTPS to communicate with server. The socket aims to conduct real time communication (It should always keep a live HTTP connection.)
Libraries like socket.IO are needed when we need real-time in our app. Let me explain this in little more detail. Let's assume that you are developing a game, which is multiplayer and 2 or more users can play that simultaneously. Then, in that case, you won't be making HTTP or HTTPS calls because of many reasons and one of them is that their packet size is large and other is that these calls are very slow. In such scenarios we use libraries like sockets to send and receive data to and from the server. Sockets are really fast and are capable of sending only those data packets which are needed. Using HTTP programming you can never create any multiplayer game or any app which will be interacting with a server on a realtime basis.
Let's take another example. Let's assume that you are working on a chat application. When user A is typing something then user B should know that A is typing (similar to gtalk of facebook messenger). If you will use HTTP calls at that point of time then "B" will never be able to see the actual status of the other person because of the delay. So what we can use is sockets so that when user A is typing anything then his device will send only one data packet which will just notify the server that he is typing and will be delivered to user B, this process is really fast (almost realtime) and will reduce the data transfer also.
I'm working on chat application using socket.io also. So it seems to replacing everythings with socket.io. This is making me in doubt and curiousness. I totally agree with real-time app like chat suits for socket.io. However there is round-trip communication (such as user login) that's more suitable for HTTP.
Socket.io uses web socket to pass data among users who are all connected to a web server. With web socket, there is no negotiation protocols and connection remain open as long as users concerned are registering for service with the web server. As pointed out also, the payload is significantly less than http/https protocol.
Socket.IO is a JavaScript library for realtime web applications. It enables realtime, bi-directional communication between web clients and server. It has two parts: a client-side library that runs in the browser, and a server-side library for node.js. Both components have a nearly identical API.
Heroku does not provide (yet) Websockets and rely on long-polling instead (see here).
So I was surprized to see there is an addon for Pusher which is a Websockets real-time messaging service (for real time apps)
How is it possible? Is Pusher on Heroku stack really using Websockets or do they actually provide only long-polling on Heroku?
I might be missing something here...
Pusher is a 3rd party app. They have their own infrastructure and can do websockets. They are just a service that heroku customers can use. They are not running "on" heroku.
Mitch is telling you correctly. I'm currently in the process of building an app on the Heroku network that utilizes Pusher. It's not hosted on your Heroku services. The websockets that are opened are between Pusher's servers and your clients. You send Pusher the information you want disseminated to the clients listening on whatever channel you specify. Your Heroku server and Pusher don't need an open connection to each other. Since you're telling Pusher what information you want to send, to the connections it has opened on it's servers. It may not be the cheapest option in the log run. But for fast prototyping, or just not wanting to deal with your own instant data transfer solution, Pusher does work well.
I am a Ruby on Rails developer and I have a question about iOS development.
How do iPhone applications typically interact with a server?
For example, let's say you wish to send GPS coords from the iPhone to the server to be stored or processed. How is that typically done? Is it through a typical server API (like JSON)?
Sorry for such a basic question.
EDIT: Thanks for the answers below. Now, how about pushing data from the server to the iPhone app (without a request). How is that done?
The communication format is usually XML or JSON via HTTP call, but it depends on your data you wish to communicate between server and app. You may use socket connection.
Typically, every client and server exchange information via public API's.
in iOS, we prefer, RESTful webservices that deliver JSON. (There are other options also, but we prefer this)
I'd say that the best way to ensure delivery of data to the app from the server depends on whether you know the app is running or not. Push notification can deliver payload data, albeit in small quantities, to the app and it does not matter whether it's currently running or not. It's a big subject but thats a good start.
I developed a Blackberry Native application and now the client want notifications even when the device is turned-off. After a few searching, Blackberry Push Service seems the way to go, but i have some concerns:
Blackberry Push Service is a free or paid service?
What are the library requirements on the client side? Do I need additional libraries or it only work with Blackberry SDK?
How are the notifications sent? Do I need to build an additional application for that? The client has IIS servers, so I wanna know if it is possible to build such an application in .NET.
Have any one tried Urban Airship? Seems like a simpler way to accomplish the task.
RIM charges for Push services based on how much data you are pushing through their servers, and for delivery confirmation. If your customer base is small, and the push data requirements are modest they won't charge anything.
When you register to start a push service they will send you sample code but there are no additional library requirements.
Push notifications are XML documents that are POSTed to a RIM 'web' server. There are a number of services you must provide to the client for registration and push control. The standard way of doing this is again with a 'web' server that RIM and the client device communicate with. When you register RIM will send you a sample server module designed to run in Apache TomCat, but I (and others) have replicated the necessary capability on Linux, Apache, MySQL, and PHP servers (LAMPS). I don't see any reason you could not implement this on IIS but I have no experience with IIS. (I put 'web' in quotes because this server may, but does not have to, serve any web pages in the traditional sense. The push service uses HTTPS as the transport protocol.)
I don't even know what that is.
If your client is running a BES then they already have everything they need to push to the client and get delivery confirmation without any additional cost. JP Mens published a very good article on using the BES MDS server to push data to clients from a LAMPS machine.