Asyncsockets и «тихие» отключения - PullRequest
Новая
       16

Asyncsockets и «тихие» отключения

1 голос
/ 17 марта 2011

Я использовал cocoaasyncsocket в качестве клиента для Windows .net-сервера, используя asyncsocket.Я кодирую сообщения, используя ProtocolBuffers.Вместе они составляют отличный набор инструментов.

Однако недавно я заметил, что если я оставляю клиента подключенным к серверу в течение длительного времени - много часов - когда я пытаюсь сделать запрос данных,сообщение кажется отправленным, но никогда не приходит на сервер.Я называю это «тихим» отключением, потому что я не получаю обычное отключение, которое было бы, если бы была проблема с сетью.

Я пытаюсь отладить следующие методы, но ниих вызывают: 

- (NSTimeInterval)onSocket:(AsyncSocket *)sock
  shouldTimeoutReadWithTag:(long)tag
                   elapsed:(NSTimeInterval)elapsed
                 bytesDone:(CFIndex)length {

- (void)onSocket:(AsyncSocket *)sock willDisconnectWithError:(NSError *)err

- (void)onSocketDidDisconnect:(AsyncSocket *)sock

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

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

Большое спасибо.

1 Ответ

3 голосов
/ 17 марта 2011

Если вы хотите знать, что ваши клиенты и серверы подключены, у вас должен быть пульс или "keepalive", то есть сообщение уровня приложения, которое обменивается, в основном, с сообщением "Вы там" / "да".

Это особенно верно в наше время, так как многие маршрутизаторы будут молча отбрасывать незанятые TCP-соединения. Это не то, для чего был разработан TCP, но это факт жизни.

В TCP есть опция для отправки пульса уровня соединения или активности активности с помощью SO_KEEPALIVE, но исторически существовал спор о том, было ли это уместно. Дизайнеры чувствовали, что сбрасывать сокет из-за временной промежуточной сетевой проблемы было неправильно. Если за этот период фактически не было отправлено никаких данных, не было причин прерывать соединение. Другие чувствовали, что знание, является ли связь хорошей, важно само по себе. Что делать, если вы ожидали данных, но они не пришли? Ты не хочешь знать?

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

Так как часто вы должны отправлять его?

Это зависит от баланса вещей. 1а) как часто вы обычно получаете обновления? 1b) Какая задержка является приемлемой / нормальной (например, если это является частью процесса, другие шаги обычно занимают часы, тогда 5-10 минут могут быть приемлемыми). 2a) батарея и 2b) использование данных из-за сердцебиения. Я подозреваю, что влияние на батарею / мощность будет иметь решающее значение, но на все это нужно смотреть внимательно и сбалансировать.

Вы можете потерять покрытие в любое время (туннели и т. Д.). Я бы запускал сердцебиение только в том случае, если у вас не было обновлений после того, как что-то в 0,5-5 раз превышает средний интервал обновления. Поэтому, если вы ожидаете 2 обновления в минуту, запускайте сердцебиение, если бездействует от 15 секунд до 3 минут - оцените, что лучше. При условии, что пользователь находится в приложении «вживую» и «выключает» его по окончании, срок службы батареи не является такой проблемой, так как он все равно использует его. Срок службы батареи действительно важен, если вы просыпаете устройство для обработки обновлений.

...