2016-10-06 6 views
1

В проекте C++ Builder Android, TIdUDPClient на TDataModule уважает его BoundPort, как ожидается, когда устройство подключено к Wi-Fi сети:Indy10 на Android. Как заставить TIdUDPClient уважать свойство BoundPort для сетевого подключения к сети GSM?

// 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); 
} 

Выписка из UDP сервера получать журнал:

PeerPort = 55555

Если WiFi отключен, и вместо этого устройство подключено к сети GSM (например, Telstra Australia), BoundPort свойство игнорируется, и UDP сервер получать журнал показывает:

PeerPort = 37091

Если WiFi реактивации, сервер еще раз показывает:

PeerPort = 55555

Кто-нибудь знает, как правильно выбрать правильный порт отправки, даже если сетевой сокет изменяется?

ответ

0

Indy не имеет понятия Wi-Fi и GSM сетей. Это просто привязка сокета к локальному IP/порту, независимо от того, к чему они связаны, на уровне ОС/оборудования. Тот факт, что вы не видите каких-либо исключений, означает, что привязка успешна (и вы можете убедиться, что, посмотрев на свойство amcDeviceDM->UDPC->Binding->Port после активации сокета).

При подключении к сети GSM устройство не имеет прямого подключения . Поставщик выступает в качестве шлюза/прокси для предоставления доступа к Интернету устройства. Таким образом, UDP-сервер будет получать пакеты от пары/PeerPort, принадлежащей системе провайдера, а не устройства (вы бы это видели более четко, если UDP-сервер регистрировал PeerIP). Независимо от BoundPort вы решили связать TIdUDPClient, чтобы локально на вашем устройстве было никакого эффекта на привязку порта, используемого системой провайдера, и у вас нет контроля над этим. И это прекрасно, поскольку провайдер будет обрабатывать связь между IP-портом устройства и IP-портом провайдера для вас, поэтому пакеты могут маршрутизироваться между ними по мере необходимости.

При подключении к WiFi устройство по-прежнему не имеет прямого подключения . Маршрутизатор выступает в качестве шлюза для обеспечения доступа к Интернету устройства. Таким образом, UDP-сервер будет получать пакеты от пары PeerIP/PeerPort, принадлежащей маршрутизатору, а не устройству. Независимо от того, BoundPort вы решите связать TIdUDPClient с местным номером , может быть или не быть быть сохраненным маршрутизатором. Когда маршрутизатор видит исходящий UDP-пакет, который ему нужно перенаправить на общедоступную (Интернет) сторону сети, маршрутизатор откроет порт, который привязан к общедоступному IP-адресу маршрутизатора (если он еще не открыт), а затем отправит пакет от этого публичного IP/порта. Любые пакеты UDP, которые принимаются этим общедоступным IP-портом, затем будут перенаправлены на IP-порт устройства. Этот открытый номер порта будет обычно будет тем же номером порта, который используется исходным пакетом, если этот номер порта в настоящее время доступен на маршрутизаторе, но это не гарантия.Таким образом, даже в сети WiFi по-прежнему возможно, что UDP-сервер может видеть другой PeerPort, чем то, к чему привязано устройство. И это совершенно нормально, так как маршрутизатор будет обрабатывать связь между IP/портом устройства и IP-портом маршрутизатора для вас, поэтому пакеты могут быть маршрутизированы между ними по мере необходимости. Если вам необходимо указать номер общего порта маршрутизатора, вам необходимо настроить правило сопоставления портов на маршрутизаторе, прежде чем ваше устройство начнет отправлять пакеты, либо в конфигурации маршрутизатора статически, либо динамически через uPNP.

 Смежные вопросы

  • Нет связанных вопросов^_^