TCP или UDP с Java

1

Извините за такой длинный пост. Я провел много и много исследований по этой теме, и у меня есть вторая предпосылка, по которой я должен идти. Спасибо заранее за ваши мысли и вклад.

Сценарий:

Создание программы в Java, которая посылает пакеты данных каждые. 2-.5 секунд, которые содержат простые "в этот момент" или данных в реальном времени до примерно 5-7 клиентов. (Приблизительно всего 10 байт данных для каждого пакета). Сервер может быть подключен через Wi-Fi или Ethernet. Однако клиенты ограничены только использованием Wi-Fi. Клиент не будет отправлять какие-либо пакеты на сервер, поскольку он будет отображать только данные, полученные с сервера.

Мои мысли:

Я изначально начал создавать серверную программу с использованием TCP в качестве транспортного уровня. Это будет использовать класс ServerSocket внутри Java. Я также сделал многопоточность для приема нескольких клиентов.

TCP звучал как отличная идея по разным причинам.

  1. С TCP сообщение всегда будет отправлено, если соединение не будет выполнено.
  2. TCP переупорядочивает порядок отправки пакетов.
  3. TCP имеет управление потоком и требует больше времени для настройки при запуске.

Настолько совершенен! Управление потоком имеет решающее значение для этого сценария (так как клиент хочет самую параллельную информацию), время настройки не такое большое, и я в значительной степени гарантирован, что сообщение будет получено. Итак, его чиновник, я принял решение пойти с TCP....

Кроме того, что происходит, когда TCP отстает из-за потери пакетов? "Самая большая проблема с TCP в этом сценарии - это алгоритм управления перегрузкой, который рассматривает потерю пакетов как признак ограничений пропускной способности и автоматически дросселирует отправку пакетов. В сетях 3G или Wi-Fi это может вызвать значительную задержку".

Увидев заметную фразу "значительная латентность", я понял, что это не будет хорошо для этого сценария, так как клиенту необходимо увидеть текущие данные в этот момент, а не продолжать получать данные с.8 секунд назад. Итак, я вернулся к чертежной доске.

После проведения дополнительных исследований я обнаружил еще одну процедуру, которая включала UDP с многоадресной рассылкой. Это использует DatagramSocket на стороне сервера и MulticastSocket на стороне клиента.

UDP с многоадресной рассылкой также имеет свои преимущества:

  1. UDP без установления соединения, что означает, что пакеты передаются всем, кто слушает.
  2. UDP работает быстро и отлично подходит для аудио/видео (хотя мои простые данные, такие как строка).
  3. UDP не гарантирует доставку - это может быть хорошим или плохим. Он не отстает и не создает задержки, но нет гарантии, что все клиенты (клиенты) могут получить данные в этот момент.
  4. Отправляет один пакет, который передается вместе.

Поскольку скорость отправки пакетов будет довольно быстрой (. 2-.5 сек.), Я не слишком беспокоюсь о потере пакетов (если он не будет последовательно отбрасывать пакеты и выглядит невосприимчивым). Основная проблема, с которой я сталкиваюсь с UDP над чем-либо, заключается в том, что она не знает порядок отправки пакетов. Так, например, скажем, я хотел отправить текущие данные текущего времени. Сервер отправляет пакеты, содержащие "11:59:03", "11:59:06", "11:59:08" и т.д. Я бы не хотел, чтобы данные были представлены клиенту как "11:59: 08 "," 11:59:03 "," 11:59:06 "и т.д.

После представления всей информации выше, вот мои вопросы:

  • TCP "догоняет" себя при возникновении проблем с задержкой или всегда остается в стороне, когда возникает латентность при получении пакетов? Если да, то достаточно ли быстро восстановить "живые" данные?

  • Как часто пакеты данных выходят из строя с UDP?

И превыше всего:

  • На ваш взгляд, какой, по вашему мнению, лучше всего подходит для этого сценария?

Спасибо за помощь!

  • 0
    Если вы хотите использовать UDP примерно так же, как TCP, что вам и нужно, оставайтесь с реальной сделкой и используйте TCP. Это просто работает.
Теги:
networking
sockets
tcp
udp

2 ответа

3
Лучший ответ

TCP "догоняет" себя при возникновении проблем с задержкой или всегда остается в стороне, когда возникает латентность при получении пакетов?

TCP восстанавливает скорость передачи, когда он сталкивается с перегрузкой, и пытается восстановить, увеличивая его.

Если да, то достаточно ли быстро восстановить "живые" данные?

Я не знаю, что означает это предложение, но, как правило, полная скорость в конечном итоге восстанавливается.

Как часто пакеты данных выходят из строя с UDP?

Это полностью зависит от промежуточной сети. На это нет единого ответа.

NB Это довольно обычная ссылка, которую вы цитируете.

  • UDP означает "Протокол пользовательских дейтаграмм", а не "Протокол универсальных дейтаграмм".
  • UDP-пакеты имеют встроенный порядок отправки, но при получении не гарантируются.
  • "UDP быстрее, потому что проверка ошибок для пакетов не имеет смысла. "Проверка ошибок для пакетов" подразумевает повторную передачу, но это происходит только тогда, когда была потеря пакетов. Сравнение потери скорости UDP с потерянной скоростью TCP не имеет смысла.
  • "UDP делает проверку ошибок" несовместим с "UDP быстрее, потому что проверка ошибок для пакетов" отсутствует.
  • "TCP требует, чтобы три пакета устанавливали соединение сокета, прежде чем любые пользовательские данные могли быть отправлены" и "Как только соединение установлено, передача данных может начаться" неверны. Клиент может передавать данные вместе с третьим сообщением квитирования.
  • Список полей заголовков TCP является неполным и порядок неверен.
  • Для TCP "сообщение передается на границы сегментов" не имеет смысла, поскольку сообщений нет.
  • "Соединение завершено закрытием всех установленных виртуальных каналов" неверно. Виртуальных цепей нет. Это сеть с коммутацией пакетов.
  • В разделе "рукопожатие" и в нескольких других местах он не упоминает протокол четырехстороннего закрытия TCP.
  • Предложения "В отличие от TCP, UDP совместим с пакетными передачами (передача всем в локальной сети), а многоадресная рассылка (отправка всем абонентам)" и "UDP совместима с пакетной трансляцией" бессмысленны (и, кстати, сняты с более ранней версии Статья в Википедии). Правильный термин здесь не "совместим", а поддерживает.

Я не люблю эту практику, ссылаясь на произвольный интернет-мусор здесь, а затем задавая вопросы на его основе.

Поделиться
  • 0
    Спасибо за предложение. Я удалил ссылку, указанную выше. Эта информация очень помогла. Так что, по вашему мнению, вы считаете, что TCP будет лучшим решением для этого сценария? Даже с возможностью задержки при повторной передаче пакета? И 5-7 различных потоков продемонстрируют какую-либо потерю производительности?
  • 1
    @ Зак Не хватает информации в вашем вопросе, чтобы ответить на этот вопрос. Это зависит от того, нужна ли вам последовательность, управление потоком, гарантированное поступление каждого сообщения и т. Д. Если нет, вы можете использовать UDP. Если вы это делаете, вы должны использовать TCP или внедрить uber -protocol по UDP, который сделает все это за вас, что довольно бессмысленно, когда TCP уже существует. Но отправка сообщения каждые 0,2 секунды семи клиентам на самом деле не является проблемой производительности и сама по себе не является достаточным основанием для принятия такого решения. Если UDP достаточно, вы можете посмотреть и на многоадресную рассылку.
Показать ещё 1 комментарий
0

UDP-пакеты могут выйти из строя, если между сервером и клиентом существует много перелетов, но более вероятно, чем выйти из строя, так это то, что некоторые из них будут сброшены (опять же, чем больше шансов, тем больше шансов). Если ваша главная проблема с UDP - это порядок, и если у вас есть контроль над клиентом, вы можете просто отказаться от любых сообщений с более ранней меткой времени, чем предыдущая.

Поделиться

Ещё вопросы

Сообщество Overcoder
Наверх
Меню