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.
Related
I'm working on real-time multiplayer game in Android (java) and I narrowed down the my choices for bidirectional connection to WebSocket and Socket programming
My requirements are:
Fast Reaction Time
High-Frequency send and receive with Small Payloads
Stable connection
Secure Connection
Image and audio transfer
In app chats
Base on these requirements, I would like to know which is more suitable.
Thanks.
A WebSocket is a regular TCP socket connection that:
Mainly, it is supported in web browsers, so they can be used from Javascript.
Starts as a HTTP connection, allowing it to easily cross proxies and firewalls, and make use of HTTP mechanisms like cookies and the Origin HTTP header among others. So for example, a Websocket connection will send the cookies that the browser has for that domain.
Uses its own data framing protocol.
Uses its own PING/PONG schema.
If you do not need any of those, you may be alright with just a socket.
I'm developing an application for Windows Mobile 6.5 that needs to get and send data from a Postgres database within the network of the app.
I've googled it and read every page on the matter but haven't been able to find a solution.
The npgsql driver doesn't work on this sdk.
Much like for Android or iOS, I'd recommend that you build an intermediary web service that's provided by a server on the Internet that the phones talk to instead of talking directly to the database. The web service would accept REST+JSON, REST+XML, XML-RPC, SOAP, or whatever your preferred web service procotol is from the phone clients. It'd act on the requests from the phones, doing whatever is needed in the database to satisfy the request, and return any result via the web service protocol.
This means your individual phones don't need connections direct to PostgreSQL - a good thing, since phone network connections are flakey and the retry/re-establish logic can be hard to get right. You'd land up with lots of dangling connections to the Pg server. You're much better off with a stateless protocol like HTTP to talk to a web service that then does the real work.
Choose whatever web service protocol is easiest to work with on Windows Phone 6.5 and implement it using your preferred back-end server. In your case I imagine that's likely to be .NET on IIS.
Depending on the app, you might already have a web service protocol. If you have a modern web page version then it's fairly likely to use JavaScript with REST+JSON to call server endpoints, in which case you may just be able to extend and re-use those for the phone app.
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.
I am a new programmer who is new to iPhone development and server stuff. I have a lot of questions to ask.
You don't have to answer all the questions; any help is appreciated!
How does iPhone apps interact with server?
Is there a particular kind of server i should use to interact iphone app with server?
If there is no particular kind of server then what kind of server can be used?
What are their advantages and disadvantages?
What should the iPhone app (which is the client) do in order to interact with the server?
How does the server know which iPhone to send data to?
What should the server do in order to interact with iPhone app (client)?
Your best bet is to have your iPhone make web requests of a web server. Your iPhone app acts just like a web browser, making http requests to a web server, and parsing the response.
I'm building an app right now that hits PHP scripts I've written that do database work, etc, and return JSON objects. It's not fancy--I could have built a whole SOAP or RPC web service, but I didn't do that, it just makes GET requests with query-string arguments.
There are handy libraries you want to know about. Google "iPhone JSON" to find the JSON library written by Stig Brautaset, that's the one most people seem to be using. Also, rather than putting yourself through all the hoops that the iPhone's built-in web client framework requires, go get ASIHTTPRequest, a very powerful and MUCH simplified web client library.
As a general rule, you want to do as much processing on the server as possible. For instance, there's a place in my app I'm searching for events happening within a user-specified range of their local coordinates ("within 10 miles of me"). I wrote PHP to build a latitude/longitude bounding box, and query from the database based on that. That's WAY faster than bringing a bunch of events down and then asking Core Location to calculate their distance from where I'm standing.
You've asked quite a few questions so I'll try my best to answer them all:
First, you need to be a bit clearer, what type of server are you talking about? Email server, web server, lolcat server, it depends.
At the basic level, the iphone communicates over the internet. The internet uses Internet Protocol, and there are two standard protocols built atop of IP: Transmission Control Protocol, and User Datagram Protocol. Each has it's own uses and functions.
TCP/IP and UDP/IP make up the backbone of internet communication.
A more specific application protocol is built atop of these two internet protocols, with a specific format to a given application. For example, HTTP is the standard protocol for transferring HTML and other Web information between a web server to a web browser client, over TCP.
So, your iPhone would use whatever protocol is required to commuincate with the server. For more common server communication, the iOS SDK provides methods to construct messages (for example if you wish to make an HTTP request to a web server, you can use initWithContentsOfURL to send a GET request).
If you built a custom server, then you will need construct the required message protocol on the iphone, and send it to the server, using either TCP or UDP (whatever your custom server expects).
How do apps like Apple's "Remote" app control mac applications and send data?
is this via php with exec() commands or some other method? and how would I do it in c?
Also, how fast is this rate of transfer (can I use it to send real-time data like streaming video or audio?)
thanks to anyone who cares to enlighten me on this issue :-)
Apps generally communicate using a TCP/IP based protocol and the wireless LAN connection (the iPhone also has Bluetooth). In the case of the Remote app the communication is via with the Digital Audio Control Protocol. iTunes implements DACP so the Remote app can control it. Other common protocols are HTTP and FTP. There are classes in the iPhone SDK to connect to noth HTTP and FTP servers. There is also the Cocoa HTTP Server project which allows the iPhone to act as a HTTP server.
iPhone apps can also use Bonjour/mDNS/zeroconfig (they're different names for the same technology) so that the user doesn't have to be concerned with configuring IP address'.
The data transfer rate of the wireless connection is faster enough to stream video.
many of these remote applications work by installing client software on the computer and establishing a network connection. In the case of Apple's remote software, the client software is built into the networking capabilities of iTunes. You must authenticate using your iTunes sign in and be on local wifi.
The third party app "intelliremote" works very similarly only has it's own client software to install and can work across a WAN with proper port forwarding enabled on your network.
I haven't encountered any realtime streaming options as most of these utilities are designed to pass control messages and meta-info on media files.