Комментарии 16
Да, в программах бывают ошибки. Да, в библиотеках тоже. Как читателю, хочется какой-то вывод из всего написанного. :)
Вывод — когда будите использовать asio::udp помните об этом. Какой еще вывод? Человек сэкономил время на ресерч — куда уж больше.
Тогда уж, надо было баг-репорт отправить разработчикам asio, будет больше пользы от данной статьи
Мухи отдельно, котлеты отдельно — то что есть где-то багрепорт — не помешает в течении тех месяцев пока его будут чинить наткнуться на данный баг.
Не говоря о том, что вполне возможно данные баг уже описан и известен.
По примеру QT некоторые баги живут годами.
Не говоря о том, что вполне возможно данные баг уже описан и известен.
По примеру QT некоторые баги живут годами.
увы мне его тоже хочется, но для себя я пока не нашел способа, и просто оборачиваю эту конструкцию в try/catch и в catch ничего не делаю. Подумал что вынеся проблему на общественное обозрение будет больше шансов обмозговать и решить ее.
Возможно, в качестве временного решения, можно выделять буфер размером не меньше SO_MAX_MSG_SIZE. Я именно так и делал, поскольку в своё время тоже с удивлением не обнаружил прямого способа определить размер дейтаграммы для считывания.
С сокетами вообще разброд и шатание, по крайней мере под nix'ами и windows API заметно отличается.
Чего стоит только замечательная особенность winapi установить сокет как блокирующий и отсутствие возможности проверить блокирующий он или нет. Из-за этого нельзя полностью корректно реализовать метод isBlocking(), но, тем не менее, во всех библиотеках он реализован, просто может подкинуть несколько интересных сюрпризов под windows.
Чего стоит только замечательная особенность winapi установить сокет как блокирующий и отсутствие возможности проверить блокирующий он или нет. Из-за этого нельзя полностью корректно реализовать метод isBlocking(), но, тем не менее, во всех библиотеках он реализован, просто может подкинуть несколько интересных сюрпризов под windows.
Такая же фигня в исходниках, которые шли с 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
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
Вот так она забивает на мою длину:
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. Столько пафоса было при регистрации, а сами какие-то детские ошибки делают. Неужели нельзя было сделать парсер чуточку умнее?
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. Столько пафоса было при регистрации, а сами какие-то детские ошибки делают. Неужели нельзя было сделать парсер чуточку умнее?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
[asio::udp] Не кроссплатформенное поведение