iOS Best way to program server connection into iPhone app?

[dancks]

For the moment this is just conceptual and is a long way off, but I plan to make a fitness tracker app that can update my stats and food I eat as both a beginner iPhone app and also to dabble in server and networking programming. The server in question is an old emac at my house running debian. I had this plan of creating a client program on the server where it would use the pcap networking library to pick up and read packets with a certain port number, and execute login, store, retrieve commands based on what the packets contained, to be run as a daemon. I don't know of any Objective-C/cocoa networking functions so I was wondering if pcap is supported or would work on the iPhone? Is there another library to do this? I know its possible to make a library file in C, and make Objective-C wrappers to read it, but its difficult and not without flaws.

tl;dr: best way to programmatically connect to a server with app, keep secure conversation going, etc.

 

[robbieduncan]

Probably not in the way you have described! Do you really want to invent your own network protocol/message format? Or would it be simpler to use the common web services paradigm?

 

[AxiomaticRubric]

What you'll want to avoid is persistent server connections. There are too many things that can go wrong, especially on a handheld device with multiple connectivity methods.

As already mentioned, a simple web service is the way to go. You can get one up and running with a minimum of fuss, and you won't have to write a single line of C code for your app to interact with it. Your goal should be to write RESTful code in Objective-C, which is actually quite simple.

 

[dancks]

Probably not in the way you have described! Do you really want to invent your own network protocol/message format? Or would it be simpler to use the common web services paradigm?

What you'll want to avoid is persistent server connections. There are too many things that can go wrong, especially on a handheld device with multiple connectivity methods.

As already mentioned, a simple web service is the way to go. You can get one up and running with a minimum of fuss, and you won't have to write a single line of C code for your app to interact with it. Your goal should be to write RESTful code in Objective-C, which is actually quite simple.

I'm still researching. I'm not sure how I would implement a web service (protocol stack?)

I'm looking at this tutorial:

http://www.icodeblog.com/2008/11/03/iphone-programming-tutorial-intro-to-soap-web-services/

That seems nice. There's still the issue of how would I be able to send and receive specific data from the server? I was gonna use MySQL server, which does allow remote connections.

So, I write a php page that receives a GET or POST message, and send back certain data as per my request through port 80. If this information is sensitive, maybe I could encrypt with php script and write an Objective-c class to encrypt and decrypt messages. Thats not a terrible way to go. Is this what you had in mind?

Since this is a home server (and I absolutely refuse to use or rent server space from someone else) security is of the essence.

Persistent connections shouldn't be an issue I could do more research and write a server side script to analyze and close inactive connections.

I planned on having the connection close when the application is minimised.

 

[dejo]

So, I write a php page that receives a GET or POST message, and send back certain data as per my request through port 80. If this information is sensitive, maybe I could encrypt with php script

Why not use an https connection and serve the response through port 443? Then its already encrypted.

Anyways, I think you are thinking way too low-level and basically are reinventing the wheel here. Set up a web server. These issues have already been figured out and people have been using them for many years now.

 

[dancks]

Why not use an https connection and serve the response through port 443? Then its already encrypted.

Anyways, I think you are thinking way too low-level and basically are reinventing the wheel here. Set up a web server. These issues have already been figured out and people have been using them for many years now.

I know other people have done all this before, I just wasn't aware of how much was taken care of with cocoa. Or some other library I'm not aware of. Its basically java at this point.

 

[robbieduncan]

I know other people have done all this before, I just wasn't aware of how much was taken care of with cocoa. Or some other library I'm not aware of. Its basically java at this point.

Why will the server end by Cocoa? Java is just fine there

 

[dejo]

I know other people have done all this before, I just wasn't aware of how much was taken care of with cocoa. Or some other library I'm not aware of. Its basically java at this point.

Sorry, it just sounded to me like you were already crafting a low-level packet-communication solution, when installing a web server and building upon that would probably save you a lot of hassle.

 

[Duncan C]

Sorry, it just sounded to me like you were already crafting a low-level packet-communication solution, when installing a web server and building upon that would probably save you a lot of hassle.

I agree with dejo. It does sound like you were planning to re-invent the wheel.

Creating a scalable server architecture is hard work, and there are lots of gotchas. Greater minds than ours have spent many, many person-years on the problem, and come up with good, reproducible solutions. Don't try to invent your own server architecture.

 

[dancks]

I agree with dejo. It does sound like you were planning to re-invent the wheel.

Creating a scalable server architecture is hard work, and there are lots of gotchas. Greater minds than ours have spent many, many person-years on the problem, and come up with good, reproducible solutions. Don't try to invent your own server architecture.

To a certain extent I was, however I thought I could get away with a server daemon that simply screened packets and responded with requested info. It seemed simple on paper. It would be written in C and interacted with a MySQL database so that would be taken care of. Linux takes care of providing me with high level networking API so again, some learning but not terrible. The only real hard part would be how do I get it running 24/7, prevent buffer overflows and
... the iPhone would've been hard. Its already pretty difficult. The part I can't figure out is how do I use a service already provided on the server and send information back and forth? At that point I feel like I'm almost creating a website.

I'll just use Apache, port 443 and send POST data with PHP back to the iPhone. should be fun.

 

[chown33]

To a certain extent I was, however I thought I could get away with a server daemon that simply screened packets and responded with requested info. It seemed simple on paper. It would be written in C and interacted with a MySQL database so that would be taken care of. Linux takes care of providing me with high level networking API so again, some learning but not terrible. The only real hard part would be how do I get it running 24/7, prevent buffer overflows and
... the iPhone would've been hard. Its already pretty difficult. The part I can't figure out is how do I use a service already provided on the server and send information back and forth? At that point I feel like I'm almost creating a website.

I'll just use Apache, port 443 and send POST data with PHP back to the iPhone. should be fun.

If the server is is running HTTPS, or even just HTTP, then the URL Loading classes are the ones to use. These provide a high-level view of network connections, based on URLs, requests, and responses.

There are lower-level classes, as well as lower-level C functions (such as socket(), read(), write() in the Posix functions (e.g. see 'man socket')), none of which you will need to use directly.

The reason it feels like you're creating a website is because you are. An HTTP server is an HTTP server, whether the content represents a website or a web app.

In a web app, HTTP is being used as the transport protocol in a REST design. You should be looking at it from the higher level of requests and responses, not the lowest level of connectionless packets and packet-filtering, unless you want to reinvent the entire NSURL** class library, and all the low-level TCP-IP socket() stuff as well.

 

[Duncan C]

To a certain extent I was, however I thought I could get away with a server daemon that simply screened packets and responded with requested info. It seemed simple on paper. It would be written in C and interacted with a MySQL database so that would be taken care of. Linux takes care of providing me with high level networking API so again, some learning but not terrible. The only real hard part would be how do I get it running 24/7, prevent buffer overflows and
... the iPhone would've been hard. Its already pretty difficult. The part I can't figure out is how do I use a service already provided on the server and send information back and forth? At that point I feel like I'm almost creating a website.

I'll just use Apache, port 443 and send POST data with PHP back to the iPhone. should be fun.

If you're comfortable writing socket code then what you describe isn't that hard, FOR A SINGLE USER. However, creating a scalable host architecture IS hard. VERY hard. If your app is successful and you have hundreds of simultaneous connections, your host will likely choke and die. Re-architect for hundreds, and after some multiplier on your connections, your server will choke again. And again.