У меня есть программа, использующая двунаправленный TCP-сокет для отправки сообщений с хоста P C на преобразователь VLinx ethe rnet в последовательный, а затем на PL C через RS-232. Во время интенсивного трафика c сокет периодически прекращает обмен данными, хотя все мягкие тесты соединения показывают, что он подключен, активен и доступен для записи. Я подозреваю, что что-то прерывает соединение, из-за чего сокет закрывается без FIN / ACK. Как я могу проверить, где может произойти это отключение?
Сама программа написана на VB6 и использует Catalyst SocketTools / SocketWrench в отличие от стандартной библиотеки Winsock. Методология, свойства и код кажутся правильными, поскольку такая же установка надежно работает на двух других сайтах. Эта проблема возникает именно на этом сайте. Это происходит только во время производства, когда в сети присутствует трафик c, и соединение может теряться где-то от 20 до 100 раз за 10-часовой день.
Существуют избыточные тесты, чтобы выявить эту потерю связи и держать систему в рабочем состоянии. У нас есть тесты на сообщения ACK, размер очереди сообщений, время между передачами (токены с интервалом 2 секунды) и т. Д. c. Как правило, сокет не перестает отвечать в течение более 30 секунд, прежде чем он будет пойман, закрыт и восстановлен, что работает правильно> 99% времени.
Ранее я включал возможности ведения журнала SocketTools, которые не фиксируйте любую важную информацию. Совсем недавно я попытался заставить систему пинговать VLinx при первых признаках пропущенного сообщения (2,5 секунды). Эти эхо-запросы всегда были успешными, а это означает, что при кратковременной потере соединения на коммутаторе или точке доступа он не остается отключенным надолго.
У меня нет доступа к сетевому оборудованию, кроме P C и VLinx, которыми мы владеем. ИТ-специалисты предприятия также не склонны помогать отслеживать подобные вещи, потому что они работают на проектной модели.
Есть ли у кого-нибудь какие-либо предложения, что я могу сделать, чтобы попытаться определить, где возникает проблема, поэтому что затем я могу попытаться найти постоянное решение этой проблемы, а не использовать пластырь в виде повторного подключения несколько раз в день?