sendto , теряются пакеты до отправки в windows

[wolfdown]

Есть примерно такой код (сократил для удобства)

SOCKADDR_IN _serv_addr;
int _mySocket;
QByteArray packet;
 
WSADATA wsda;
if (WSAStartup(0x202, &wsda)) {
    qDebug() << "WSAStartup error: " << WSAGetLastError();
    WSACleanup();
}
_mySocket = socket(AF_INET, SOCK_DGRAM, IPPROTO_UDP);
 
if (_mySocket == INVALID_SOCKET || _mySocket == SOCKET_ERROR) {
    qDebug() << "create socket error" << endl;
    qDebug() << WSAGetLastError();
    WSACleanup();
}
 
_serv_addr.sin_family = AF_INET;
_serv_addr.sin_port = htons(_settings._port);
_serv_addr.sin_addr.s_addr = inet_addr(_settings._ip.toAscii().data());
 
while(true){
       if (sendto(_mySocket, packet.data(), packet.size(), 0, (struct sockaddr*)&_serv_addr, sizeof(sockaddr)) < 0) {
            qDebug() << "Error" << endl;
    }
 
}

При работе на ОС Windows если отлавливать отправляемые с данного хоста пакеты Wireshark`ом пропадает около сотни пакетов. При работе под OC Linux ничего не пропадает. В чем может быть проблема?

Сообщение отредактировано: wolfdown - 29.01.15, 11:29

[popsa]

sendto возвращает при этом SOCKET_ERROR или все успешно? какого размера данные передаются?

[wolfdown]

Цитата popsa @ 29.01.15, 12:02

sendto возвращает при этом SOCKET_ERROR или все успешно? какого размера данные передаются?

Нет. Ошибок отправки нет.
Данные отправляются размером 1000 Байт.

[Relaxander]

собственно, UDP - протокол без гарантии. Так что потеря пакетов там не то чтобы в порядке вещей, но вполне возможна.
Для гарантии нужен TCP

[popsa]

Цитата

Данные отправляются размером 1000 Байт.

с размером не пробовал эксперементировать?

Цитата

пропадает около сотни пакетов

это за какое время?

Цитата

Для гарантии нужен TCP

Это да. ТС, по какой причине UDP а не TCP ?)

[wolfdown]

Не. UDP может теряться в сети и тд. А у меня даже комп не покинуло (см. схему)

Прикреплённая картинка

отправляю 65535 пакетов, соответственно sendto() вызывается столько же раз. На все затрачивается времени - 1 секунда. Wireshrk ловит пакеты на выходе (см. схему) и показывает 65321 или около того, но никогда не 65535.

С размером тоже эксперементировал. Не помогло(

Почему UDP? Ну задачу такую поставили генерировать UDP-трафик

Сообщение отредактировано: wolfdown - 29.01.15, 12:52

[Oleg2004]

Цитата wolfdown @ 29.01.15, 11:24

int _mySocket;

В Винде сокет имеет тип SOCKET
А в Линуксе - int

[wolfdown]

Цитата Oleg2004 @ 29.01.15, 21:26

Цитата wolfdown @ 29.01.15, 11:24

int _mySocket;

В Винде сокет имеет тип SOCKET
А в Линуксе - int

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

#define _W64 __w64
typedef _W64 unsigned int UINT_PTR, *PUINT_PTR;
typedef UINT_PTR        SOCKET;

[Pacific]

wolfdown
Вот совсем не то же самое. В винде сокет - беззнаковый int, с этим связано много ошибок при переносе линуксового кода.

[Oleg2004]

Цитата wolfdown @ 30.01.15, 05:58

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

Идеология разная.
Целое число в *никсах тупо обозначает индекс строки в таблице файлов, в которой расположено описание данного сокета.
В винде - 32-битное число - просто уникальный дескриптор этого сокета.

[Kray74]

Это что сейчас было?

M

Надо сообщать модератору о нарушении в теме  

Сообщение отредактировано: Oleg2004 - 13.02.15, 09:36

[GAGARIN]

Цитата Oleg2004 @ 30.01.15, 08:01

Цитата wolfdown @ 30.01.15, 05:58

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

Идеология разная.
Целое число в *никсах тупо обозначает индекс строки в таблице файлов, в которой расположено описание данного сокета.
В винде - 32-битное число - просто уникальный дескриптор этого сокета.

Более того, исходя из

typedef UINT_PTR        SOCKET;

следует, что на 64-битной машине, SOCKET будет 64-битным числом.

Сообщение отредактировано: GAGARIN - 15.04.15, 09:09

[nemez]

надо данные ловить не ваершарком, а тисипидампом
Он пишет сколько пакетов получено, сколько потеряно
libpcap физически не может ловить все пакеты 100, часть проходит мимо нее. Это естественно. Потому как ядро живет своей жизнью и его производительность не зависит от производительности промежуточного драйвера libpcap, ядро не будет ждать пока какой-то его компонент будет буферизировать дату. Оно будет передавать, а если драйверу повезет, он может его получить. Короче, суть проблемы в том, что буфер libpcap заполняется, но не освобождается, и пакеты идуть стороной. Особенно это видно под виндой ввиду ее кончености как оси.
Но по факту, когда буфер освобождается, для libpcap становится возможным помещать пакеты в свои потроха, и шоу продолжается.
Короче, проблема эта не зависит от платформ особо, а бороться с ней можно путем увеличения размера буфера
tcpdump --buffer-size=3242304820139489201348201348021
на ваершарке, под твоей недоосью, это будет выглядеть так

buffer size
Увеличишь до невдолбенных размеров и будет тебе много счастья, хватило бы оперативы )))