Определить дисконнект сервера по TCP

[Mifodiy1977]

Здравствуйте. Нужно как-то определить дисконнект сервера. В моем случае сервер - это Ethernet-RS-485 шлюз ICP-DAS I-7540D. Ну, это не только указанный шлюз, еще и Can и RS-232, но в данном случае использую как шлюз 485 шины. Так вот, проблема в том, что я не должен делать заново соединение только потому, что после запроса, посланного через этот шлюз (в порт 10002 - это порт 485 шины) на шину 485 обратно не приходит никакого ответа. Это еще не означает, что нет связи со шлюзом, может просто не быть активных узлов на 485 шине. Есть известный мне способ определить дисконнект со шлюзом - по ошибке в процедуре записи в порт TCP. Небольшая проблема заключается в том, что эта ошибка возникает лишь спустя 20 секунд после физического отключения шлюза от сети (я так понимаю - это время жизни пакета). А до этого пакеты отправляются как ни в чем ни бывало, даже не смотря на то, что time out на входе TCP write стоит 400 миллисекунд. Честно говоря, я не понимаю, на что влияет величина на этом входе.

Вопрос. Можно ли как-то побыстрее получить дисконнект? И вопрос. Нафига вход Time Out у TCP Write и на что он вообще влияет?

Заранее благодарен

[Mifodiy1977]

(я так понимаю - это время жизни пакета) - неправильно понял, просто время, за которое переполняется буфер TCP

[Borjomy_1]

А RS-232 идет другим портом? В смысле COM1 - на RS-485, а COM2 - на RS-232? Если так, то можно соединить Rx и Tx на порте RS-232. Тогда посылая туда периодически пакет, должны получать его обратно. Если ответа нет, то становится понятно, что модуль не подключен.

[Mifodiy1977]

RS-232 на первом порте, RS-485 - на втором, CAN - на третьем. Мысль интересная, но мне как-то не очень нравится. Вроде все верно, но порты-то разные, а фиг знает, может модуль по каким-то своим внутренним соображениям закроет порт 485, а 232 не закроет. Маловероятно, но кто его знает. Ладно, не критично. Пусть через переполнение буфера определяется. За совет спасибо.
Вообще проблема существует, много народу в инете на эту тему вопросы задает и чаще всего получает ответ "Никак". Проблема решается через какие-то хитрые функции протокола - использовать таймер keepalive (таймер поддержания канала во время отсутствия сетевой активности). Как его использовать в LabView, я не знаю, вероятно это свойство задается в момент создания соединения, но в LabView это свойство вряд ли доступно.

[Borjomy_1]

Тогда вешать на 485- устройство, которое там всегда будет сидеть. Но вообще - версия с RS-232 достаточно просто тестируется. Переполнение буфера гораздо более левая идея. Возникает вопрос: что будет с устройствами, когда они будут подключены в момент недостаточно переполненного буфера?

[Mifodiy1977]

Ничего особенного. ПЧ Веспер 8300 (который и есть в данном случае единственный узел в сети) просто заткнется от такого изобилия запросов (проверено) и будет молчать до реконнекта, очистки буфера и нового запроса. Но я решил сделать проще. Фиг с ним пусть рвется и устанавливается соединение хоть каждую секунду (когда нет ПЧ в сети), ничего ж шлюзу не сделается. Буду делать реконнект по любой ошибке чтения. Хорошо, что в этом шлюзе есть еще и 232 порт, а могло и не быть. Лучше не полагаться на частные случаи, по возможности.

[Mifodiy1977]

Вообще проект дурацкий. Понасовали мне оборудования разного. 23 подъемника с ПЧ Altivar71 от Шнайдера с управлением по CanOpen и датчиками абсолютного положения XCC от того же Шнайдера тоже с CanOpen шиной. Пять точечных подъемов с дискретным управлением, якобы с возможностью управления от компа, а на поверку все от 220 вольт, пришлось в ящики ставить свои дискретные модули от ICP-DAS ET-7052 и релюшки для развязки. Привод круга (сценического, отсюда ясно, что это театр) - ВЕСППЕР 8300 с управлением по 485 шине (преобразователь 485 шины в нем даже не был установлен субподрядчиком, пришлось покупать). Датчик положения круга - тот же XCC. Всем этим я управляю от одного компа. Can получаю через шлюз NET-CAN 110 от VS COM, 485 шину через I-7540D от ICP-DAS (в нем есть и CAN но очень ограниченный по скорости, поскольку внутри по сути шлюз ком порта на эзернете, к которому и подключен внутренний компик, из-за чего CAN шлюз физически не сможет пропустить даже 56 килобит Can трафика). Плюс всякая разветвиловка для Ethernet и Can. Начальник решил сэкономить на контроллерах (хотя признаться, я распределенное управление на контроллерах да еще и со скадой ниразу не делал)? и решил все управлять с одного компа с сенсорным дисплеем (типа круто рулить механизмами с сенсорного экрана). Вот я и получил этот чудо-зоопарк.
Канал управления для себя однозначно выбрал Ethernet, потому как считаю это направление универсальным, перспективным и не требующем специализированных плат в компьютере, что не накладывает никаких ограничений на форм-фактор компа и не требует никаких драйверов. Плюс возможность рулить всем оборудованием подключившись к любой точке сети, хоть по вай фай.
Сейчас прикручу управление кругом (дурацкий ВЕСПЕР, у него все управляющие команды пишутся во флэш, что ограничивает частоту подачи команд и задания на скорость, плюс время отклика на любой запрос не меньше 20 миллисекунд, ужас просто, не считая просто глюков), и займусь управлением по положению. Надо чтоб подъемники отрабатывали заданные положения, в идеале сцены (групповое перемещение). А еще кроме всего прочего предполагается дополнительный пульт с опосредованным управлением несколькими механизмами (круг, занавес) через основной пульт, опять же через Ethernet, куда же без него. В общем живу в коммандировках... А дома многие проблемы не решаются и не выявляются ввиду отсутствия объекта управления. Дом за 4000 километров. Вот такая фигня.
Извиняюсь за офтоп

[Borjomy_1]

Можно попробовать наладить удаленный доступ к компу через интернет. Тогда значительную часть работ можно провести удаленно

[Mifodiy1977]

Я бы не стал пытаться рулить сценической механикой удаленно :) Макет с альтиваром у меня теперь есть, но немаловажно живое оборудование. И повторюсь, дырка в интернет для такого объекта, как пульт управления сценической механикой, по-моему - вещь небезопасная. А прогу залить не проблема, посылаешь дистриб и всё. Уж пару человек, что смогут установить прогу с флешки я в театре найду. Кстати, интернет тут очень медленный, удаленное управление сделать в таком канале врядли удастся. А что вы имели ввиду? Может я неверно понял?

[Borjomy_1]

Я имел в виду программное обеспечение типа TeamViewer.

[Mifodiy1977]

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

[Borjomy_1]

Не, это естественно. Но вообще производить разработку ПО на работающем оборудовании ( с рабочего места или удаленно ) тоже не айс.

[mzu2006]

ПМСМ, один из самых простых способов определить наличие-отсутствие связи: подвесить своего клиента, который отвечал бы что-то осмысленное. Типа ICMP Ping, но нагруженного Вашей функциональностью.

[mzu2006]

ПМСМ, один из самых простых способов определить наличие-отсутствие связи: подвесить своего клиента, который отвечал бы что-то осмысленное. Типа ICMP Ping, но нагруженного Вашей функциональностью.