In a C++Builder Android project, TIdUDPClient on a TDataModule respects its BoundPort as expected when the device is connected to a WiFi network:
// BoundPort property is set to 55555...
amcDeviceDM->UDPC->Active = true;
amcDeviceDM->UDPC->Connect();
if(amcDeviceDM->UDPC->Connected())
{
amcDeviceDM->UDPC->SendBuffer(fHost,fPort,Id_IPv4,DataPkt);
}
Extract from UDP Server receive log:
PeerPort = 55555
If WiFi is disabled, and instead the device is connected to a GSM network (like Telstra Australia), the BoundPort property is ignored, and the UDP Server receive log shows:
PeerPort = 37091
If WiFi is reactivated, the server once again shows:
PeerPort = 55555
Does anyone know how to ensure the correct sending port is always selected, even if the network socket changes?
Indy has no concept of WiFi vs GSM networks. It is simply binding a socket to a local IP/port, regardless of what they happen to be associated to at the OS/hardware layers. The fact that you are not seeing any exceptions raised means the binding is successful (and you can verify that by looking at the amcDeviceDM->UDPC->Binding->Port property after activating the socket).
When connected to a GSM network, the device does not have a direct connection to the Internet. The provider is acting as a gateway/proxy to give the device Internet access. As such, the UDP server is going to be receiving packets from a PeerIP/PeerPort pair that belongs to the provider's system, not the device (you would see that more clearly if the UDP server were logging the PeerIP). Whatever BoundPort you decide to bind TIdUDPClient to locally on your device has no effect whatsoever on the port binding used by the provider's system, and you have no control over that. And that is perfectly fine, as the provider will handle the linkage between the device's IP/Port and the provider's IP/Port for you so packets can be routed between them as needed.
When connected to WiFi, the device still does not have a direct connection to the Internet. The router is acting as a gateway to give the device Internet access. As such, the UDP server is going to be receiving packets from a PeerIP/PeerPort pair that belongs to the router, not the device. Whatever BoundPort you decide to bind TIdUDPClient to locally may or may not be preserved by the router. When a router sees an outgoing UDP packet that it needs to forward to the public (Internet) side of the network, the router will open a port that is bound to the router's public IP (if not already open), and then send the packet from that public IP/Port. Any UDP packets that are received by that public IP/port will then be forwarded to the device's IP/Port. That opened port number will usually be the same port number used by the original packet, if that port number is currently available on the router, but that is not a guarantee. So, even on a WiFi network, it is still possible for the UDP server to see a different PeerPort than what the device is bound to. And that is perfectly fine, as the router will handle the linkage between the device's IP/Port and the router's IP/Port for you so packets can be routed between them as needed. If you need to guarantee the router's public port number, you will have to configure a port mapping rule on the router before your device starts sending packets, either in the router's configuration statically, or dynamically via uPNP.
My Samsung (S4) is connected via Wifi (over a router) with a PC. Let's say the Samsung has IP address 192.168.173.5 and the PC has i.e. 192.168.173.6
On the PC I simply do a network broadcast via an UDP socket. This broadcast does never reach my android world.
If I connect an iphone to the same network the network broadcast to 192.168.173.255 reach the iphone. I found something on the net that some HTC android phone does have this kind of problems - related to the Wifi driver on the phone.
Question:
Does anybody has an idea what's wrong here and why Android does not receive these broadcast messages? Is this the wifi driver on Samsung side which does not route broadcast messages at all?
I want to send/receive data (e.g. binary or strings) from my mobile Android device to a PC over a WiFi Router.
Is it the same way I send data over WiFi with a TCP socket connection?
So I send data out of my client (Android device) and listen at my server at the port I defined?
If I already programmed the WiFi TCP socket connection, do I have to add additional program code to send the data with 3G or UMTS if I disable WiFi?
Thanks!
Michael
So it seems that there is no additional code necessary because the sockets are on a higher layer on the OSI-model than Wifi or 3G.
I'm trying to receive UDP packets from a wifi router in my android phone the phone connected to wifi router wirelessly. should I write a client in android to simply receive that UDP packet from specific port? how can I make sure that the data is received ?
i'm trying to write an app to discover hosts in the network ( like Network Discovery by Aubort), I have a question:
When the android phone send broadcast ping:
-Do the broadcast pings come to wireless router ( or Access point!) and it broadcast them for the phone? And then the wireless router receive and response the ping-echo-reply to the phone?
-If not the phone have to broadcast pings itself and I think not sure that it's signal quality is as good as wireless router's. So how to make sure that the phone have a complete scan in the network?!
(sorry for my poor English >.<)
Broadcast packets are retransmitted by the access point to other wireless clients (as well as to the wired network).