UNIX, sockets, загадочный баг.
Легко.
Например, он может (по умолчанию!) думать, что ты слишком уж
полюбил это место, а потому надо бы тебе соединения пообрывать.
---
"Narrowness of experience leads to narrowness of imagination."
RTFM говорит, что всё хорошо.
RETURN VALUE
These calls return the number of bytes received, or -1 if an error occurred. The return value will be 0 when the peer has
performed an orderly shutdown.
, так что может есть pcap дампы, код и инфа по сокетамв ту же кучу: логи с клиента и сервера, выстроенные в правильной временной последовательности
то есть, например, возвращает ли клиентский read 0 раньше, чем завершается select на сервере или позже
Серверная фигня успешно делает accept, форкаетсяэто тоже 10^4 раз в секунду?
приблизительно раз в 10000 запросов != 10000 запросов в секунду
Оставить комментарий
bleyman
Есть кривая фигня, общающаяся с другой кривой фигнёй посредством интернетных (не AF_UNIX) сокетов. И иногда, приблизительно раз в 10000 запросов, их общение не складывается.Серверная фигня успешно делает accept, форкается, отец закрывает session_socket, сын закрывает listen_socket и делает на session_socket select, передавая сокет только первым fd_set'ом, который про чтение. И этот селект таймаутится (700мс, тогда как в типичном случае select возвращается сразу). То есть возвращает 0, ну и по времени в логах видно, что вот, таймаутнулось.
Клиент соответственно делает connect, send, recv и всё проходит успешно, но recv возвращает 0. send обёрнута в специальную функцию, которая проверяет возвращаемое значение и даже умеет допосылать остаток буфера, передаваемая длина буфера точно-точно строго больше нуля етс, то есть вроде мой код корректный.
Никто не сталкивался с подобной загадочной мистикой? Я уж даже не знаю, что и думать, может у чуваков там какой-нибудь фаервол хитрый...