[asio::udp] Не кроссплатформенное поведение

[Andrey2008]

Да, в программах бывают ошибки. Да, в библиотеках тоже. Как читателю, хочется какой-то вывод из всего написанного. :)

[YoungSkipper]

Вывод — когда будите использовать asio::udp помните об этом. Какой еще вывод? Человек сэкономил время на ресерч — куда уж больше.

[prograholic]

Тогда уж, надо было баг-репорт отправить разработчикам asio, будет больше пользы от данной статьи

[YoungSkipper]

Мухи отдельно, котлеты отдельно — то что есть где-то багрепорт — не помешает в течении тех месяцев пока его будут чинить наткнуться на данный баг.

Не говоря о том, что вполне возможно данные баг уже описан и известен.
По примеру QT некоторые баги живут годами.

[prograholic]

Насчет мух и котлет я с вами согласен. Однако багрепорт позволит не потерять эту особенность и донести ее до разработчиков.

p.s. В багтрекере boost такой проблемы не нашел, если что могу помочь автору с оформлением тикета

[Cupper]

Вы уже помогли что не нашли ее в багтрекере :) Баг обязательно зарепортаю. Я просто до сих пор терзаюсь сомнения что я где то облажался, потому что проблема таки серьезная. Как будто никто раньше и не юзал asio для udp.

[Cupper]

увы мне его тоже хочется, но для себя я пока не нашел способа, и просто оборачиваю эту конструкцию в try/catch и в catch ничего не делаю. Подумал что вынеся проблему на общественное обозрение будет больше шансов обмозговать и решить ее.

[pravic]

Зачем try/catch, а не передача фейкового error_code? Исключения не бесплатны же.

[Cupper]

Да, так верно лучше. Еще нужно глянуть можно ли это ошибку потом из er точно идентифицировать, что бы в функции обертки в случае этой ошибки глушить ее (подгоняем под Linux), а другие обрабатывать.

[ilynxy]

Возможно, в качестве временного решения, можно выделять буфер размером не меньше SO_MAX_MSG_SIZE. Я именно так и делал, поскольку в своё время тоже с удивлением не обнаружил прямого способа определить размер дейтаграммы для считывания.

[9mm]

С сокетами вообще разброд и шатание, по крайней мере под nix'ами и windows API заметно отличается.
Чего стоит только замечательная особенность winapi установить сокет как блокирующий и отсутствие возможности проверить блокирующий он или нет. Из-за этого нельзя полностью корректно реализовать метод isBlocking(), но, тем не менее, во всех библиотеках он реализован, просто может подкинуть несколько интересных сюрпризов под windows.

[mayorovp]

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

[9mm]

Чтобы совмещать код написанный разными людьми в разное время. Опять-же проверку на режим можно в assert запихнуть, для спокойствия.

[biorhitm]

Такая же фигня в исходниках, которые шли с AVR-студией. Долго не мог понять почему программа так хаотично падает. Оказалось, что функции чтения по барабану размер буфера, передаваемый мной. Просто копирует все данные, что есть в буфер.

uint16 recvfrom(SOCKET s, uint8 * buf, uint16 len, uint8 * addr, uint16 *port)
{
uint8 head[8];
uint16 data_len=0;

if ( len > 0 )
{
switch (IINCHIP_READ(Sn_MR(s)) & 0x07)
{
case Sn_MR_UDP:
wiz_read_buf(s, head, 0x08);
// read peer's IP address, port number.
addr[0] = head[0];
addr[1] = head[1];
addr[2] = head[2];
addr[3] = head[3];
*port = head[4];
*port = (*port

[biorhitm]

Самое важное пропало. Вот так она забивает на мою длину:
data_len = (uint16)head[6];
data_len = (data_len

[biorhitm]

Вот так она забивает на мою длину:
data_len = (uint16)head[4];
data_len = (data_len << 8) + (uint16)head[5];

А так читает:
wiz_read_buf(s, buf, data_len+(data_len & 0x01));

P.S. Столько пафоса было при регистрации, а сами какие-то детские ошибки делают. Неужели нельзя было сделать парсер чуточку умнее?