Странности TCP

[Artem.spb]

Возникло затруднение, которого до сих пор удавалось избегать в силу локальности передачи данных. Но сейчас приложение будет работать через интернет.
Есть несколько контроллеров, которые стучаться к серверу и шлют ему данные примерно раз в минуту.
Есть сервер, ждущий слушателем. Как только появляется входящее соединение, ему открывается клон обработчика пакетов.
Обработчик с таймаутом 5 сек читает данные из сетки. Если приходят, складирует в базу, если не приходят, смотри код ошибки. Если 56 (таймаут), то жить можно, если любая друга, то закрывает соединение и завершает работу.
Если контроллер именно закрывает соединение, то всё хорошо, выскакивает ошибка (кажется 66).
Но, если при работающих контроллере и сервере я нагло выдерну провод (имитируя потерю связи), то на сервере продолжает сыпаться ошибка 56 таймаут, и программа считает, что связь всё ещё есть, продолжает крутить цикл.
И при этом контроллер может успешно установить ещё один сеанс связи и слать данные по новому каналу, а старый так и будет крутиться с ошибкой 56.
Кто-нибудь сталкивался с такими странностями? как понять, что связь именно прервалась?

[Vitekkz88]

Кто-нибудь сталкивался с такими странностями? как понять, что связь именно прервалась?

После рукопожатия клиента-сервера считается что связь установлена. А прекращается связь после прощания(то есть после вызова TCP Close). Отслеживание физического разрыва связи в протоколе(на сколько мне известно) не предусмотрено. То есть нет конкретной ошибки, которая бы говорила "Связь потеряна, так как отсоединили кабель или кабель порвался и т.д."
Ошибка 56 - носит общий характер. Она не даёт информации о том, по какой причине произошел таймаут(физический дисконект либо это ошибка на программном уровне:данные не пришли/не отправились).
Если у Вас есть доступ к исходникам клиента-сервера, то:
1. Можете добавить свой пакет жизни(эхо-пакет, который отправляется раз секунду например для проверки связи).Этот пакет с подтверждением со стороны сервера. Если подтверждение не получено через N-секунд, то можете попробовать отправить этот пакет еще раз. Если повторно не пришло подтверждение - считаете что соединение прервано по причине "Нет ответа от сервера" либо "Ошибка отправки данных на стороне клиента".
2. Делайте ping через LabVIEW. Результат парсите и находите кол-во потерь при передачи. Если есть потери - то считаете соединение разорваным(или как минимум связь не установлена из-за неверных сетевых настроек).
3. Если Вас интересует конкретика в плане отсоединения кабеля - то используйте WinAPI. Вероятней всего там есть функция, которая возвращает информацию о состоянии сетевого подключения.
4. Так же может помочь информация о сетевой карте https://decibel.ni.com/content/docs/DOC-1267, а именно поле speed. Например, если отключить кабель - то speed =0. Иначе там отображается скорость соединения.
Последние 2 варианта актуальны на уровне Windows. Я не знаю, можно ли это будет на контроллерах реализовать(есть ли там такой функционал).

[dadreamer]

В этом плане Network Streams - более удобная технология, т.к. позволяет отследить отключения удалённой стороны, как физические, так и программные, и при построении соответствующей логики может переподключить соединение, так что программа сможет стабильно работать дальше. Насколько я помню из того, что раньше делал, у каждой точки есть такие свойства: Is Connected? и Remote Endpoint Destroyed.

2015-12-08_10-10-27.jpg (20.45 КБ) 9406 просмотров

Первое равно False при отсутствии связи читающей и пишущей стороны, в том числе и при выдёргивании кабеля из сетевого разъёма. Второе равно True при закрытии сетевого подключения (Destroy Stream Endpoint) (возможно, также и при аварийном закрытии программы, сейчас точно не помню). Можно этим пользоваться так: если нет ошибки error out И точка подключена И точка НЕ разрушена, то читаем или пишем указанное число элементов. В противном случае (если нет ошибки error out И точка НЕ подключена И точка НЕ разрушена), мониторим свойства Is Connected? и Remote Endpoint Destroyed в течение некоторого промежутка времени (например, 1 мин.). Если появилась связь или точка была разрушена, прекращаем мониторинг. При разрушении точки закрываем соединение (Destroy Stream Endpoint) и открываем заново, как при начальной инициализации. Ну, а если связь появилась, работаем дальше, как ни в чём ни бывало. Само подключение достоверно устанавливается, когда нет ошибки error out И ссылка на точку НЕ Not A Number/Path/Refnum?.

[Vitekkz88]

dadreamer писал(а):Network Streams - более удобная технология

С помощью Network Streams можно подключиться к стороннему(не LabVIEW-шному) серверу TCP? Или Network Streams требует обязательного использования клиента-сервера, реализованного именно с этой технологией и только в LabVIEW? Network Streams - это какой-то стандартизованный подход к передачи данных или чисто LabVIEW-шная фишка?
http://www.ni.com/white-paper/12079/en/ - тут смотрел про Network Streams в своё время. Не стал использовать по причине "Supported Configurations: 1:1". Ну и я не был уверен, что у меня Network Streams будет работать с сторонним TCP/IP - сервером(который, кстати, менялся раза 3 уже).

[dadreamer]

Vitekkz88, это проприетарный механизм NI, и к сожалению, со сторонними серверами он работать не будет. По вашей ссылке в табличке написано: "Type - LabVIEW Feature", "3rd Party APIs? - Not at this time", то есть, это фишка и пока что нет открытого API для использования NS в сторонних проектах. Это существенный минус этой технологии. Однако на NI'шных контроллерах и на поддерживаемых платформах должно работать нормально, как и заявлено.

[Vitekkz88]

dadreamer, да вот я как раз года полтора назад и смотрел эту ссылку(а она опубликована в 2013 году). Может что поменялось с тех пор, 2 года прошло. А технология, по-моему в LV2010 появилась.
Счастливые люди, которые работают исключительно в рамках LabVIEW...

[Borjomy_1]

Правильнее рвать соединение по ошибке 56. Для того, чтобы таймаута не возникало, следование посылок должно быть регулярным. Если вас это не устраивает, то можно принять, что с одного IP может существовать не более одного соединения. В этом случае, если возникает новое соединение, то предыдущее автоматически рвется (и клон завершает работу).
Либо организовать клон не по соединению, а по IP удаленного хоста. И передавать ему новый коннект. Старый он должен автоматически закрывать сам.

[Artem.spb]

Про пинги и "пустые" пакеты думал, но надеялся, что есть методы прямее.
Вопрос конечно же не в выдёргивании кабеля из этого компа, а в возможных сбоях на всей линии.
Про NS надо посмотреть, спасибо, хотя сейчас уже не буду переделывать проект, учту на будущее.

[AlexanderKonoval]

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

[Vitekkz88]

Artem.spb писал(а):Про пинги и "пустые" пакеты думал, но надеялся, что есть методы прямее.

Если есть возможность - то добавьте echo-команду на стороне клиента и сервера. Это абсолютно нормальная практика при работе по TCP/IP. Можете эту команду по отдельному порту гонять, сеть от этого не нагрузится. Всё будет приходить без проблем, TCP/IP - это протокол с гарантированной доставкой данных.
Я однажды сам столкнулся с подобной проблемой, но у меня не было возможности править сервер(он был на Си запилен), echo-команд не было предусмотрено(оно и не мудрено, в Си можно сокет открывать с спец.дискриптором, который заботится о keep alive-пакетах. В LabVIEW-шной реализации TCP/IP такой педали нет, поэтому её надо самому прикручивать и на своей стороне и на стороне сервера.). Не имея возможности добавить echo, я использовал одну из "нейтральных" команд...каждую секунду по отдельному порту запрашивал версию ПО. А ошибку таймаута я обрабатывал только на этапе установки соединения, а далее по любой ошибке на стороне TCP/IP я пробовал вначале сделать реконнект. Если не удавалось переподключиться - приложение закрывалось.

[Borjomy_1]

Сервер, который у вас на хосте - пассивное устройство. Никого пинговать он не должен! Зачем вешать на него чуждый ему функционал??? Мало того, доп соединение тоже надо контролировать. А если там будет потеря связи, а в это время приходит пакет? Терять пакет? И долго думать, как решать возможные конфликты состояний. Самое простое и самое правильное- это то, что контролировать соединение должен контроллер. Сервер при ошибке рвет соединение. Также принять правило - один ip - одно соединение. Установите время жизни соединения, при превышении которого задача останавливается на стороне сервера.

[Vitekkz88]

Сервер, который у вас на хосте - пассивное устройство. Никого пинговать он не должен!

А кто сказал, что на стороне сервера будет ping? (если он вообще будет) На стороне клиента(контроллера) разумеется. А сервер живёт своей жизнью и просто ждёт, когда к нему кто-то подцепится.
Какое доп.соединение? Какие конфликты состояний? Borjomy_1, Вы про что?

принять правило - один ip - одно соединение.

Открывать несколько портов на одном соединении - нормальная практика. Или что-то другое имелось ввиду, простите за недопонимание? Один порт на данные, второй на обмен командами, третий для служебных целей, четвертый - связь с сторонним сервером и т.д. А ошибку тайм-аута следует обрабатывать на этапе установки соединения и всё. Далее, как уже писал, эта ошибка общего характера и конкретики она не даст.
Артём, заводите echo-пакет, который будет туда-сюда гоняться раз в секунду. Тайм-аут на ожидание отправки/получения пакета ставьте 3 секунды например(или сами прикиньте время ожидания). Если команда отправилась нормально(на клиентской стороне вы не получили ошибки после вызова функции записи в порт), то далее переходите в состояние ожидания ответа(подтверждения). Если ответ не пришел - считаете, что на стороне сервера произошел сбой отправки.Одновременно с этим анализируете, что не так с сервером(или он не смог принять пакет или он не смог отправить пакет). Думаю, Вы понимаете о чем речь - всё логично. Конечно, возможна и такая ситуация: клиент отправил -> сервер получил -> сервер отправил -> "ошибка" -> клиент не получил. Вот какая именно "ошибка" установить однозначно не удастся. Или это кабель барахлит или это сетевая карта сгорела или это что-то еще произошло...Получите просто таймаут на ожидание данных. Чтобы определить конкретней(кабель порвался или сеть просто глючит) - добавляется логика на проверку ping-а или состояния сетевой карты( на стороне клиента разумеется). Если пигн есть(а значит сетевая карта живая) - пробуете вновь отправить echo-пакет. Если клиент опять ничего не получает - то надо проверять как работает сервер. На сервер обычно добавляют еще логгирование, типа: "Принял пакет, отправил ответ", либо "Ошибка ожидания пакет", "Принял - не смог ответить" и т.д. Тогда получится полноценный обработчик и логгер ошибок. Так же следует учитывать, что сервер может быть просто обесточен. Но тогда у Вас будут ошибки в отправке, а ping не пройдет. Либо Вы не сможете подключиться на этапе открытия соединения(TCP Open). Тогда у Вас будет ошибка типа: "Превышено время ожидания соединения. Повторить?" и т.д.

[IvanLis]

Artem.spb, а какая скорость обмена Клиент<->Сервер?
Может проще сделать небольшую надстройку над UDP (подтверждение о доставке и целостности пакета).
В принципе получим некий гибрид TCP-UDP, без установления связи, но с гарантированной доставкой.
Для определения очередности пакетов, если интересует, можно дополнительно передавать метку времени. Причем при перезапросе (отсутствии подтверждения) пакет передается с прежней временной меткой для сохранения очередности (мало вероятно, вдруг между ними что-то было отправлено).

[Borjomy_1]

Открывать несколько портов на одном соединении - нормальная практика.

Я имею в виду, что со стороны сервера по определенному порту в одно время может существовать только одно соединение с определенным контроллером (уникальный IP адрес). Я не понимаю, зачем усложнения со стороны контроллера? Пинг какой-то. Если таймаут при отправке пакета, то что тут пинг сделает? НИЧЕГО. Он не предотвращает потерю соединения, он не может его восстановить. Ну продетектируется проблема на 1 сек раньше. И что? Если топикстартер не хочет терять информацию из-за сбоя, то данные на стороне контроллера надо хранить в очереди. В случае неудачи передачи пакета, его данные запихиваются обратно в очередь, а программа пытается восстановить связь.

[Vitekkz88]

Я не понимаю, зачем усложнения со стороны контроллера? Пинг какой-то.Ну продетектируется проблема на 1 сек раньше. И что?

Borjomy_1, а что Вы предлагаете? Как узнать, что пользователь или оператор отключил кабель из сетевой карты?Как узнать, что сервер перестал отвечать на запросы? Таймаут сгенерить и успокоиться? Сделать реконект и выжидать N секунд?Опять получить ошибку таймаута и начать думать "А что же там могло произойти???".
Только давайте без фантазий " а если сеть не настроена, а если магнитные бури, а если земля налетит на небесную ось" и т.д. Допускаем: связь установилась, клиент и сервер начали успешно обмениваться данными. В некоторый момент сработал таймаут(причина - обрыв кабеля. Возможная ситуация? Вполне!). Дальнейшие действия?