Надежность в UDP

Мне нужно сделать проект приложения BitTorrent на Java, и он требует передачи данных по протоколу UDP, а не по TCP. В этом проекте учитель просит меня убедиться в надежности протокола UDP. Поэтому я искал некоторые решения в Интернете и обнаружил, что в java есть такие классы, как «ReliableSocket» и «ReliableServerSocket». Поэтому я хотел бы знать, что эти классы могут удовлетворить требования моего проекта. И в чем разница между этими двумя классами?

Спасибо большое за вашу помощь


person Lee Dat    schedule 25.12.2016    source источник
comment
Tcp — это надежный протокол, что означает, что протокол надежен и абстрагирован от инкапсулированного уровня приложений. Udp не является, поэтому сначала применяется некоторый порядок к пакетам или сеансу (в udp нет такого понятия, как сеанс в udp, вы должны создать его на уровне приложения), чтобы можно было собирать не по порядку полученные пакеты и обнаруживать отброшенные пакеты. и заставить их возмущаться. В основном все, что Tcp делает для вас эффективно и аккуратно, абстрагируется от вас, вы должны делать. Я бы сказал, почему бы просто не использовать Tcp? Похоже на плохое использование существующих технологий.   -  person marshal craft    schedule 25.12.2016
comment
Также полагаю, что Google сделал свою собственную версию Udp под названием Quick, которая, как я думаю, предназначена для замены tcp с более высокой производительностью, хотя я не уверен в специфике Quick, поскольку это не интернет-стандарт, как tcp и удп есть. Но если это сделано Google, вероятно, для него есть несколько пакетов nodejs.   -  person marshal craft    schedule 25.12.2016
comment
Это Oracle Java или javascript? Я предполагаю, что Oracle Java на данный момент.   -  person marshal craft    schedule 25.12.2016


Ответы (1)


UDP — это ненадежный протокол с потерями, который работает поверх протокола IP. В отличие от TCP (который обрабатывает все аспекты надежной связи), прикладной уровень должен обрабатывать отброшенные пакеты и другие аспекты «надежного» транспортного протокола. Таким образом, вполне вероятно, что любая реализация, которая требует надежности в той же степени, что и TCP, будет иметь дополнительные накладные расходы.

Вы можете выделить два порта port A и port B. Каждый порт является однонаправленным, если нет отброшенного пакета.

client 1 = port A = server 2

server 1 = port B = client 2

Это делает вещи простыми. Сервер просто отправляет данные и периодически прослушивает, но получает сообщения только в том случае, если его клиент сбрасывает сигнал.

Клиент — это отрицание. Он принимает сигналы и отправляет только в случае отсутствия пакета. Альтернативной реализацией была бы та, в которой пара клиент/сервер могла бы общаться друг с другом, делая порт действительно однонаправленным.

Мы получаем надежность сообщений на обоих портах, используя индекс двух пакетов.

client index 1 = server index 2

server index 1 = client index 2

Индекс для каждого из них является однобайтовым и увеличивается клиентами при отправке нового сообщения. Доставка сообщения предполагается до тех пор, пока не будет получено специальное сообщение, которое будет UDP-сообщением для отброшенного пакета. Это будет содержать сигнал для отброшенного сообщения, вероятно, в его наиболее значимом или наименее значимом бите / байте в зависимости от порядка следования байтов дизайна, а также от индекса сообщения. Очередь также кажется необходимой, но я еще не проработал ее детали.

person marshal craft    schedule 25.12.2016
comment
Мои данные могут быть любого типа, например byte[], int, String, java object или объект, который я создаю. Поэтому, когда мы хотим передавать данные по UDP, мы должны преобразовать мой тип данных в массив байтов и привязать его к DatagramPacket. Но DatagramPacket не гарантирует надежность, я иногда терял свой пакет. - person Lee Dat; 25.12.2016
comment
Поэтому я хотел бы знать, поддерживает ли java какой-либо доступный механизм для надежной передачи данных. Ваша идея хороша, но мы должны программировать сами. - person Lee Dat; 25.12.2016
comment
Да, вы должны запрограммировать его самостоятельно. На самом деле, если вам нужна надежность, вы должны использовать TCP, он был разработан, чтобы быть надежным. Единственным недостатком TCP является то, что он распознает клиентов и серверы. Так что обычно два конца, один задает все вопросы, а другой просто отвечает на эти запросы. Я не хочу вдаваться в преобразование сетевых адресов, но, как правило, возникают проблемы, когда сервер хочет действовать как клиент. Одним из решений этого является WSS или веб-сокет, который делает Tcp более похожим на Udp, поскольку обе стороны могут выступать в качестве клиента. - person marshal craft; 25.12.2016
comment
Существует протокол Quic от Google, который был представлен для принятия в качестве нового формального интернет-стандарта, такого как UDP (после прочтения о нем я думаю, что он просто переносит TSL (ssl) в UDP. Что странно, потому что спецификация TSL уже описывает UDP. Я читал что QUIC хорошо обрабатывает отброшенные пакеты, что бы это ни значило.Вы почти наверняка можете найти и использовать API сокета java QUIC. - person marshal craft; 25.12.2016
comment
Нужно ли использовать тайм-аут в этом случае? По истечении некоторого времени, если клиент не получает данные, это означает, что они потеряны, поэтому сервер должен отправить их повторно. - person Lee Dat; 26.12.2016
comment
@ABCDE в каком случае? В UDP нет такой вещи, как соединение, и, следовательно, не может истечь время ожидания, как в случае TCP. Если вы имеете в виду QUIC, я не могу сказать, так как у меня нет опыта работы с этим протоколом передачи. - person marshal craft; 27.12.2016
comment
Я думаю, что в вашем вопросе есть две стороны. Академическая сторона, на которой вы узнаете о транспортных протоколах Интернета и инкапсуляции/кодировании пакетов, а также о реальных коммерческих продуктах. С одной стороны, это хорошее упражнение, вы можете полностью и легко внедрить прикладное программное обеспечение, чтобы сделать UDP надежным. Может быть, даже с меньшим капитальным ремонтом и более высокой пропускной способностью, чем TCP? С другой стороны, TCP является международным стандартом надежной передачи и, вероятно, делает это очень хорошо. Возможно, даже он оптимизирован, чтобы быть лучшим решением, учитывая его уровень надежности. - person marshal craft; 27.12.2016
comment
Таким образом, разработка собственной реализации, которая по существу имитирует TCP, может оказаться бесполезной. Также у TCP есть то преимущество, что он делает все на уровне IP, поэтому вы просто отправляете пакеты, и все эффективно обрабатывается самостоятельно. UDP существует на уровне IP, поэтому обработка отброшенных пакетов будет инкапсулирована в полезную нагрузку пакета UDP, а не в оптимизированный заголовок. - person marshal craft; 27.12.2016
comment
Google, возможно, разработал QUIC, потому что ему требовался улучшенный носитель производительности, отличный от TCP. По сути, для этого требовалась не вся надежность TCP, а больше, чем UDP. Таким образом, вполне возможно, что прирост производительности был возможен. Например, видео в реальном времени, если пакет отброшен, не нужно пытаться его получить, но, возможно, ему нужно какое-то отслеживание, что делает его средой передачи с полупотерями. Как ни странно, я читал, что QUIC работает НАД UDP вместо того, чтобы просто работать как собственный протокол по IP. Таким образом, QUIC — это просто приложение между IP/UDP и вашим приложением. - person marshal craft; 27.12.2016
comment
Также я склонен замечать, что, хотя Google отлично справляется с вещами, лежащими на очень высоком уровне абстракции, такими как браузер, разработанный на Python, или веб-сервер, все вещи, которые требуют ярких творческих идей; это часто кричащие разработчики, как правило, терпят неудачу в других областях, часто близких к аппаратному обеспечению, используя международное сотрудничество нескольких конгломератов и почти все, что существует, как правило, низко в большой сложной и часто асимметричной иерархии абстракции и смягчения сложности, где другие компании обычно сигнализируют Microsoft. присутствие доминировало - person marshal craft; 28.12.2016
comment
обычно в этих областях преобладает необходимость, и именно поэтому они асимметричны, и творческие идеи просто не работают. Например, при заданном дискретном списке объектов, определяющих слово «надежный», существует очень четко определенное оптимальное решение. - person marshal craft; 28.12.2016