boost::asio пропадают пакеты

Возможные причины:

memcpy(d, &data_, bytes_transferred) 

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

Вообше, для реализации проверки приема полного пакета лучше использовать async_read_until.

tcpdump работает с сетевухой в promiscuous режиме (xто на интерфейс физически попало, то он и показывает). Если tcpdump не показывает часть пакетов, то они просто не дошли.

Спасибо! У меня есть такой же сервер на чистом epoll на нем все доходит, но тоже есть такие проблемы, но они появляются раз в неделю. Вроде все сделал как в примерах...

Спасибо, сегодня попробую

Это значит ты где-то не вычитываешь буфера, хотя должен. Позырь в нетстат, на Recv-Q

http://pastebin.com/1bYUBdUN вот так у меня, когда не доходят пакеты

У меня есть такой же сервер на epoll и на нем по истечении трех дней примерно происходит следущее, приходят пакеты от 2 - 3 клиентов хотя должно приходить от 30 - я уверен в этом! после ребута процесса все нормально, а ингода приходится ждать пока закроются все коннекты и только после закрития все соединение работа восстановливается, (причем я юзаю REUSE_ADDR, несмотря на это)

Главный то есть слушающий сокет работает так: ev.events = EPOLLIN | EPOLLET; и если на нем события то делаю accept до тех пор пока не вернятся EAGAIN

Коннекты так: ev.events = EPOLLIN | EPOLLET;

и делаю recv до EAGAIN

Считывать до EAGAIN - это как я понял обязательное условие, правильно?

Может моя проблема в том что на либой пакет от коннекта я должен отослать ответ и я делаю просто send(4 байта ) после recv? Может быть нужно сделать EPOLL_CTL_MOD c EPOLLIN | EPOLLET на EPOLLOUT | EPOLLET, на клиентских сокетах?

Убери EPOLLET

Т.е. я конечно не хочу сказать, что ты не правильно работаешь с ET, но проверить было бы неплохо )

Да без epollet тоже самое , я уже проверял

Что я могу предоставить когда произойдет такая проблема, strace висит на epoll_wait в netstat порядка 12 коннектов - как и при нормальной работе , сопаставлял время tcpdump прихода пакета и возврат из epoll_wait - все совпадает, есть аналогичный сервер только для двух клиентов на другом порту там все отлично в тот момент когда не доходят пакеты

Может быть что то с моими глобальными параметрами tcp и сети?

Маловероятно. Скорее всего сбой в протоколе. Быстрее всего диагностировать с обоих сторон

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

Или может быть, хоть в смане написано что достачно close сделать для закрытия, все таки стоит делать EPOLL_CTL_DEL , потому что у меня сейчас просто close для закрытия

А буст копирует твой буфер который ты на стеке задал?

boost::asio::async_write(socket_, boost::asio::buffer(packetAnswer, 4), boost::bind(&session::handle_write, this, boost::asio::placeholders::error))

не охото смотреть, но думаю в нормальной сетевой либе boost::asio::buffer - обертка над указателем и его длинной. Когда ты стартуешь операцию, тк движек асинхронный, то она ставится в очередь и ты выходишь из handle_read удаляя стековую переменную packetAnswer. на следующей операции io_service идет чтение в несуществующий буфер на 4 байта.

Как вариант, не охото смотреть буст :D

Так же строка 31 Packet pack; Не видно контекста использования : Server->onConnect(&pack, &socketMy); и int dataCount = Server->onData(&pack, &socketMy);

http://www.boost.org/doc/libs/1_50_0/doc/html/boost_asio/tutorial/tutdaytime3.html Строка:

message_ = make_daytime_string();

Ты же на стеке создал :

Packet pack;
BYTE packetAnswer[1];
char packetAnswer[4];

Спасибо! сделал PacketAnswer членом класса, но все равно тоже самое