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.
Related
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 am implementing an iPhone/iPad app that allows users to send each other messages using the bonjour protocol. Basically, a server publishes his service over bonjour and the clients connected to the same wifi can discover his service and connect to it to start sending messages. The problem I've found is that some routers seem to have problems with Bonjour. When running my app at home or at some other places it works perfectly. The publishing and discovering of the bonjour services works flawlessly. However when I tried my app at one of my friend's apartments, some (not all) of the clients were not able to discover the published bonjour service. I also noticed that other apps that use Bonjour (such as Apple's Remote app) were also having trouble on said network. After doing some digging I've found that other people have had similar problems with bonjour and some routers. Therefore I have 2 questions:
1) Does anyone know if this problem with Bonjour that some routers seem to have is a widespread issue? In other words, if my app relies on Bonjour in order to function at all, do I have to be worried that it won't work in 50% of the WLAN networks or do most routers not have any issues with bonjour. Obviously I can't expect anyone to know how every router out there deals with bonjour packets but maybe there are some Networking gurus that can point me in the right direction :-p.
2) Second, if bonjour is too risky of a protocol to build my app on, what are some alternatives with similar features? The features I would (preferably) need would be service publishing and discovery without users having to manually enter IP addresses of other phones.
Ok thanks for your help! I understand that this is kind of a broad question but any help is appreciated! :)
This is potentially a tough nut to crack. The problem causing devices not to find each other on certain networks is related to the underlying transport (i.e. multicast UDP) and not Bonjour (or mDNS or whatever else you wanna call it).
In high-level, non-rigorous terms, multicast data puts more load on routers. Large corporate and university networks sometimes like to drop Bonjour messages (i.e. UDP packets sent to the multicast group 224.0.0.251 on port 5353) because it means the network isn't inundated with thousands of clients advertising their iTunes libraries or whatever, and at scale this can improve general performance. At the other end of the spectrum, some domestic routers drop multicast packets out of the box for reasons known only to the manufacturer. There's not a whole lot you can do about either situation.
Try running a tcpdump on the network to see if the packets are actually coming through. I've not come across a home router that doesn't forward them for a while. If they're not, you'll have to come up with some central [internet-facing, perhaps?] lookup facility. If they're visible, then there's something up with your implementation.
There's nothing stopping you from writing your own simpler protocol for service discovery to be sent over multicast- it's just that there are loads of Bonjour clients in a ton of different languages already written and tested.
From my understanding you cannot socket a connection between two iPhones (correct me if I'm wrong). So what I would like to do is have one server sitting between the client application that accepts messages and redistributes them to the appropriate person(s). Essentially the application is going to allow people to have a shared map that has their locations and everyone can annotate it.
1) I have been reading and researching into the CFStream class, but I'm curious to know if it might be better to just use the C send() and recv() functions. They almost seem much easier to use. What does CFStream offer over the native C socket functions that make it a better option?
2) Since I need the phone to actively listen for updated shared user locations/new annotations from other users, my plan was to periodically have the phone poll the server for any "news" from other users (say every minute or two). Is there anyway the phone could spin off a new thread in the application that is constantly waiting for incoming traffic? It would make life easier to be able to have a user annotate the map, push that to the server which then immediately updates the appropriate users maps.
I have been using example socket code from Jonathan Zdziarski's iPhone SDK book from O'Rielly Media to just try sending messages between a server and iPhone emulator (the classic knock knock joke server/client). However, after sending 1 or 2 messages the server gets stuck "receiving." The code runs perfectly when not sent from an emulator, as I can seemly spam the client send function and get a response from the server each time. Could the server be hanging because I use send() and recv() instead of the CFRead and Write stream?
You can socket iPhone applications using bonjour, or even GameKit (which is what I use because it manages all data for you).
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.
I'm working on a multiplayer iPhone application that allows up to 6 users to connect and play in "real time." I've been looking at hosted and non-hosted socket servers (SmartFox, ElectroServer, Photon/Neutron, ProjectDarkstar) and I'm wondering if anyone has any recommendations for services or implementation? Anyone have any idea of what a game like Zynga's Live Poker uses for this type of functionality or what kind of hardware you might need?
Some sub-questions:
The game is turn-based. Would it make more sense to use AMF and poll a server or should I go for the socket-based route? My current concern is concurrent connection limits and hosting costs.
Is it possible to "broadcast" a device as a socket server? i.e. once I get all my players connected, could I allocate one of the 6 devices to be a socket server and push all communication through that device? Would that be crazy? That would get around concurrency issues and I'd only need to rely on the socket server service as a lobby for the initial connection. The allocated user would stay connected to facilitate game to server communication.
1.
It's much easier to use polling, and since the game is turn based you could poll at a relatively slow rate (perhaps a couple of seconds), which means less battery drain. That said, using sockets or persistent HTTP connections would be a slicker way of doing it (and much more work). These two questions might be of interest:
How do I create a chat server that is not driven by polling?
COMET (server push to client) on iPhone
I don't know why you would use AMF. Why not JSON? Or maybe HessianKit?
2.
It makes a lot of sense to designate one of the devices as a server. Having a completely decentralized network of game clients that need to synchronize is a very hard task. Again, since your game is turn based, which doesn't require perfect real-time synchronization, you don't have to worry that having centralized state will introduce more latency.
If you intend for users to play over a local network, you should consider using GameKit.