Что происходит с соединениями TCP и UDP (с многоадресной рассылкой), когда приложение iOS действительно входит в фоновый режим - PullRequest
7 голосов
/ 28 января 2012

Я создал пару экспериментов:

Настройка 1. Я создал приложение TCP Sender и приложение TCP Receiver.

Для этого эксперимента я запустил отправителя TCP на устройстве iOS и приемник TCP на другом устройстве iOS. И тогда оба проверяются, чтобы установить соединение и отправки и получения данных. Затем я помещаю приложение TCP Receiver в фоновый режим. Приложение TCP Sender указывает на потерю соединения и сбой (да, я так и думал).

Настройка 2: я создал приложение UDP Sender и приложение UDP Receiver.

Так же, как и выше, я запустил приложение UDP Sender на устройстве iOS и приложение UDP Receiver на другом устройстве iOS. В приложении UDP Receiver я подписался на группу многоадресной рассылки и т. Д. Я убедился, что приложение UDP Receiver получает данные из этой группы многоадресной рассылки, отправленные приложением UDP Sender. Затем я помещаю приложение UDP Receiver в фоновый режим. Через 2 минуты я получаю приложение UDP Sender для отправки другого фрагмента данных. Затем я полностью закрываю приложение UDP Sender и выключаю это устройство iOS. Затем я подожду еще 2 минуты или более, а затем выведу приложение UDP Receiver из фона. Приложение UDP Receiver действительно получило данные, отправленные приложением UDP Sender, до того, как оно было прервано.

В setup1 мое объяснение состоит в том, что TCP ориентирован на соединение.

В setup2 я понимаю, что UDP не подключен. Любое объяснение, почему setup2 работал так, как мне кажется? (Все еще получает данные даже в фоновом режиме)

Ответы [ 2 ]

11 голосов
/ 28 января 2012

Все, что происходит, когда вы помещаете приложение в фоновый режим, а затем отпускаете его приостановленным, заключается в том, что оно перестает планировать ядро.Он не сразу разрывает какие-либо соединения и не разрушает любые сокеты (если вы не принудительно).

В вашем случае UDP ядро ​​получает пакет и помещает его в буфер ядра, ожидая, пока ваше приложениеполучить это.Поскольку процесс вашего приложения существует, но фактически остановлен, данные будут просто храниться в буфере ядра.Если вы получите слишком много данных, он переполнит буфер ядра и будет удален.В противном случае ваше приложение может получить его, когда (если) оно запланировано снова.

В случае с TCP в значительной степени происходит то же самое.

Но (большой, но): ОС всегда имеетвозможность срывать сокеты для приостановленных приложений, если это необходимо, на основании нехватки памяти и т. д. Поэтому, хотя это не обязательно будет делать это безвозмездно, оно может сделать это.

Я не совсем уверен, почему выВы видите, что соединение TCP разорвано быстро.Может случиться так, что эвристика ядра для сервера соединений TCP более агрессивна, чем для сокетов UDP, поскольку соединения TCP требуют большего количества состояний и более непрерывной обработки, чем сокеты UDP.

См. Техническое примечание TN2277 Сеть и многозадачность .

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

Мое мнение из-за ОС, этого не должно происходить, если вы пробовали на ОС Android, потому что у IO есть ограничения на то, что может работать на фоне, а что нет.я думаю, потому что TCP требует больше ресурсов для отправки информации.TCP использует потоки данных, а UDP использует блоки данных.Проблема заключается в том, что TCP создает большие пакеты данных, в то время как UDP использует 8 КБ блоков данных.

...