Разобщение сокета На Одном конце, брандмауэр?

Question

У меня есть приложение на C #, которое отлично работает уже несколько лет.Он подключается через сокет TCP / IP к компьютеру, который отправляет мне выполнение биржевых сделок.

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

Когда происходит разрыв соединения в моем приложении (на стороне клиента), я не вижу ничего необычного, за исключением того, что я перестаю получать данные через сокет.Wireshark подтверждает, что никакие данные не поступают в сокет, а поток приема моего приложения блокируется при вызове Receive(), когда я останавливаю его в отладчике.Сокет отображается так, как УСТАНОВЛЕНО в netstat.

Но со стороны сервера это выглядит так, как будто мой клиент отключается.Глядя на их журналы, похоже, что сокет на их конце обычно заканчивается либо (nRecvd = -1, errno = 104), либо (nRecvd = 0, errno = 11).(104 - это сброс соединения одноранговым узлом).

Кажется, что разрыв соединения происходит только после некоторого периода бездействия.На данный момент я решил эту проблему, внедрив сердцебиение между моим клиентом и их сервером, которое просто отправляет короткое сообщение каждые 20 секунд и получает ответ.Это привело к тому, что за последние несколько дней количество отключений упало до 0.

Сначала я решил, что проблема была в аппаратном брандмауэре.Это приводило к тайм-ауту сокета после завершения работы.Но человек, отвечающий за брандмауэр, утверждает, что тайм-аут для подключений по этому порту (8887) составляет 2160 минут.

Я использую Windows Server 2003 и .NET 3.5.Торговый сервер - это linux-машина (я полагаю, sles9, хотя и не уверен).

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

Спасибо, Майк

Answer 1

То, что вы описываете, является обычным явлением, и обычно внедряется heartbeat для поддержания работы TCP-сокетов через такие брандмауэры / шлюзы, как вы сделали.

У этого оборудования могут быть жесткие тайм-ауты в 2160 минут (хотя, по моему опыту, чаще встречается 20-30 минут), но соединения обычно прерываются гораздо более агрессивно, если есть какая-либо нагрузка.Такие брандмауэры имеют ограниченные ресурсы, и когда им требуется дополнительное отслеживание подключений, они, как правило, отбрасывают самое старое отслеживаемое соединение без какой-либо активности, независимо от установленного жесткого тайм-аута.

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

Answer 2

Я бы настроил wiresharp по обе стороны брандмауэра, чтобы посмотреть, что происходит на TCP (и более низком уровне).И когда администратор говорит, что "тайм-аут для подключений" - это что-то.Это тайм-аут для незанятого установленного соединения?Все остальное, я думаю, не имеет никакого смысла.

Кроме того, используете ли вы опцию KeepAlive для TCP?И перенаправляется ли это брандмауэром или нет?

Как я уже сказал, вероятно, вы захотите запустить wireshark по обе стороны брандмауэра...