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

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

код клиента выполняет следующее:
1. выделение памяти у ОС в boost::shared_array.
2. сериализация.
3. копирование в shared_array.
4. boost::asio::async_write().
5. tcpdump показывает что данные ушли.
6. на приеме данные искажены.

лог tcpdump`a для пояснения формирования непонятных "фреймов":
строки сериализации содержащие подстроки servimpl - это то, что отправляется от клиента серверу.
строки сериализации содержащие подстроки type1 - это то, что отправляется от сервера клиенту.

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

далее...
в точке 3 происходит разбиение очередного архива, остальная часть которого появляется только в точке 5.
т.е. это именно та итерация(348), на которой происходит искажение архива, и как следствие - ошибка десериализации.


далее...
в точке 4 должен находится остаток архива разбитого в точке 3.


вот та часть, в которой появляется остаток от архива разбитого в точке 3.


какие мысли?

Это сообщение отредактировал(а) boostcoder - 8.4.2011, 00:57

Где код?

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

Добавлено через 1 минуту и 35 секунд
я рассчитывал на то, что кто-то увидит знакомую ситуацию, и подскажет как решить.

зы
кстати, если между отправками данных поставить sleep на 1мс - то проблема решается полностью.

кто-то знает кто может добавлять к моим данным нечитаемые данные и разбивать их на фреймы? это выполняет TCP стек? сетевая подсистема? просто не знаю как это называется...

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

прикладываю мегапростой пример воспроизводящий ошибку.


Присоединённый файл ( Кол-во скачиваний: 11 )
 asiotest.zip 2,75 Kb

фрагментация осуществляется на сетевом уровне
к данным "мусор" добавляться не может

вы точно уверены, что в сокет все записывается правильно?
вы сравнивали, что передается в async_write() и в send()?

boostcoder, данные скорее всего искажены именно от отправителя.
На первый взгляд, именно так. копать... 
Если дальше копать то послушайте трафик wireshark, и выложите сюда. ну может конечно кто то и tcp дамп почитать смоежт я как то не.

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

тот мусор что на скринах, показывает tcpdump. в мой код этот мусор не поступает.


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


нет. а как это сделать? добавить в недры asio вывод?
или есть какой-то еще способ?


сейчас сделаю.


эм.. помогает задержка при записи, а не при чтении.


я проверял не только на линукс...

клиентский код запускаю на: 2.6.35-28-generic-pae
код сервера на: 2.6.35-25-generic-pae

логи.
сделал wireshark`ом на локальной стороне.
на сервере нет X`ов, я хз как там wireshark запускать.

зы
по логам, ничего не понял...


Присоединённый файл ( Кол-во скачиваний: 5 )
 logs.zip 76,38 Kb

заново протестил еще раз на winXP/Win7/Linux.
баг воспроизводится всегда :(
тестил так:

в этом большая ошибка
я много раз на это же полагался
а в итоге как раз в мегапростом коде и был баг ;)



написать враперы над send/recv/... из Libc
насколько я знаю, достаточно создать что-то типа wrappers.c, там реализовать обертки
вот реальный код подмены fork из какого-то проекта...


Добавлено через 3 минуты и 2 секунды

в таком случае я уверен на 99% баг где-то в коде
думаю в вашем, а не asio

Почитал я код и у меня возникло подозрение, что async_test() и asio в клиенте работают в разных потоках. А shared_array (как и shared_ptr) не может корректно передаваться между потоками (по крайней мере я пару месяцев назад не нашел такого способа).
Те когда выполняется код:

в отмеченных местах возникает состояние гонки, а так-же в функции start_write в вызове boost::bind происходят изменения в счетчике ссылок shared_array и последний ломается. Если не повезет один из деструкторов shared_array может убить данные раньше чем обновятся данные счетчика ссылок.

В свое время пару месяцев назад я напоролся на точно такой-же баг, но только с shared_ptr, через который между потоками передавался вектор. Весь процесс передачи был обернут мутексами, кроме участков, где возможно удаление временных объектов shared_ptr (а они возникали так как данные передавались через std::queue), но программа всеравно падала где-то в недрах asio. А иногда не падала, а что-то передавала.
И что самое паршивое в GCC все работало. А в Intel C++ падало или не падало. Зависело это от фазы луны, загрузки процессора и т. д.

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

Потокобезопасность shared_ptr описана здесь: http://www.boost.org/doc/libs/1_46_1/libs/...tm#ThreadSafety (Example 3 описывает возникшую ситуацию).

перевариваю...

Добавлено через 41 секунду
а по этой проблеме, которая у вас возникла, вы где-то на форуме тему создавали? хотелось бы почитать.

Нет, не создавал. Что-бы создать тему нужна была хоть какая-либо детализация проблемы, а у меня даже segmentation fault в разных местах всплывали. Я неделю думал, что на какой-то хитрый баг либо в asio либо в intel С++ наткнулся. Потом начал искать все места, который потенциально перераспределяли память и где рядом был обмен данными между потоками. С 3-й попытки заменил нужный shared_ptr на обычный ptr и ручное управление памятью и проблема ушла полностью.