AsyncUDPSocket сломанная труба после блокировки телефона с приложением приостановлено в фоновом режиме

Question

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

1. Запустите мое приложение
2. Отключить отслеживание местоположения в настройках моего приложения (поэтому без фона просыпается)
3. Нажмите кнопку «Домой» (приложение переходит в фоновый режим, сокет «вымораживается» с остальной частью приложения)
4. Блокировка телефона
5. Разблокировать телефон
6. Приложение резюме
7. Попытка перезапустить отслеживание и отправить что-либо из сокета. Как только я пытаюсь, я получаю ошибку SIGPIPE / EPIPE и приложение вылетает.

Я подумал, что лучший способ справиться с этим - закрывать и отпускать сокет всякий раз, когда приложение закрывается, а фоновое отслеживание не включено, но когда я пытаюсь [socket close] или [socket release] на AsyncUDPSocket, я получаю различные EXC_BAD_ACCESS ошибки. Я отправил сообщение об ошибке в команду разработчиков, но мне было интересно, может ли кто-нибудь здесь дать какие-то идеи о том, как полностью избежать ошибки SIGPIPE или других способов сохранить сокет живым, не выпуская его. Спасибо.

Answer 1

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

Идеи о том, как с этим бороться здесь: SIGPIPE сбой при переключении фоновой задачи (либо для игнорируется SIGPIPE для всего приложения, либо для сокета, либо для него предоставляется обработчик)

пс. также - кажется, что настройка игнорирования SIGPIPE не работает с подключенным отладчиком, поэтому сравните с и без.

Answer 2

На всякий случай, если кому-то любопытно (что, судя по статистике этого вопроса, это не так), я не смог определить причину ошибки SIGPIPE, но в конце концов решил проблемы с управлением памятью (которые были из-за неправильной реализации onUdpSocketDidClose в моем делегате), поэтому я могу повторно инициализировать сокет при каждом перезапуске приложения.