Отключение потокового HTTP-соединения как можно скорее после потери соединения - PullRequest
2 голосов
/ 23 февраля 2012

Итак, мы пытаемся поддерживать огромное количество одновременных подключений с мобильных устройств к нашему HTTP-серверу Erlang. Конечно, мобильные устройства могут иметь довольно прерывистые соединения, поэтому мы стараемся как можно быстрее сбрасывать мертвые соединения, чтобы избежать их перегрузок.

Теперь я не уверен, на каком уровне мы должны обнаруживать мертвые соединения. TCP имеет пакеты keepalive, которые требуют ACK. Поэтому в идеале мы будем отправлять пакет поддержки активности каждые 15 секунд, и если мы не получим ACK в течение следующих 15 секунд, мы прервем соединение. Тем не менее, я понятия не имею, возможно ли это даже в Эрланге. Кроме того, я думаю, что существует вероятность того, что некоторые NAT, маршрутизаторы Wi-Fi и мобильные сети получают подтверждение активности в течение определенного времени, исправьте меня, если я ошибаюсь. Так ли это, и если да, то есть ли альтернативный способ выполнения «сердцебиений» на уровне TCP?

Мы также попробовали пульс на уровне приложения - отправку \ n вниз по потоку HTTP. Однако даже при всех установленных параметрах Erlang, включая send_timeout, мы не получим никаких ошибок в течение примерно 5 минут при определенных обстоятельствах, таких как, например, мобильное устройство, отклоняющееся слишком далеко от его Wi-Fi-маршрутизатора.

Как лучше всего реализовать потоковое HTTP-соединение, чтобы сервер потерял связь как можно скорее после потери контакта? Любая помощь будет высоко ценится!

Ответы [ 2 ]

2 голосов
/ 24 февраля 2012

Вы можете добавить специальный сторожевой таймер для HTTP-соединения. Watchdog будет иметь настраиваемое время ожидания, которое будет сбрасываться после каждой операции (чтение или запись) соединения. И если в течение указанного времени не было никаких операций с сокетом - соединение закрывается.

Этот подход устранит проблему устаревших соединений (соединения абсолютно здоровы, но без какой-либо активности ввода-вывода). А если клиенты находятся вне зоны покрытия - соединение будет длиться только до указанного времени ожидания. Также не требуется механизм поддержания активности при использовании сторожевого подхода.

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

0 голосов
/ 21 апреля 2012

Комментарий Исака ответил на это за меня - настройка времени ожидания активности сокета на уровне машины.

См. http://tldp.org/HOWTO/TCP-Keepalive-HOWTO/usingkeepalive.html

...