Wednesday, October 10, 2007 6:09 PMHi,
I have a client that runs on a Windows Mobile device (using Blackjack for testing) and it connects to a server that runs on a Windows box. The client initiated connections using TCP to the server work great, but I cannot seem to be able to receive any server initiated UDP messages on the phone. The UDP messages are used as a kind of a 'refresh' message to the client to tell it to resync it's data with the server.
My data connection is over GPRS (Edge). I've been pulling my hear out on this one for a bit now and I can't seem to find anything online about UDP messages not being received on the phone so I'm hoping someone can help me here.
So the specific question is: Is it possible to receive UDP messages on the device when using GPRS? Any other pointers, tips appreciated.
Wednesday, October 10, 2007 10:39 PM
Jari Niskala wrote: So the specific question is: Is it possible to receive UDP messages on the device when using GPRS? Any other pointers, tips appreciated.
Yes it is possible. I have previously worked on a large enterprise level application built on the Windows Mobile platform which soely used UDP to communicate over a wide range of network types (including GPRS) in a number of regions world wide.
It is not without it's challenges though.
Can you explain when/how you are attempting UDP communications. Are you storing the IP address of the PDA and at some stage in the future sending a UDP packet?
If you send a UDP message from your PDA and monitor the PDA's IP address from the server you will probably see the IP address changing every so often even though you are using the same PDA for all tests and it hasn't lost GPRS coverage during the test.
Most teleco's have a fixed number of routable IP addresses (much less than the number of customers they have), so access to the internet etc goes through a gateway which allocates them an address out of a pool. These allocations typically have a timeout associated with them (in my experience anywhere between 5 and 30 minutes), i.e. if you dont' send or reiceve a packet in this timeframe the allocation disappears and the next time your PDA attempts to access the internet it appears to be via a different IP address/port combination.
This is a problem with server originated UDP packets since you might be sending it to an "old" IP address/port number etc. Our custom protocol resolved this because we could tune the frequency the handheld sent "ping" or "keep-alive" style UDP packets to the server (which the server recorded as the PDA's last known IP address). These packets kept the gateways happy, and since we were sending these messages for application logic reasons anyway it didn't significantly increase data charges occurred by our customers.
Hope this helps,
Wednesday, October 10, 2007 11:10 PMHi Christopher,
Thank you for your response. This does clear up a lot.
In our case the client does report the IP address to the server which is then used by the server to send the UDP packet.
For some reason though even when the IP address hasn't changed, the UDP packets aren't received on the client, but at least knowing that it should be possible while the IP hasn't changed is great.
Now is there anything specific that you can think of regarding setting up the socket etc on the client side?
Currently the client does the following:
1. Create socket
socket(AF_INET, SOCK_DGRAM, IPPROTO_UDP);
2. Bind the socket to:
sin_family = AF_INET;
sin_addr.s_addr = htonl(INADDR_ANY);
sin_port = htons(port); // 52311
3. Make it non-blocking (i've also tried the socket in blocking mode)
And thanks again for your response.
Saturday, October 13, 2007 12:08 AMDid some more digging around on this and found out that depending on the carrier, mine is Cingular/ATT, a static IP might be required in order to be able to receive UDP/TCP connections. This can be requested from the carrier (haven't done this yet).
Since this is dependent on the carrier, it's best to check directly with your carrier.
Hope this will save someone else a lot of time and headache.
Thursday, April 24, 2008 1:43 PMHi Jari,
Did you manage to get your client-server application working? If so, could you share your experience here? I am having the same problem for more than two weeks. You mentioned:
"Did some more digging around on this and found out that depending on the carrier, mine is Cingular/ATT, a static IP might be required in order to be able to receive UDP/TCP connections."
Where did you get that info from? I am curious about it. I am waiting for your reply or maybe other people out there could help me too?
Thursday, April 24, 2008 4:56 PMHi Sam,
I actually ended up going to the technical support chat with AT&T/Cingular to get the answer.
Regarding implementation, we never did end up actually getting static ip addresses as we are counting on it working over WiFi and using more of a polling mechanism as a backup if on GPRS. However, at least so far the UDP messages weren't working but haven't looked into this yet... Need to get a new phone with WiFi support first.
I'll probably be working on this over the next week so I'll post an update if I find out anything useful.
Thursday, April 24, 2008 9:57 PMHi Jari,
I never expected someone to reply me that fast. thank you very much . So, right now you are able to use your WiFi to communicate with your server, right? Did the WiFi use a static IP address or dynamic one?
I heard that it is difficult to get a static IP from the carrier. I am not surprised that they wont give you one.
I think the problem with the GPRS is that what you see is the internal IP address, but the server sees the external one. Hence, the information back from the server never reach the client. There is a mechanism called NAT to translate between internal and external IP address. I am not an expert in this field so what I have just said maybe wrong. Please correct me, anybody.
Thanks, and I waiting for your update, Jari.
Thursday, April 24, 2008 10:10 PMHi Sam,
Thanks . I just heard from the guys in our group that were using Wifi that they did in fact get the UDP messages to come through. Communication over TCP was always working well. I think the issue was with ActiveSync causing the IP Address to change and in making sure the correct ip address was used like you mentioned...
For the IP address, I think the device actually gets assigned one from the wifi network depending on how that's configured.
I'm about to go buy a device with wifi so i can set it up for testing locally
Friday, April 25, 2008 4:48 PMJari,
Too bad, none of us can make the GPRS connection work in the client-server app. However, I will try my best to dig in further to get this issue solved.
Monday, November 09, 2009 9:30 PMMan I had that same problem with active sync changing the local IP address that connection manager uses. I was able to have the UDP socket bind to an endpoint, but when sending to a remote point there was a socket exception. I have a suggested work around solution for AT&T/Cingular, if the static IP actually changes with out you keeping alive the connection, you can have the phone(server) send the new IP to the client machine, and then the client machine can adjust to the new IP address on the phone. I noticed applications such as windows messenger actually does this.
Tuesday, November 10, 2009 2:46 AM
just wondering how this is done.Mobile Phone IP is non-routable which issues by Telco. It is ok from MObile to send data to Server computer. But from Server Computer sending back to MObile part I am not sure. The question is how to pass data to Telco network?
Peace is the fruit of Love