Проблема с отправкой и получением пакетов Java UDP

Я работаю над проектом для класса, используя отправителей и получателей Java и UDP. Предпосылка проблемы состоит в том, чтобы прочитать текстовый файл, сохранить содержимое в пакете, отправить пакет, получить пакет, прочитать файл на экране и создать новый текстовый документ на принимающем компьютере из идентичного текстового файла. .

У меня все это работает. Когда я тестирую с локальным хостом, он работает в 100% случаев. Когда я отправляю его со своего ноутбука на компьютер, он работает в 100% случаев. Однако, когда я отправляю его с моего ПК на свой ноутбук, он не работает.

У меня есть несколько операторов отладки System.out для проверки некоторой информации, которую я отправляю. Я знаю, что текстовый файл должен занимать 7 пакетов. Однако всякий раз, когда я отправляю его со своего ПК на ноутбук, он говорит, что я отправляю 46 пакетов.

Моя первоначальная мысль заключалась в том, что, возможно, пакеты отправляются не по порядку. Первый пакет, который я отправляю, указывает, сколько пакетов должен получить получатель. Я подумал, может быть, по какой-то причине «46» может означать заглавную «F», поэтому я удалил все заглавные «F», и все равно написано, что я отправляю 46 пакетов.

Я подумал, что, может быть, я отправляю слишком много информации за раз, поэтому я использовал Thread.sleep(), чтобы дать моему получателю время не отставать - это тоже не сработало.

Наконец, я прочитал документацию Oracle и несколько сообщений в Интернете и обнаружил, что UDP ненадежен. Итак, я предполагаю, что потенциально это может быть так. Тем не менее, я хочу просто убедиться, что это может быть проблемой.

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

Спасибо за вашу помощь :)


person BearForceOne    schedule 19.09.2014    source источник


Ответы (1)


Да, UDP — ненадежный протокол. Сообщения UDP могут быть потеряны, и ни отправитель, ни получатель не получат никакого уведомления.

7 пакетов становятся 46 пакетами, как правило, из-за фрагментации на уровне IP-пакетов. Уровень протокола ниже IP (например, физические пакеты Ethernet, пакеты Wi-Fi и т. д.) обычно имеет жесткое ограничение на самый большой IP-пакет, который может быть отправлен «за один раз», и аналогичные ограничения налагаются сетевыми маршрутизаторами, шлюзами и т. д. Если отправлен IP-пакет, размер которого превышает лимит, могут произойти две вещи:

  • IP-пакет может превратиться в «фрагменты», которые необходимо собрать получателю.

  • Промежуточное оборудование может отправить обратно отправителю ICMP-сообщение, указывающее ему отправлять меньшие IP-пакеты.

В любом случае конечным результатом является то, что количество IP-пакетов, необходимых для отправки UDP-сообщения заданного размера, может варьироваться в зависимости от сети.

Конечно, если сообщение UDP должно быть отправлено в виде нескольких IP-пакетов, И в сети существует локальная перегрузка, это увеличит вероятность того, что пакеты и, следовательно, сообщения не будут отправлены.


Но суть в том, что UDP ненадежен. Если вам нужна надежность, простое решение — использовать TCP.

person Stephen C    schedule 19.09.2014
comment
Потрясающий ответ, спасибо! Я решил проверить это. Я не уверен, что это было просто совпадение, но, похоже, это сработало. Я попробовал это со своего ноутбука на свой компьютер с кучей воспроизводимых видео на Youtube, и приемник UDP сказал, что получил 106 пакетов, и в конечном итоге сообщение не было получено должным образом. Я отключил их все и отправил их снова, и это сработало. Я провел тот же эксперимент с моего компьютера на свой ноутбук, и у меня были те же результаты. Опять же, не уверен, было ли это совпадением, но из того, что вы сказали, и из моего эксперимента, похоже, это ответ на мою проблему. Спасибо :) - person BearForceOne; 19.09.2014
comment
@BearForceOne - это указывает на потерю пакетов как на проблему. Если вы потеряете один пакет, вы потеряете все UDP-сообщение, и, следовательно, передача файла завершится неудачно. - person Stephen C; 20.09.2014