Почему Socket.BeginReceive теряет пакеты из UDP?

Следующий код ожидает данных по UDP.У меня есть тестовая функция, которая отправляет 1000 пакетов (датаграмм?) По 500 байт каждый.Каждый раз, когда я запускаю тестовую функцию, получатель получает только первые несколько десятков пакетов, но отбрасывает остальные.Я просмотрел входящие сетевые данные с помощью Wireshark и увидел, что все 1000 пакетов действительно получены, но просто не дожидаются кода приложения.Вот некоторые из соответствующих кодов VB.NET 3.5:Я отправляю данные следующим образом (пока не беспокоюсь о содержимом пакета):Если я добавляю небольшую задержку после каждого вызова Send, больше пакетов пройдет;однако, поскольку Wireshark говорит, что все они все равно были получены, похоже, что проблема в моем коде приема.Следует упомянуть, что UdpListen работает в отдельном потоке.Есть идеи, почему я сбрасываю пакеты?Я также пробовал UdpClient.BeginReceive /EndReceive, но имел ту же проблему.Вторая проблема, которая меня беспокоит, - это глобальный характер приемного буфера при использовании Sockets, и я не уверен, что обрабатываю входящие пакеты достаточно быстро, чтобы буфер был перезаписан.Пока не знаю, что с этим делать, но я открыт для предложений.26 сентября: ОбновлениеОсновываясь на различных, несколько противоречивых предложениях из ответов на этот и другие сообщения, я внес некоторые изменения в свой код.Спасибо всем, кто вмешивался в различные вопросы;Теперь я получаю все свои пакеты от коммутируемого доступа до Fast Ethernet.Как видите, виноват мой код, а не тот факт, что UDP отбрасывает пакеты (на самом деле я не видел более крошечного процента отбрасываемых или выходящих из строя пакетов с момента моих исправлений).Отличия:1) BeginReceive () /EndReceive () заменено на BeginReceiveFrom () /EndReceiveFrom ().Само по себе это не имело никакого благородного эффекта.2) Объединение вызовов BeginReceiveFrom () вместо ожидания установки асинхронного дескриптора.Не уверен, есть ли здесь польза.3) Явно установите Socket.ReceiveBufferSize равным 500000, что достаточно для 1 секунды моих данных на скорости Fast Ethernet.Оказывается, это другой буфер, чем тот, который был передан в BeginReceiveFrom ().В этом была самая большая выгода.4) Я также изменил свою процедуру отправки, чтобы подождать пару мсек после отправки определенного количества байтов для регулирования в зависимости от ожидаемой полосы пропускания.Это было большим преимуществом для моего получающего кода, даже несмотря на то, что Wireshark сказал, что все мои данные по-прежнему передаются даже без этой задержки.Я НЕ стал использовать отдельный поток обработки, потому что, как я понимаю, каждый вызов BeginReceiveFrom будет вызывать мой обратный вызов в новом рабочем потоке.Это означает, что у меня может быть одновременно запущено несколько обратных вызовов.Это также означает, что как только я вызываю BeginReceiveFrom, у меня появляется время заняться своими делами (если я не трачу слишком много времени и не исчерпываю доступные рабочие потоки).То, что не показано выше, - это обработка ошибок и работа с неверными или отсутствующими данными UDP.Я думаю, что это решит мою проблему, но если кто-то все еще видит что-то не так с вышеизложенным (или что-то, что я мог бы сделать лучше), я хотел бы услышать об этом.
7 голосов | спросил Dan C 25 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowSat, 25 Sep 2010 12:47:22 +0400 2010, 12:47:22

0 ответов


Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132