Жизнь TCP соединения - PullRequest
       8

Жизнь TCP соединения

19 голосов
/ 01 октября 2008

Как долго можно ожидать, что TCP / клиент-сервер будет длиться в дикой природе?

Я хочу, чтобы он оставался постоянно на связи, но вещи случаются, поэтому клиенту придется переподключаться. В какой момент я говорю, что в коде есть проблема, а не какое-то внешнее оборудование?

Ответы [ 6 ]

16 голосов
/ 01 октября 2008

Я согласен с Zan Lynx. Нет никакой гарантии, но вы можете поддерживать соединение практически бесконечно, отправляя данные через него, при условии отсутствия проблем с подключением или пропускной способностью.

Обычно я придерживался подхода поддержания уровня приложений, хотя обычно это происходит потому, что это было в спецификации клиента, поэтому мне пришлось это сделать. Но просто отправляйте какой-нибудь короткий фрагмент данных каждую минуту или две, и вы ожидаете какого-то подтверждения.

Считаете ли вы, что один сбой подтвердил, что не удалось установить соединение, решать вам. Как правило, это то, что я делал в прошлом, хотя был случай, когда я ждал три неудачных ответа подряд, чтобы разорвать соединение, потому что приложение на другом конце соединения было чрезвычайно ненадежным, чтобы ответить на: «Вы здесь? ?» запросы.

Если произойдет сбой соединения, что, возможно, в какой-то момент произойдет, даже если машины находятся в одной сети, просто попытайтесь восстановить его. Если это не удается установленное количество раз, то у вас есть проблема. Если ваше соединение постоянно прерывается после того, как оно было подключено какое-то время, у вас снова возникла проблема. Скорее всего, в обоих случаях это, скорее всего, проблема с сетью, а не с вашим кодом, или, возможно, проблема со стеком TCP / IP на вашем компьютере (известно: у меня возникли проблемы с этим на старой версии QNX - это просто случайно упадет). Сказав, что у вас может быть проблема с программным обеспечением, и единственный способ узнать наверняка - это часто подключить отладчик или войти туда. Например. если вы всегда можете подключиться успешно, но через некоторое время вы перестанете получать ACK, даже после повторного подключения, то, возможно, ваш сервер заблокирован или застревает в цикле или что-то в этом роде.

Что действительно полезно, так это настроить серию длительных тестов при различных условиях нагрузки: от просто отправки запросов на сохранение активности и ответов на них / ack до полной нагрузки на сервер. Как правило, это придаст вам больше уверенности в ваших программных компонентах и ​​может быть очень полезно для устранения некоторых действительно странных проблем, которые не обязательно вызовут проблемы с вашим соединением, хотя они могут привести к проблемам с проводимыми транзакциями. Например, когда-то я писал сервер приложений для телекоммуникаций, который предоставлял такие услуги, как перевод номеров, и мы просто оставляли его работать по несколько дней. Дело в том, что когда наступила суббота, на целый день она отклоняла каждый поступивший запрос на вызов, который составлял миллионы вызовов, и мы не знали, почему. Оказалось, из-за одной опечатки в коде преобразования даты, которая вызвала проблему только по субботам.

Надеюсь, это поможет.

13 голосов
/ 07 января 2009

Я думаю, что самая важная идея здесь - теория против практики.

Первоначальная теория заключалась в том, что связи не имели времени жизни. Если у вас было соединение, оно оставалось открытым всегда, даже если трафика не было, пока событие не привело к его закрытию.

Новая теория заключается в том, что в большинстве выпусков ОС включен таймер поддержки активности. Это означает, что соединения будут длиться вечно, пока система на другом конце реагирует на случайный обмен на уровне TCP.

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

Два действительно хороших примера: удаленный клиент использует DHCP, срок аренды истекает, а IP-адрес меняется.

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

Способ реализации логики переподключения во многом зависит от вашей архитектуры, рабочей среды и целей производительности.

7 голосов
/ 01 октября 2008

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

6 голосов
/ 01 октября 2008

Там действительно нет никакого способа сказать. В TCP нет ничего, что могло бы привести к разрыву соединения через определенное время. У кого-то в надежном соединении могут быть годы безотказной работы, а у другого - каждые 5 минут. Нет никакого способа сказать или даже догадаться.

2 голосов
/ 01 октября 2008

Вам понадобятся данные, периодически передаваемые по соединению, чтобы поддерживать его в рабочем состоянии - многие ОС или брандмауэры будут сбрасывать неактивное соединение.

0 голосов
/ 01 октября 2008

Выберите значение. Одна капля каждый час, вероятно, хорошо. Десять неожиданных обрывов соединения за 5 минут, вероятно, указывают на проблему.

TCP-соединения обычно длятся около двух часов без трафика. Любой конец может отправлять пакеты keep-alive, которые, я думаю, являются просто ACK для последнего полученного пакета. Обычно это можно установить для каждого сокета или по умолчанию для каждого TCP-соединения.

Поддержание уровня приложения также возможно. Для протокола в стиле telnet, такого как FTP, SMTP, POP или IMAP, что-то вроде отправки возврата, перевода строки и возврата из командной строки.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...