Потеря соединения TCP

[PaXXaN]

Доброе время суток!
Подскажите, при открытом сокете (через TCP Open Connection) и отсутствии входных данных как можно определить, что устройство на том конце отключилось?

[Eugen Graf]

А может быть пингом, я думаю должно получится.

Примерно вот так (замени конечно localhost на адрес IP)

[PaXXaN]

А может быть пингом, я думаю должно получится.

Примерно вот так (замени конечно localhost на адрес IP)

Попробывал - вылазит окно дополнительное(что не желательно), и нужно же ещё анализировать возвращаемые ответы на +/-?
Хотелось бы всё осуществлять внутри программы...

[Eugen Graf]

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

[PaXXaN]

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

А вот это отличная идея! Сервер как раз там имеется...
Получается, можно по 1 сокету общаться, а по второму (событие тайм аут задействовать) - закрывать и открывать соединение. Если всё в норме - значит устройство ещё на проводе. А вот время, через которое это следует проделывать, насколько маленьким может быть? У меня щас стоит 50 мс. Нормальное?

[Eugen Graf]

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

[PaXXaN]

да уж... ставлю 10с - и то вылетает ошибка ожидания.

А эту проверку лучше где разместить: в тайм ауте или какомнть параллельном потоке?

[Eugen Graf]

Чтобы ответить мне нужно знать для чего это всё, если прибор не посылает данные, то видимо ты хочешь посылать данные? Или просто хочешь знать есть прибор в сети или его нет?

Если ты всё же посылаешь прибору какие то данные, то ведь при отсылке данных тоже есть таймаут.

[PaXXaN]

Чтобы ответить мне нужно знать для чего это всё, если прибор не посылает данные, то видимо ты хочешь посылать данные? Или просто хочешь знать есть прибор в сети или его нет?

Если ты всё же посылаешь прибору какие то данные, то ведь при отсылке данных тоже есть таймаут.

Это всё тот же EM-1000. Я туда загружаю пачку команд. Она начинает выполняться и по мере выполнения, на ПК должны отсылаться пакеты результатов работы. На ПК они разбираются и в соответствии с полученными данными или продолжается ожидание (предварительно изменив счетчики и отобразив принятие предыдущего ответа), или же завершается ожидание и проделываются финальные операции.

[Eugen Graf]

Хм, а ты не можешь отсылать одну команду, дождаться выполнения и ответа, а потом отсылать следующую. Тогда ты всегда будешь в курсе выполнения и не будешь парится по поводу присутствия прибора в сети.

[PaXXaN]

Хм, а ты не можешь отсылать одну команду, дождаться выполнения и ответа, а потом отсылать следующую. Тогда ты всегда будешь в курсе выполнения и не будешь парится по поводу присутствия прибора в сети.

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