Зависание в boost asio на операции чтения из сокета

Так вот, периодически (очень редко) происходит зависание в socket_.receive() на клиенте. ЧЯДНТ?

Кэп подсказывает, что сервер нифига не посылает.

Посылает. Но netstat -t показывает дофигищу сокетов в TIME_WAIT.
ulimit -a показывает:

core file size          (blocks, -c) 0
data seg size           (kbytes, -d) unlimited
scheduling priority             (-e) 0
file size               (blocks, -f) unlimited
pending signals                 (-i) 13971
max locked memory       (kbytes, -l) 64
max memory size         (kbytes, -m) unlimited
open files                      (-n) 1024
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) 819200
real-time priority              (-r) 0
stack size              (kbytes, -s) 8192
cpu time               (seconds, -t) unlimited
max user processes              (-u) 1024
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited

Читал (в т.ч. в доках к libev/libevent) что бывает прилетают фантомные события на чтения. Короче, выставь на сокеты асинхронный режим.

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

Так же посмотри dmesg, там бывают весёлые сообщения от фаервола типа упёрлось всё в кое-какие лимиты.

Если клиент повисает то значит до него данные не доходят. Это, кстати, дебажится tcpdump.

а что boost::asio::async_write( socket_, ... ) возвращает? в смысле, нет ли ошибки?

может у тебя банально тырнет отваливается. или что-то там у тебя за сеть.

Попробуй сделать strace, чтобы посмотреть, в asio проблема, или нет.

Асинхронный режим стоит. Но есть N потоков в каждом из которых запущен io_service.run()

если там aio то как оно может подвисать? Странно это...

Ошибки на записи нет (в евент хендлере). Есть зависание при чтении из сокета у клиента.
все происходит на локалхосте.

Так вот, периодически (очень редко) происходит зависание в socket_.receive() на клиенте. ЧЯДНТ?

ссылка на вражий msdn, но там вроде толково все расписано:

http://msdn.microsoft.com/en-us/library/windows/desktop/ms738547(v=vs.85).aspx

с asio не работал, потому не знаю насколько актуально

The only working way to do that (that I have found) is to:

prevent accept() from adding more clients

have a list of the open sockets somewhere and to wait until they are all properly closed which means:

using shutdown() to tell the client that you will no longer work on that socket

call read() for a while to make sure that all the client has sent in the meantime has been pulled

then using close() to free each client socket.

THEN, you can safely close() the listening socket.

альтернативная версия, у меня так и сделано, но без asio, подвисаний нет, тестировал через apache benchmark

вот кстати мой исходник:
https://github.com/abudnik/PythonServer/blob/master/PythonServer.cpp
там можно проект собрать и затестить скриптом из test/sendscript/send.py

Какие нах асинхронные режимы, если речь про синхронное чтение?

Автор, повторяю, сделай strace, там будет видно, что происходит. Там будет recv или read, увидишь, пришли ли данные, или же нет. То есть увидишь, где проблема - в asio и твоем коде, или нет.

p.s. code review:

boost::asio::async_write( socket_, boost::asio::buffer( ss2.str() ),

std::string s("abc");
boost::asio::const_buffers_1 buf = boost::asio::buffer(s);
s[1] = 'w';
const void* p = boost::asio::buffer_cast<const void*>(buf); 
std::cout << static_cast<const char*>(p) << std::endl;

С ужасом для себя увидел: «awc»

Логично, asio буфер - это просто пара указатель + размер. Если бы он копировал, это было бы малопригодно для серьезного применения.

Нашел истинную причину зависания. Там реально нетривиальная трабла с асинхронным i/o.
Могу рассказать подробнее.

Давай, чё.

у меня там 2 процесса общаются через сокет.
первый процесс кидает в сокет реквест, потом ждет респонса от второго.
Проблема в том, что я инициировал асинхронную операцию записи в сокет, а только затем чтения. Так вот, второй процесс может респонс отослать быстрее чем первый закинет асинхронную операцию чтения этого респонса.
А буст то ли выкидывает, то ли игнорит не зарегестрированные евенты в еполле. Поэтому когда в еполле регеца этот эвент, то уже поздно.
Реализация с синхронной записью, затем синхронным чтением на сокете, который сконструирован с параметром io_service та же самая беда, причем разруливается она переходом на асинхр. операции i/o и правильной последовательностью регистрации этих евентов в бусте.
Хз, писать чувакам из boost.org, или нет...

Пиши, но сначала попробуй до минимального примера сократить.

Вот синхронный пример, передающий туда-сюда строчку, клиент посылает запрос, затем спит секунду, а затем читает ответ. Работает, как часы.

https://gist.github.com/4665157

С асинхронным чтением, заряженным, уже когда сервер давно сдох, тоже все ОК:

https://gist.github.com/4665257

Короче говоря, мне кажется, что косяк всё-таки где-то у тебя, или буст очень старый, там в asio было довольно-таки много проблем.

по сравнению с твоим примером у меня сервер асинхронно читает/пишет (но это скорее всего и не важно), а клиент - многопоточный, т.е. у меня несколько потоков, которые выполняют io_service.run()
Буду писать простой пример, чтобы бага воспроизводилась и слать репорт. Проверял только в boost 1.48.

1.48 как раз весьма корявый, под MacOS нам пришлось его не юзать.

А что в плане asio фонтан? А то у нас юзается 1.49 под Win- пока вроде норм, но хотелось бы услышать success/fail stories.

Да можно в трекере посмотреть (который, похоже, лежит...)

С 1.51 и 1.52 проблем вроде не было, до этого долго на 1.47 сидели. Соседний отдел весьма высоконагруженный сервак с 1.49 сейчас собирают.

По поводу винды - не скажу, только под linux/*bsd/solaris/macos используем.

они еще boost::property_tree::read_json/write_json не осилили сделать thread-safe... /0

Ему и не нужно быть thread-safe. Как и, например, std::vector'у.

Столкнулся с этой проблемой, хотелось бы узнать чем закончилась эта история, решилась ли проблема в новых версиях буста?

Были запущены 2 процесса на локалхосте, один - в роли сервера, второй - клиент. Клиент инициировал соединение с сервером. Сценарий работы был следующий: клиент писал в сокет асинхронно, а затем читал респонс синхронно. На чтении периодически всё подвисало потому что не приходил респонс, хотя сервер его отсылал (по логам видно).
Решил избавиться от постоянного создания соединения между клиентом и сервером. Решил просто использовать пул соединений, т.е. коннектился к серверу заранее и держал соединения до завершения работы клиента. Помогло. Всё работает на линуксах и бсд норм.
«клиент»: https://github.com/abudnik/prun/blob/master/src/worker/worker.cpp
«сервер»: https://github.com/abudnik/prun/blob/master/src/worker/exec.cpp
Предположительно проблема была в том, что когда сервер отсылал респонс (а точнее приходило событие об успешном копировании отсылаемого сообщения в буферы ядра), он тут же разрывал соединение (закрывал сокет) по своей инициативе, хотя это должен был делать сам инициатор (клиент). Клиент мог регестрировать событие на чтение в epoll уже когда сокет был закрыт сервером, поэтому (?) респонсы не доходили.

в начале теме была вроде речь об //async_read_some но, раз проблема была в синхронной задержке то это всё объясняет