всем доброго дня.

в asio, синхронные read()/write() продолжаются вечно, пока не будет прочитано/записано требуемое кол-во байт.

мне требуется блокирующие чтение/запись с таймаутом.
в экзамплах asio есть примеры реализации такого поведения:
1. blocking_tcp_client.
2. blocking_udp_client.

но они не подходят потому, что для блокировки вызывающего потока используют метод io_service::run_one().
у такой реализации особенность в том, что для того чтоб она работала, нужен отдельный io_service на каждую такую реализацию. а это не хорошо..

вопрос в том, каким образом реализовать блокирующие чтение/запись, имея один io_service и множество сокетов?
при этом, хотелось бы иметь возможность использовать все это дело И с обычными асинхронными чтением/записью.

спасибо.


Это сообщение отредактировал(а) boostcoder - 29.5.2011, 07:08

Буду краток:
1) SO_RCVTIMEO/SO_SNDTIMEO (совместно с socket::native()) или
2) deadline_timer
Но в обоих случаях - ничего кроме как закрыть сокет вы не сможете. Для асинхронных операций на Windows Vista+ вроде бы должен сносно работать метод socket::cancel(), но вот беда - asio при сборке старается угодить всем и работает даже под Vista так как будто работа ведется под Windows XP - т.е. что-то там "мудрит" с cancel и потоками.
Я рекомендую никогда не использовать cancel() - только close() одинаково поддерживают все платформы. И вина тут в общем-то не asio, а WinSock или даже Berkley Sockets.
Про SO_RCVTIMEO/SO_SNDTIMEO рекомендую почитать MSDN. Гугл говорит, что "MSDN говорит", что состояние сокета после такого таймаута не определено и безопасно он может быть только закрыт.

mabrarov, спасибо.
немного расстроился.. :(
буду думать...

Да что тут расстраиваться.. это же логично - после отмены хз, что там принялось/отправилось, а что нет.
А во-вторых IMHO, синхронные операции ввода/вывода (особенно в сети) must die. Многие (C#, Apache MINA, Twisted), только сейчас начинают это понимать. И еще, не забывайте, что если socket-layer сказал вам "я все отправил" - это вовсе не означает, что он что-то там вообще отправил (есть буфер отправки). И уж тем более не означает, что что-то дошло до другого конца. Читайте Йона Снейдера "Эффективное программирование TCP-IP" - вот там все мифы очень четко рассеиваются и логично объясняется работа сокетов без излишних подробностей работы TCP/UDP. 

не удержался: 

  

  

нужно тоже самое. Но у меня есть возможность создавать на каждый сокет свой  io_service, но я фигею от логики deadline_timer. И везде где я видел в случае если тайпер истекает закрывается сокет, но зачем ??? я даже боюсь представить что для того что бы операция чтения которая весит где "там" вернула управление.

Надеюсь это не так, и после истечения таймера можно на том же сокете вызвать еще раз операцию получения данных ?

не понял предложения.

Под юниксами я бы посоветовал использовать обёртку над неблокирующим сокетом и единичным poll(). Вполне делается полная имитацыя read/write с таймаутом.

Я бы делала с помощью select. Открывала дескриптор,  клала его в пул селекта и вызывала select с нужным таймаутом. Но вообще это часть реализации асинхронного взаимодействия, не понимаю, зачем этим пользоваться непосредственно.

Добавлено через 37 секунд
Ну да, poll уже посоветовали 

при истечении таймера сокет закрывается. Но зачем ? Ответ вероятно что для того что бы прервать блокирующую операцию чтения. Но это же о плохо. 


надо кроссплаптформенно


Хм... я почему то был уверен что сама операция read умеет с timeout работать... Видать напутал. 

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

По логике если я не получу нужный мне мессадж, то далее сокет открытым держать нет смысла. Поэтому и deadlite_timer сойдет.

select как раз относительно кроссплатформенен. POSIX.1-2001 + 4.4BSD + винда.

Странно, что такого функционала не предоставляет используемая тобой библиотека асинхронных сокетов.

ну так закрывай его. он же асинхронный.

хехе, ну так я и использую asio который это делает через deadline_timer который может прервать операцию чтения только закрыв сокет, что мне изначаьлно и не особо понравилось.


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

cupper, так ###! есть же cancel().
мне такое решение не подходило, ибо использовался блокирующий ввод-вывод.