Как долго я могу ожидать, что TCP/TCP-соединение клиента/сервера будет продолжаться в дикой природе?
Я хочу, чтобы он оставался на постоянной основе, но все происходит, поэтому клиенту нужно будет снова подключиться. В какой момент я могу сказать, что проблема в коде, а не проблема с каким-то внешним оборудованием?
Я согласен с Zan Lynx. Нет никакой гарантии, но вы можете поддерживать связь практически неограниченно, отправляя данные по ней, предполагая, что нет проблем с подключением или пропускной способностью.
В общем, я пошел на уровень поддержки на уровне приложений, хотя обычно это происходит из-за того, что он был в спецификации клиента, поэтому мне пришлось это делать. Но просто отправляйте короткий фрагмент данных каждую минуту или две, к которым вы ожидаете какое-то подтверждение.
Если вы считаете, что один отказ не был подтвержден, так как сбой связи был до вас. Как правило, это то, что я делал в прошлом, хотя был случай, когда я ожидал трех неудачных ответов подряд, чтобы отказаться от соединения, потому что приложение на другом конце соединения было очень неприятным в ответе на "вы там"?" запросы.
Если соединение не удастся, что в какой-то момент, вероятно, будет, даже с машинами в той же сети, а затем попробуйте восстановить его. Если это не выполняется определенное количество раз, то у вас есть проблема. Если ваше соединение настойчиво терпит неудачу после того, как оно было подключено какое-то время, то снова возникает проблема. Скорее всего, в обоих случаях это, вероятно, проблема с сетью, а не с вашим кодом, или, может быть, проблема с стеком TCP/IP на вашем компьютере (было известно: у меня возникли проблемы с этой версией в старой версии QNX - это просто случайно выпадают). Сказав, что у вас может быть проблема с программным обеспечением, и единственный способ узнать наверняка - это часто прикреплять отладчик или получать некоторые записи. Например. если вы всегда можете успешно подключиться, но через какое-то время вы перестанете получать ACK, даже после повторного подключения, тогда, возможно, ваш сервер блокируется или застревает в цикле или что-то в этом роде.
Что действительно полезно, чтобы установить серию длительных тестов в различных условиях загрузки, просто отправляя в режим сохранения, вы там? /ack запросы и ответы, чтобы полностью избивать сервер. Это, как правило, дает вам больше уверенности в ваших программных компонентах и может быть очень полезно в избавлении от некоторых действительно странных проблем, которые не обязательно вызовут проблему с вашим соединением, хотя они могут привести к проблемам с транзакциями. Например, я когда-то писал сервер приложений для телекоммуникаций, который предоставлял такие услуги, как перевод чисел, и мы просто оставим его работающим в течение нескольких дней. Дело в том, что, когда суббота наступит, на весь день, он отклонит каждый запрос на вызов, который пришел, который составил миллионы звонков, и мы понятия не имели, почему. Это оказалось из-за одной опечатки в каком-то коде конверсии даты, что только вызвало проблему по субботам.
Надеюсь, что это поможет.
Я думаю, что самая важная идея здесь - теория против практики.
Исходная теория заключалась в том, что соединения не имели времен жизни. Если у вас было соединение, оно оставалось открытым навсегда, даже если трафика не было, пока событие не заставило его закрыть.
Новая теория заключается в том, что большинство выпусков ОС включили таймер keep-alive. Это означает, что соединения будут длиться вечно, пока система на другом конце реагирует на случайный обмен уровня TCP.
В действительности, многие соединения будут прекращены со временем, с множеством критериев и ситуаций.
Два действительно хороших примера: удаленный клиент использует DHCP, срок аренды истекает, и IP-адрес изменяется.
Другим примером является брандмауэры, которые, как представляется, становятся все более интеллектуальными и могут идентифицировать трафик постоянного трафика против реальных данных и закрывать соединения на основе любых критериев высокого уровня, особенно простоя.
Как вы хотите реализовать логику повторного подключения, многое зависит от вашей архитектуры, рабочей среды и целей производительности.
Не имеет значения, вы должны разработать свой код для автоматического повторного подключения, если это желаемое поведение.
Невозможно сказать. Для TCP нет ничего, что могло бы привести к простому подключению через определенное время. У кого-то на надежном соединении могут быть годы бесперебойной работы, в то время как кто-то из другого соединения может повторно подключаться каждые 5 минут. Невозможно сказать или даже догадываться.
Вам понадобятся некоторые данные, проходящие через соединение, чтобы сохранить его в живых - многие ОС или брандмауэры будут отключать неактивное соединение.
Выберите значение. Одна капля каждый час, вероятно, прекрасна. Вероятно, десять неожиданных соединений за 5 минут указывают на проблему.
TCP-соединение обычно длится около двух часов без какого-либо трафика. Любой конец может отправлять пакеты keep-alive, которые, я думаю, просто ACK на последнем полученном пакете. Обычно это можно установить для каждого сокета или по умолчанию для каждого TCP-соединения.
Также возможен уровень поддержки на уровне приложений. Для протокола типа telnet, такого как FTP, SMTP, POP или IMAP, что-то вроде отправки return, newline и возврата командной строки.