2016-06-02 14 views
0

Я установил соединение StreamWriter/StreamReader с помощью NetworkStream для управления частью испытательного оборудования. Основное соединение - TCP.C# StreamWriter/NetworkStream/TcpClient/Не отправляет данные после простоя в течение +5 минут

В данном конкретном случае это соединение остается бездействующим в течение нескольких минут. По прошествии +5 минут, когда я звоню streamWriter.writeLine(...), затем заподлицо, никакие данные не отправляются с моего компьютера на тестовое оборудование (просмотр пакетов на проводах). До и во время простоя пакеты не обмениваются. Нет FIN или RST пакеты, и т.д. ...

Отладка мой streamWriter объект, это, как представляется, по-прежнему в силе (connected = true, и т.д ...)

У меня возникли проблемы определения того, что часть моего StreamWriter//TcpClient объект отключается или закрывается без отправки сообщения FIN или RST для официального закрытия соединения.

Вот сокращенный вариант кода, который неисправный:

private void button1_Click(object sender, EventArgs e) 
{ 
     TcpClient client; 
     NetworkStream networkStream; 
     System.IO.StreamReader streamReader; 
     System.IO.StreamWriter streamWriter; 
     string outputString; 

     client = new TcpClient("555.555.555.555", 5025); 
     client.ReceiveTimeout = 5000; 
     networkStream = client.GetStream(); 
     streamReader = new System.IO.StreamReader(networkStream); 
     streamWriter = new System.IO.StreamWriter(networkStream); 

     //This section works fine, every time 
     streamWriter.WriteLine("*IDN?\n");  //Ask for equipment identification 
     streamWriter.Flush(); 
     outputString = streamReader.ReadLine(); 
     Console.WriteLine("First Attempt: Connected to: {0}", outputString); 

     System.Threading.Thread.Sleep(301000); //Simulate idle connection time 

     //The read in this section fails if the sleep above is longer than 5 minutes 
     streamWriter.WriteLine("*IDN?\n");  //Ask for equipment identification 
     streamWriter.Flush(); 
     outputString = streamReader.ReadLine(); 
     Console.WriteLine("Second Attempt: Connected to: {0}", outputString); 
} 

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

Если я изменю свой сон на что-то менее 5 минут, все будет хорошо.

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

Я также не считаю, что это проблема сторонних сетей, так как Wireshark показывает, что никакие сообщения FIN или RST не были отправлены/получены, и моя попытка выписать сообщение через 5 минут не виден Wireshark, что также работает на моем компьютере.

Я запускаю Microsoft Visual Studio 2010 на своем компьютере под управлением Windows 7, если это помогает.

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

+0

У меня была та же проблема. Это не проблема с вашим кодом. Что-то между устройствами - это очистка простоя соединений (вероятно, брандмауэр с состоянием). Добавление keepalive (10 минут было адекватным в моем случае) было единственным решением, которое я смог найти. – itsme86

+0

стоит попробовать * на всякий случай * - установить 'NoDelay' на tcp-client –

+0

С некоторыми дополнительными копаниями я отключил свое антивирусное ПО« Symantec »и больше не мог воссоздать проблему. Похоже, что политика на моем компьютере, созданная ИТ-отделом, отключит простоя. В попытке играть хорошо с политикой, я собираюсь реализовать простую проверку времени, где, если в последний раз, когда соединение было использовано, было какое-то время назад, я закрою и снова открою соединение. – Peter

ответ

0

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

 Смежные вопросы

  • Нет связанных вопросов^_^