TcpListener прекращает принимать или принимает разорванные соединения

Question

В настоящее время у нас проблема с самописным серверным приложением, работающим в Windows (встречается в разных версиях). Сервер прослушивает порт TCP, принимает соединения, обменивается некоторыми данными, а затем снова закрывает соединения. Время от времени подключается около 100 клиентов.

Иногда сервер перестает работать: файлы журнала показывают, что соединения по-прежнему принимаются, но при первой попытке чтения возникает ошибка сокета (10054 - Сброс соединения по одноранговой сети). Я не думаю, что это проблема клиента, потому что она внезапно перестает работать для всех клиентов.

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

Есть идеи, где искать? Журналы Wireshark будут в ближайшее время ..

Выдержка из журнала (метка времени, идентификатор темы, сообщение)

11:37:56.137 T#3960 Connection from 10.21.13.3
11:37:56.138 T#3960 Client Exception: Socket Error # 10054
Connection reset by peer.
11:37:56.138 T#3960 ClientDisconnected
11:38:00.294 T#4144 Connection from 10.21.13.3

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

Answer 1

«Брандмауэр с состоянием» или NAT отслеживает соединения и должен посылать RST для соединений, о которых он не знает.Если брандмауэр по какой-то причине теряет связь, то вы, вероятно, увидите, что случайные соединения сбрасываются.

Наш маршрутизатор в работе делает это - он забывает о соединениях, когда соединение PPP умирает, что удивительно бесполезно, когдаидет дождь и перезапуск DSL занимает слишком много времени.Однако вместо сброса соединений он просто отбрасывает пакеты (что еще более бесполезно!).

Answer 2

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

Серверное приложение использует log4net, для которого настроен файл журнала ImmediateFlush = true. Если каждый оператор журнала напрямую записывается в файл и происходит несколько соединений сокетов, это замедляет работу всего приложения. Серверу потребовалось около минуты, чтобы действительно принял соединение. Это было намного больше, чем тайм-аут на стороне клиента. Таким образом, в журнале было показано только «принято» и «отключено» - даже журнал был отложен!

Приносим извинения за неудобства ...

Answer 3

Похоже на проблему с брандмауэром или маршрутизацией - возможно, устаревшие соединения отключаются после истечения времени ожидания.Используете ли вы ping / keepalive внутри вашего протокола.
В противном случае вы можете попросить Wireshark узнать, что происходит.

Answer 4

Как выглядят логи со стороны клиента?

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

Если ошибка отсутствует на стороне клиента;тогда я бы сказал, что на вашей стороне клиента вы увидите реальную ошибку.

Answer 5

Вы не говорите, какие версии Windows вы используете для сервера, но вы должны знать, что стек Windows TCP / IP ведет себя по-разному в серверных и клиентских ОС.Существуют ограничения на количество одновременных входящих подключений, которые разрешает клиентская ОС, и они значительно ниже, чем вы могли бы ожидать.

Answer 6

Вы пытались изменить отставание, а затем посмотреть, сколько времени или сколько клиентов обслуживается до возникновения этой проблемы