Currently, am working on client(web client) server application, am using xmpp framework to send and receive messages, xmpp is async communication, i have read articles on the internet, to create Asynchronous scalable web applications with real-time persistent long-running connections with SignalR is the best way. I want to know that can i use SignalR and Xmpp simultaneously?
Related
I want to to use Pidgin as a instant messaging client. Then I want to make peer-to-peer connection using XMPP protocol. I do not want to use a solution including a server.
I have try and inspect those things below:
XMPP protocol says it is a decentralized solution for im and it needs 'servers',
Official XMPP web site also states that there is an extention for serverless messaging, but i do not get it and how to implement it in pidgin?
The official XMPP states there is something called Jingle, and through jingle anyone can send media/files peer-to-peer. But if I didn't understand wrong as a client I still connected to a server?,
11 years ago this question had been asked:Is XMPP peer to peer connection without server possible? Unfortunately who asked the question was looking for something like WebRTC. Check the answers. This is not what i am looking for.
Also there's 'ejabberd'. If you use ejabberd you still make connection to ejabberd daemon and you are not instant messaging peer-to-peer. Host Unknown - XMPP Pidgin
So my question is simple: By using "pidgin" as a client and "xmpp" as protocol; is it possible to make peer-to-peer instant messaging? And if it is possible, how can I make it?
Thank you.
I have an iphone app with rails serving as a backend server.
Now I need to implement a chat functionality using sockets connections.
A lot of examples show you how to implement chat using sockets in browser.
What I need here is how I can implement an application where you create socket server in the rails app , and the client in iphone app which listens to the channel I give them.
I tried using faye(examples given only how to implement client in the browser) and using fayeObjC library for iphone to create client, but am not able to listen to the channel from this library.I know I must be implementing it wrong here.
I'll share my code also here, but first I need to know is there a better solution than this?
Also I appreciate some links to some examples where socket server is in rails and clients are iphone app.
Appreciate any help and mostly need a right direction to implement it.
Update
I tried the faye combination again and it worked.Although still looking for more solutions.
You can check about TCP sockets:
http://www.raywenderlich.com/3932/how-to-create-a-socket-based-iphone-app-and-server
Chat Application Using Ruby
http://quickblox.com/modules/chat/
http://caydenliew.com/2011/11/ios-mac-os-communication-with-asyncsocket/
http://www.macresearch.org/cocoa-scientists-part-xxix-message
Next link is a comprehensive Networking Guide - Using Internet Sockets
You must keep in mind two major problems to peer-to-peer communications (Chat): reachability and how to receive new messages while your application is in the background (get notifications).
For the last you can use APNS approach: an invisible notification will be pushed to the iPhone indicating that a new message is ready to be read. So your app will make a request for unread messages (what app like WhatsApp does).
Besides TCP sockets you could use websockets (HTTP - so there are no firewall problems).
Best in class - Socket.IO.
Here you will find the wiki https://github.com/learnboost/socket.io/wiki (you will find there an extension for Ruby also)
Here an example for iOS chat client for socket.io & node.js backend
Jabber
Another option: XMPP - "stands for eXtensible Messaging and Presence Protocol. Such a protocol is open-standard and oriented to message exchange (builds and maintains by Jabber community). Message exchange happens near real time, so it is an ideal infrastructure to build chat-like applications. The protocol also implements a mechanism to notify presence information (whether a user is online or not) and the maintenance of a contact list. XMPP is a thorough protocol, which has been adopted also by big companies like Google to build their Instant Messaging service."
Here you will find all about developing a Jabber Client for iOS (enable users to sign in, add buddies, and send messages; how to install and configure a jabber server, create accounts, and interact with the server from an iOS application http://mobile.tutsplus.com/tutorials/iphone/building-a-jabber-client-for-ios-server-setup/
I know that SocketRocket by square is a strong native Objective-C library. But it doesn't offer the channel abstraction you seem to be looking for.
If you would consider outsourcing the WebSocket connections then you could use a hosted service like Pusher, who I work for. You can publish messages (trigger events) on channels using the pusher-gem. And you can subscribe to channels and receive messages using one of Pusher's Objective-C libraries.
Other solutions will also have Objective-C libraries and you can find a list of them via this realtime web tech guide.
I have an idea of an application that involves a "chat feature", basically an ability for people to chat with each other. Since sending messages through a server would be slow (plus it would be pretty bad having to check the server every second if you have new messages) I want to use sockets to have peer to peer chat ability instead of going through a server.
My 2 questions:
1) Is socket programming the most optimal way to develop a chat program? I know there is push notification service, but I don't think it can be used for a chat program too well. Going through a server seems kind of bad if you imagine 5,000 people chatting and having to poll the server every second.
2) Will Apple have issues approving an app that has peer to peer chat program that uses sockets?
Thank you.
Sockets are indeed appropriate. But you are better off with a client/server approach rather than a P2P approach.
Having worked on a very well known instant messaging service for many years, I can tell you absolutely that going through a server is not slow - as long as your server is not slow.
Client/server has lots of advantages. Namely, it's not as difficult as any sort of P2P connectivity where such issues as NATs and Firewalls make direct socket connections difficult and unreliable. Besides, you would need a messaging service anyway for clients to exchange IP addresses.
Your stated assumption that a client or server would have to "poll" is not how scalable systems work. You should use a persistent TCP socket and look at scaling a socket service up though any of the available async methods that exist today. select(), poll(), epoll on Linux, and IO Completion Ports on Windows are all techniques for having thousands of sockets simultaneously connected without periodic polling.
My suggestion - just deploy an XMPP/Jabber server. Most implementations scale up nicely to the thousands of clients. Then your chat program is just an XMPP client socket. Some of the Jabber servers even support HTTP connectivity for situations where a user's only access is via an http or http proxy server. I played around with Openfire a while back and was reasonably impresseed.
I'm fairly certain that iOS has sockets, and that it's allowed by Apple. I only know via second hand from folks that have worked on iOS products. You probably shouldn't use the push notification service for anything more than notifications to wake up your app that there is something it needs to do.
Hope this helps.
Is there a framework that supports publishing (pushing) messages from a WCF service (REST or SOAP) to various clients like IPhone, Android and WP7? I'm thinking I can use the WSDualHttpBinding to do dual communication between WCF and WP7. However, I'm assuming WSDualHttpBinding is not supported in the other two platforms since is not a WS-* standard and there's a lot of stuff that WCF does to establish a receiving channel on the client side. Is there any other way to accomplish this? How would I about rolling my own?
I'm thinking about exposing my WCF service as a restful endpoint and implement a COMET style pub/sub and calling it good.
I'm stuck. Any help would be greatly appreciated.
Since you already have a solution for WP7, you could probably use urbanairship.com to handle the pushes for iPhone and Android. I've used them on a prior project with good results. (I don't work for them.)
I found this "Cloud to Device Messaging", C2DM, yesterday and thought it may serve your question:
http://www.makeurownrules.com/archives/category/android
Have you considered using SignalR? It'll fallback gracefully from WebSockets & Server-Side Events through to long polling. There's a mono implementation of the client-side library.
We're successfully using it in a large-scale realtime application and it works a treat. A bit further down this page it details how to communicate with clients from outside the SignalR infrastructure which may be useful if you want to talk to clients from your WCF service.
Cheers,
Dean
I'm currently writing a simple cross platform app with Node.js on the server and web/iPhone/Blackberry clients. Bandwidth and latency requirements are similar to something you would see in an IRC "party game" or any chat system. I've developed the web client using HTTP long polling (speaking JSON both ways).
For iPhone/blackberry I could use the built in HTTP libraries to talk to my current implementation, or I could write a socket listener on the server and talk to it using sockets. Is there any advantage to doing so? Why do non-browser HTTP clients seem to be discouraged?
Can't speak to iPhone as I don't know enough about the technical details of the network stack, but for BlackBerry HTTP requests from the browser are treated differently from app-initiated requests in general. BlackBerry as a solution consists not just of a device-side TCP/HTTP stack, but the BlackBerry service, which includes (depending on if you're enterprise or not) a BlackBerry Enterprise Server with Mobile Data Services (BES/MDS) hosted on your enterprise network, or a Research In Motion hosted BlackBerry Internet Services (BIS) server, which proxy all connections from the mobile browser. These servers can do a lot of things, including handling some aspects of cookies, authentication, and content transcoding to make content more consumable by the mobile device (images and the like). For a BES/MDS they can even act as the secure endpoint in an HTTPS connection.
Anyway, this also means that a lot of the functionality you'd expect from a normal TCP/HTTP connection actually happens off the device, and so can be controlled by a carrier or enterprise or RIM. Bare-bones sockets are different because the various servers in the middle can't make as many assumptions about a TCP socket as they can about an HTTP connection, so they can't mess around with your HTTP requests. A lot of BlackBerry apps actually end up writing their own HTTP client on top of the socket layer for that very reason, so if you have to do something like an HTTP long poll (Comet?) definitely write it on top of the socket connection, not the built-in HTTP connection.