Теряются UDP в виртуальной сети VMWare - Сети, сокеты, протоколы

Ни кто не сталкивался с этой проблемой.
На реальных машинах с железными роутерами проблем не наблюдал. Все это происходит именно в виртуальной сети VMWare.
При чем как правило теряются именно первые пакеты. Стоит только первому пакету пройти, и все, все остальные удачно доходят.
Под первыми пакетами подразумеваю пакеты, идущие сразу после:

       SOCKET sock = socket(AF_INET, SOCK_DGRAM, IPPROTO_UDP);
       if (sock == INVALID_SOCKET)
             return;
 
       BOOL bOptVal = TRUE;
       setsockopt(sock, SOL_SOCKET, SO_REUSEADDR, reinterpret_cast<char*>(&bOptVal), sizeof(bOptVal));
 
       DWORD interval = ConnectionTimeOut * 1000;
       setsockopt(sock, SOL_SOCKET, SO_RCVTIMEO, reinterpret_cast<char*>(&interval), sizeof(interval));
 
       sockaddr_in ServerAddr;
       ServerAddr.sin_family = AF_INET;
       ServerAddr.sin_port = 0;
       ServerAddr.sin_addr.s_addr = inet_addr(IPv4Address.c_str());
       if (bind(sock, reinterpret_cast<sockaddr*>(&ServerAddr), sizeof(ServerAddr)))
       {
             closesocket(sock);
             return;
       }
 
       if (connect(sock, reinterpret_cast<sockaddr*>(&addr), sizeof(addr)))
       {
             closesocket(sock);
             return;
       }

recv говорит что отправил, и говорит сколько отправил.
recvto пробовал без connect — эффект тот же, хотя чего тут ожидать.
Такое впечатление, что необходимо просто сбросить сокет из какого-то зависшего состояния.

Заранее благодарен за любые намеки.

Здравствуйте, dosik, Вы писали:

D>Ни кто не сталкивался с этой проблемой.
D>На реальных машинах с железными роутерами проблем не наблюдал. Все это происходит именно в виртуальной сети VMWare.
D>При чем как правило теряются именно первые пакеты. Стоит только первому пакету пройти, и все, все остальные удачно доходят.

NAT punchthrough ?

Добрый день
Нет опыта в работе в сети VMWare , но по опыту работу в других системах сталкивался с подобной
ситуацией.

Первый пакет теряется поскольку адрес машины на которую посылается сообщение не известен и не находиться в таблице ARP.
После посылки первого пакета , инициируетя сообщение по протоколу ARP и вносится в таблицу.
Следующие пакеты уже посылаются без проблем.

Здравствуйте, dosik, Вы писали:

D>Ни кто не сталкивался с этой проблемой.
D>На реальных машинах с железными роутерами проблем не наблюдал. Все это происходит именно в виртуальной сети VMWare.
D>При чем как правило теряются именно первые пакеты. Стоит только первому пакету пройти, и все, все остальные удачно доходят.
D>Под первыми пакетами подразумеваю пакеты, идущие сразу после:
D>

D>       SOCKET sock = socket(AF_INET, SOCK_DGRAM, IPPROTO_UDP);
D>       if (sock == INVALID_SOCKET)
D>             return;
 
D>       BOOL bOptVal = TRUE;
D>       setsockopt(sock, SOL_SOCKET, SO_REUSEADDR, reinterpret_cast<char*>(&bOptVal), sizeof(bOptVal));
 
D>       DWORD interval = ConnectionTimeOut * 1000;
D>       setsockopt(sock, SOL_SOCKET, SO_RCVTIMEO, reinterpret_cast<char*>(&interval), sizeof(interval));
 
D>       sockaddr_in ServerAddr;
D>       ServerAddr.sin_family = AF_INET;
D>       ServerAddr.sin_port = 0;
D>       ServerAddr.sin_addr.s_addr = inet_addr(IPv4Address.c_str());
D>       if (bind(sock, reinterpret_cast<sockaddr*>(&ServerAddr), sizeof(ServerAddr)))
D>       {
D>             closesocket(sock);
D>             return;
D>       }
 
D>       if (connect(sock, reinterpret_cast<sockaddr*>(&addr), sizeof(addr)))
D>       {
D>             closesocket(sock);
D>             return;
D>       }
D>

D>recv говорит что отправил, и говорит сколько отправил.
D>recvto пробовал без connect — эффект тот же, хотя чего тут ожидать.
D>Такое впечатление, что необходимо просто сбросить сокет из какого-то зависшего состояния.

D>Заранее благодарен за любые намеки.

Здравствуйте, neFormal, Вы писали:

F>NAT punchthrough ?

Что простите?

Здравствуйте, Alex34, Вы писали:

A>Добрый день
A>Нет опыта в работе в сети VMWare , но по опыту работу в других системах сталкивался с подобной
A>ситуацией.

A>Первый пакет теряется поскольку адрес машины на которую посылается сообщение не известен и не находиться в таблице ARP.
A>После посылки первого пакета , инициируетя сообщение по протоколу ARP и вносится в таблицу.
A>Следующие пакеты уже посылаются без проблем.

Так вот если бы! Тогда бы потерялся один "самый" первый.
А тут не идут первые из соединения. Т.е. один и тот же клиент через определенный интервал шлет запросы, для ответа на которые я каждый раз открываю новый сокет. И только одному богу известно, заработает он или нет.

Здравствуйте, dosik, Вы писали:

F>>NAT punchthrough ?
D>Что простите?

ну гугл же.

если вкратце, то при проходе через NAT(если он включен для сети в vmware) он забирает первый пакет.
по этому пакету создаётся внутри NAT'а редирект с внешнего адреса на адрес внутренней сети. без этого NAT не будет позволять подключаться с внешнего на внутренний.

Здравствуйте, neFormal, Вы писали:

F>если вкратце, то при проходе через NAT(если он включен для сети в vmware) он забирает первый пакет.
F>по этому пакету создаётся внутри NAT'а редирект с внешнего адреса на адрес внутренней сети. без этого NAT не будет позволять подключаться с внешнего на внутренний.

Врядли. Внутренняя виртуальная сетка аля 192.168.168.0/24. IP я сам клиенту по DHCP назначаю, т.е. например у меня 192.168.168.1, а у клиента 192.168.168.10. От куд там NAT?
К стати пробовал для эксперимента слать первый ответ два раза — эффект тот же.

это не проблема

UDP uses a simple connectionless transmission model with a minimum of protocol mechanism. It has no handshaking dialogues, and thus exposes the user's program to any unreliability of the underlying network protocol. There is no guarantee of delivery, ordering, or duplicate protection

Здравствуйте, ononim, Вы писали:

O>это не проблема

O>UDP uses a simple connectionless transmission model with a minimum of protocol mechanism. It has no handshaking dialogues, and thus exposes the user's program to any unreliability of the underlying network protocol. There is no guarantee of delivery, ordering, or duplicate protection

Еще какая проблема. Это известно и к этому готовы разработчики протоколов, работающих поверх UDP. Но в рамках одного хопа потери из 5-6 попыток проходит только 1 — перебор даже UDP.

Здравствуйте, dosik, Вы писали:

D>Врядли. Внутренняя виртуальная сетка аля 192.168.168.0/24. IP я сам клиенту по DHCP назначаю, т.е. например у меня 192.168.168.1, а у клиента 192.168.168.10. От куд там NAT?
D>К стати пробовал для эксперимента слать первый ответ два раза — эффект тот же.

если "ответ", то действительно не похоже. это только для запросов, ответы не страдают, насколько я знаю.

Здравствуйте, dosik, Вы писали:

D>Здравствуйте, ononim, Вы писали:

O>>это не проблема

O>>

O>>UDP uses a simple connectionless transmission model with a minimum of protocol mechanism. It has no handshaking dialogues, and thus exposes the user's program to any unreliability of the underlying network protocol. There is no guarantee of delivery, ordering, or duplicate protection

D>Еще какая проблема. Это известно и к этому готовы разработчики протоколов, работающих поверх UDP. Но в рамках одного хопа потери из 5-6 попыток проходит только 1 — перебор даже UDP.

Перебор? Кто вам это сказал? UDP исповедует принцип "fire & forget". 100% потеря или 1% потеря UDP-трафика укладываются в элемент нормы.

Здравствуйте, neFormal, Вы писали:

F>если "ответ", то действительно не похоже. это только для запросов, ответы не страдают, насколько я знаю.

Ну фактически — ответ на запрос, который пришел на другой порт. Т.е. для ответа я создаю новый сокет.

Здравствуйте, Mr.Delphist, Вы писали:

MD>Перебор? Кто вам это сказал? UDP исповедует принцип "fire & forget". 100% потеря или 1% потеря UDP-трафика укладываются в элемент нормы.

А может все же по искать способ как сделать, чем искать отговорки и возможность не делать?

Здравствуйте, dosik,

Еще раз повторю:
UDP не гарантирует доставку. Совсем. От слова "вообще". Даже в пределах одного хопа. Даже в пределах localhost. 1% потерь или 100% потерь — все это укладывается в норму.

Здравствуйте, Vlad_SP, Вы писали:

V_S>Здравствуйте, dosik,

V_S>Еще раз повторю:
V_S>UDP не гарантирует доставку. Совсем. От слова "вообще". Даже в пределах одного хопа. Даже в пределах localhost. 1% потерь или 100% потерь — все это укладывается в норму.

Вы мне сейчас Америку пытаетесь открыть, иль другую какую страну?
По Вашей логике так DHCP вообще работать не должен (если переложить ее на конкретно озвученную мной проблему), и придумали его дураки!
Я о чем писал? О конкретной проблеме, "первые" пакеты после создания сокета не доходят до адресата в виртуальной сети, и практика показывает, что в реальных "железяных" сетях эта проблема ~~не возникает~~ не стоит так остро.
Так что, если конкретно посоветовать нечего, и Вам так хочется блеснуть своими теоретическими знаниями и процетировать RFC, может пора переходить к закату карьеры — преподавать.
Заметьте, я хоть что-то конкретное Вам предложил!

O>>это не проблема

O>>

O>>UDP uses a simple connectionless transmission model with a minimum of protocol mechanism. It has no handshaking dialogues, and thus exposes the user's program to any unreliability of the underlying network protocol. There is no guarantee of delivery, ordering, or duplicate protection

D>Еще какая проблема. Это известно и к этому готовы разработчики протоколов, работающих поверх UDP. Но в рамках одного хопа потери из 5-6 попыток проходит только 1 — перебор даже UDP.
Чисто к сведению — на стыке гигабитного и 100мбитного эзернета на обычном свиче теряется 9 пакетов из 10 _постоянно_ если с гигабитной стороны пихать их с максимально возможной скоростью и без контроля передачи просто потому что канал физически не способен их принять. И ничего, живут люди

Здравствуйте, ononim, Вы писали:

O>Чисто к сведению — на стыке гигабитного и 100мбитного эзернета на обычном свиче теряется 9 пакетов из 10 _постоянно_ если с гигабитной стороны пихать их с максимально возможной скоростью и без контроля передачи просто потому что канал физически не способен их принять. И ничего, живут люди

Это правда. Но мы тут разбираем случай когда в сети тишина, и тут появляется один пакетик, который куда-то исчезает.
Я думаю скорее проблема в сокете, так как почему-то именно первый. Может опцию какую добавить надобно. Остальные далее идут все без потерь, до 5-6 тыс. пакетов.
Пока вышел из положения топорно — первый пакет send и сразу такой же sendto.
Буду думать дальше.
Спасибо.

D>Это правда. Но мы тут разбираем случай когда в сети тишина, и тут появляется один пакетик, который куда-то исчезает.
D>Я думаю скорее проблема в сокете, так как почему-то именно первый. Может опцию какую добавить надобно. Остальные далее идут все без потерь, до 5-6 тыс. пакетов.
D>Пока вышел из положения топорно — первый пакет send и сразу такой же sendto.
D>Буду думать дальше.
D>Спасибо.
Ну если рассматривать этот случай чисто из любопытства то я бы предположил проблемы с роутингом. Ну вначале шлются пакеты через неправильный интерфейс/гейтвей а потом срабатывает какой нить dead gw detection (если там юзается еще и tcp) или видит что нету arp ответов через выбранный неправильный интерфейс и переключается в правильный. Но не зная топологии вашей сети — хз.

Здравствуйте, dosik, Вы писали:

D>Такое впечатление, что необходимо просто сбросить сокет из какого-то зависшего состояния.
D>Заранее благодарен за любые намеки.
А что именно используется из VMWare (Workstation, ESXi) и какого размера пакеты?

На ESXi VMWare вообще любит мелкие UDP пакеты терять (<40 байт). Тогда стоит попробовать поменять тип vNIC у машин или патчи соответствующие поставить.
Или, наоборот, пакеты могут быть слишком большими, в этом случае можно настроить адаптеры (для vmxnet3 выставить параметры Small Rx Buffers и Rx Ring #1 Size на максимум)

Здравствуйте, Conr, Вы писали:

C>А что именно используется из VMWare (Workstation, ESXi) и какого размера пакеты?

C>На ESXi VMWare вообще любит мелкие UDP пакеты терять (<40 байт). Тогда стоит попробовать поменять тип vNIC у машин или патчи соответствующие поставить.
C>Или, наоборот, пакеты могут быть слишком большими, в этом случае можно настроить адаптеры (для vmxnet3 выставить параметры Small Rx Buffers и Rx Ring #1 Size на максимум)

Я использую Workstation. И "первые" пакеты как раз около 15-20 байт.
Думаете можно пропатчить?

От:	dosik	www.dosik.ru
Дата:	23.12.15 05:52
Оценка:

	От:	neFormal
	Дата:	23.12.15 06:04
	Оценка:

	От:	Alex34
	Дата:	23.12.15 08:52
	Оценка:

От:	dosik	www.dosik.ru
Дата:	23.12.15 10:50
Оценка:

От:	dosik	www.dosik.ru
Дата:	23.12.15 10:53
Оценка: