Таймаут в блокирующих сокетах

[3D Hunter]

Здравствуйте еще раз. Такой вопрос по компоненту TCPServer в режиме bmThreadBlocking. Функции отправки/приема данных синхронные. Т.е. если я вызываю в сокетном потоке ClientSocket.ReceiveLn;, то код не выполнится, пока в сокете не будут обнаружены данные.

Вопрос: как ограничить время ожидания приема/отправки данных? Т.е. к примеру, если втечение 110мс данные не приходят, то код выполняется дальше. Были задумки по поводу функций опроса сокета ClientSocket.WaitForData и ClientSocket.Select. Но они, как я понял, только для неблокирующих сокетов. Или я ошибаюсь??? Если вы сталкивался с подобным или знаете решение, буду очень благодарен.

В знак благодарности выложу пример сервера в многопоточном режиме, построенном на этом компоненте. Код весь отрабатываетс стабильно, но вот с таймаутом пока никак.

P.S. не предлагать использовать Indy или Synapse. В них то таймаут есть, но хочется на основе родных классов, ради принципа.

Заранее спасибо.

Тогда еще вопрос: winsock-функция recv сама по себе блокирующая? Т.е. вызвав, ее, поток остановится? Есть догадки, что recv не вернет управление, пока не поступят данные в сокет и не будут считаны.

[theYozh]

Сообщение от 3D Hunter

Тогда еще вопрос: winsock-функция recv сама по себе блокирующая? Т.е. вызвав, ее, поток остановится? Есть догадки, что recv не вернет управление, пока не поступят данные в сокет и не будут считаны.

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

PS но на время выполнения функции recv поток естественно будет передавать управление ей.

[3D Hunter]

Спасибо за ответ! Тогда выход один - надо однозначно тестировать парсер на реальном оборудовании.

З.Ы. Да, сервер многопоточный, на блок. сокетах.

З.З.Ы. Как оттестирую парсер и все будет ок, выложу сюда исходный код. Если не забуду конечно. Кому будет нужно, пишите в личку, чтоб наверняка

[3D Hunter]

Ну вот, вчера успешно оттестировал парсер на реальных устройствах. Все работает, но есть одна неприятная особенность: при отключении устройства из списка программа ожидает приема следующего пакета и только после получения делает дисконнект. Т.е. recv все-таки может выполняться долго. Читал, что она может вернуть ноль, т.е. данных не пришло за определенный промежуток времени. Тогда вопрос: могу ли я сам определить для нее промежуток времени опроса?
Или я говорю ерунду и это заложено в самом винсоке? Спасибо

[3D Hunter]

А скажите, на чем лучше реализовывать tcp-server - на Synapse или на Indy? В сунапсе свои библиотеки сокетов, от винсока он зависит косвенно ии вообще не зависит, насколько я понял.

[3D Hunter]

Вот знаете, пришел к выводу, что либо тут все молчат от незнания, либо от великого ума, которого хватает, чтобы тем (не)знанием ни с кем не делиться. А может сокеты сейчас хлебное занятие, и поэтому все молчат, дабы кусок не перепал другому? А может с ними вообще никто не работает? Однако любят тут поститься в ламерские темы, отвечая на вопросы "а как загрузить длл", "как работать с указателями", "как программно создать кнопку" наконец. Ответов там пруд пруди. Во любители флудить! Я понимаю, что мне никто не обязан, но неужели никто не может ответить на несложный вопрос, разъяснив причины задержек recv'a send'a?
Тьфу, аж на душе противно. Ладно, уже неважно. Никого не хотел обидеть, говорил в общем. В любом случае тема закрыта.