The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Mobile Device Addressing

Hey, all -

Does anyone know or have any thoughts on how I should go about getting the IP address (or equivalent) of a mobile device? I'm starting work on a project that will require two mobile devices to pass messages back and forth in a session, but both need to know about each other for this to happen. This seems like a problem that should have an extant solution, but I'm unaware of one. It would be ideal if something like a mobile DNS existed, wherein you could get an IP address given a cell number, but to the best of my knowledge that does not exist.

Anyone got any ideas?

Thanks!
BrotherBeal Send private email
Thursday, December 20, 2007
 
 
It depends on how you're passing the messages back and forth..

If you're doing SMS, you'll have their phone number, so you're in good shape.

If you're doing WAP (mobile web), you're basically screwed.  Almost every carrier has a number of proxies that all traffic goes through.  For AT&T specifically, they have 2 (3, now?) that cover all of the US.  If you collect their IP address, you'll get one of the two proxies.

Alternatively, if you can create a session for the user or a cookie on the device, you'll have better luck.  Just remember that not all devices support cookies.

Fun times.
KC Send private email
Thursday, December 20, 2007
 
 
Would blue tooth work?  I think you would then have a method of "disocvering" blue tooth devices in range.
Ted
Thursday, December 20, 2007
 
 
If you can broadcast, then each device can have a "hello, anyone out there?" message and each can present a list of available devices to the user, or post requests for access. (I assume the bluetooth or other WiFi things would help there.) Some authentication would be necessary, to ensure that the guy responding to the "hello" nessage is allowed to see your data.

Otherwise, you'll need a central server which effectively does the same thing - makes a list of available devices visible, and hands over connection information.

If the devices have SMS or Windows Messenger or any other messaging service you could easily piggy-back on their infrastructure.

The WAP issue is irrelevant - if you're after a communication channel, either your device knows its own IP address or doesn't. You can relay messages via a web server and thus it would be the session ID that matters rather than the IP address, or you could use the web server to exchange IP addresses before opening a direct TCP/IP connection.

And all devices that you can load your own code onto support cookies, because a cookie is a concept and not a physical object - if you can write code that can remember an IP address, you can write code that can remember a "cookie".

Thursday, December 20, 2007
 
 
Maybe this is a case where Amazon's message queue service would come in handy?  Both devices connect to Amazon and pick up the messages that are waiting for them in their queue?

(Not really sure this would work in your context--just looking for ways to use their web services)
Doug
Thursday, December 20, 2007
 
 
Thanks for the input. I may have been a bit vague with my post, so some clarification:

@KC: I'm not sure SMS is the way to go for this particular application, as there will be frequent messages (on the order of 1 every 10 seconds or so), and the last thing I want my application to do is kill someone's wireless bill. The really attractive thing about it, though, is the use of the phone number as a device identifier - I'd love it if there were some kind of a mobile DNS that let you find a network address given a phone number.

@<blank>: I'd prefer to avoid the need for a centralized server, if possible. That implies maintenance, which implies money, which implies that this has to be treated as a business rather than a project which is something I'd rather not tie myself to =)

My basic idea is the following:

Alice's device sends a message through some protocol (SMS, XMPP, who knows what) to Bob's device, and establishes a session which both will store locally. At any point within the session, Alice or Bob can send messages or terminate the session as needed.

Maybe leveraging an existing infrastructure is the way to go, but for now this is still in a .odt document and my brain, so I'll have to keep plugging. I guess this is the good part of this business. Thanks again for the input, though!
BrotherBeal Send private email
Friday, December 21, 2007
 
 
"I'm not sure SMS is the way to go for this particular application, as there will be frequent messages (on the order of 1 every 10 seconds or so), and the last thing I want my application to do is kill someone's wireless bill."

Connection time is connection time.  Depending on the service your customer will pay no matter which mechanism you use.

That said, I thought some services had messaging protocols that last only for fractions of a second that the user wasn't charge for.  BUT that might be provider dependent.
Cat
Thursday, December 27, 2007
 
 
Can't be done.  Give up.
Sausage Choir
Friday, December 28, 2007
 
 
Are you connected to the Internet? If so you could always use DynDNS.
Krister Renaud
Tuesday, January 08, 2008
 
 
What you seem to want to do is some kind of peer to peer networking, which implies you need a discovery model (basically what you are asking). Try a google search :) You probably want the Network model if you don't want any servers involved. How you implement that in the mobile world I don't know, sorry. You might look at how http://www.pocket-lint.co.uk/news/news.phtml/10081/11105/TerraNet-peer-to-peer-free-mobile-calls.phtml works, maybe that will provide some clues (they use special/modified handsets, however).

Tuesday, January 08, 2008
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz