RNDIS потеряла соединение / проблема с задержкой - PullRequest
2 голосов
/ 20 декабря 2011

У нас есть временный клиент SOAP, написанный на C #, который подключается к сервису CXF на рабочем столе с устройства Windows Mobile. Когда это устройство подключено через ActiveSync, оно создает виртуальный адаптер для подключения RNDIS. Этот виртуальный адаптер назначает хосту IP-адрес шлюза, 169.254.2.2.

Когда мы пытаемся установить соединение с именем хоста или IP-адресом хоста, заданным в качестве адреса в клиенте C #, все работает отлично. Однако когда мы устанавливаем IP-адрес в качестве шлюза RNDIS (169.254.2.2), соединение на стороне сервера периодически теряется. Служба CXF продолжает пытаться подключиться и в конечном итоге успешно, но это приводит к значительному замедлению соединения. Об ошибках в наших журналах не сообщается на стороне мобильного C #, только на сервере CXF.

Кто-нибудь знает, почему это происходит? Мы должны утверждать, что 169.254.2.2 невозможно использовать в качестве действительной конечной точки, прежде чем мы исключим ее.

О, и в случае, если это помогает, клиенту C # предоставляется IP 169.254.2.1 через DHCP после подключения ActiveSync.

Ответы [ 2 ]

1 голос
/ 12 января 2012

Первая проблема, которая приходит мне в голову, особенно после того, как я увидел, что вы используете DCHP, заключается в том, что время аренды IP-адреса от DHCP-сервера истекает, и серверу CXF приходится ждать выдачи DCHP-серверомновый срок аренды.

Попробуйте увеличить срок аренды DCHP, если вы знаете, что IP-адрес не изменится, и используйте статический IP-адрес, если это возможно.Это по крайней мере удалит эту точку отказа.

0 голосов
/ 31 января 2012

Я выяснил причину этого, но мне неприятно отвечать, потому что я сомневаюсь, что кто-то еще мог догадаться, что это проблема:

На нашем CXF-сервере у нас есть звонокInetAddress.getHostName(), который в основном выполняет обратный поиск DNS по запросу, отправленному от клиента C #.

При использовании IP-адреса ActiveSync в DNS не было записи для 169.254.2.1 (конечно), поэтому класс java зависал до истечения времени ожидания метода (что заняло около 20 секунд, прежде чем он записал быответ клиенту C #).При 20 секундах на запрос это приводило к значительному замедлению и ошибкам потерянного соединения.

Мы исправили это, переместив вызов в поток исполнителя, принудительно завершившийся через полсекунды.Поскольку это было в другой теме, замедление стало несуществующим.Рад, что покончил с этим!

...