Качество соединения TCP в .NET

У меня есть критически важное приложение для работы с данными в реальном времени, которое использует TCP-соединение между клиентом и сервером. В некоторых случаях соединение периодически обрывается (SocketException). Нет проблем — просто переподключитесь и двигайтесь дальше. Тем не менее, клиенты не в восторге от этих периодических пропаданий связи.

Я хотел бы знать, куда тыкать пальцем. Это клиент или сервер? Аппаратное или программное обеспечение? Это что-то о канале Ethernet? Конечным результатом будет отображение пользователю индикатора работоспособности соединения, чтобы можно было исследовать и исправить неверную ссылку.

Есть ли какие-либо показатели, которые я могу получить из TcpClient, Socket или чего-либо еще, что скажет мне о работоспособности соединения? Возможно, среднее время подтверждения, количество повторных попыток и т. д.?

Я особенно хочу знать о TCP-соединении, а не только об Ethernet-соединении в целом (ваше соединение с локальной сетью может быть отличным, но может возникнуть проблема с внешним сервером).

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


tcp .net sockets
person Jon B    schedule 15.10.2008    source источник

Ответы (2)


arrow_upward
5
arrow_downward

Во-первых, вы должны проверить детали SocketExceptions, которые вы получаете. Я не знаю, что они содержат в .Net, но в Java подробное сообщение дает полезную подсказку, например, «Соединение закрыто узлом» или «Сброс соединения».

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

В корпоративных установках типичной причиной закрытия длительных TCP-соединений является устройство брандмауэра, которое закрывает TCP-соединения без трафика, скажем, через 10 минут, или закрывает соединения после того, как их возраст достигает, скажем, 30 минут, независимо от трафика. . В общем, лучше предположить, что такие вещи произойдут, и быть готовым изящно восстановить соединение.

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

person Alexander    schedule 15.10.2008
comment
+1 за сниффер. Wireshark, сниффер, ранее известный как Ethereal, очень хорош. - person Zan Lynx; 17.01.2009

arrow_upward
1
arrow_downward

Perfmon - ваш друг, запустите журнал для всех счетчиков IP, TCP и сети. Если вы можете сказать, когда соединение прервалось, вы можете посмотреть на графике, чтобы увидеть, есть ли что-нибудь — сетевые ошибки, отсутствие передачи, не переданные байты ввода-вывода и т. д.

Добавьте также некоторые счетчики .NET, такие как GC, использование памяти и ЦП.

Последнее, что вы можете сделать, это увеличить время ожидания TCP и другие параметры. Они в реестре

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

person gbjbaanb    schedule 15.10.2008
comment
Спасибо. Тем не менее, я действительно ищу способ сделать это в небольшом масштабе внутри приложения. Если клиент сообщает о большом количестве разорванных соединений, я не могу попросить его попросить ИТ-отдел потратить день на его поиски (хотя это было бы неплохо). - person Jon B; 16.10.2008
comment
вы можете поговорить с клиентом, хотя я делал это несколько раз до сих пор, чтобы попытаться отследить проблемы с памятью, производительностью и сетью. Часто это проблема с сетевой картой. Если вы «работаете» с клиентом, это обычно заставляет его чувствовать себя теплым и пушистым. - person gbjbaanb; 16.10.2008