@yura91

При передаче некоторого количества байт по протоколу udp я же могу предсказать сколько байт отправится за один раз функцией send() - на клиенте и сколько байт прочитается одним вызовом recv - на сервере верно?? Ведь это же не потоковый протокол как tcp а передача датаграм.

1

@aLarman

Если запись достаточно медленная, то скорее всего в 98% случаев будет записано столько же сколько указан в send размер буфера да достаточно простая ситуация, с одной стороны отправвили 1024байта, на другой стороне ждите 1024 байта

0

@noname664

UDP капитально отличается от TCP.

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

Спасибо за то, что пользуетесь UDP)

1

Убежденный

noname664, все круто, только вот это чушь:

При передаче сопоставимых объемов данных нагрузка будет примерно одинаковой с TCP.

и это тоже под сомнением:
Так можно сказать: не делай в TCP "что-то не так", и ничего не будет виснуть.

0

@noname664

Вам не понравился UDP?

0

Убежденный

Нравится/не нравится - это не профессионально.
У обоих протоколов есть и сильные, и слабые стороны, для каких-то задач
лучше подходит TCP, для других UDP. А из сообщения #3 можно сделать
неверный вывод, что UDP априори лучше.

0

magirus

нам пофиг в общем.
УДИПИ - протокол с недостоверной доставкой. а дальше сами решайте.

0

@noname664

Сильные стороны UDP я перечислил, а какие сильные стороны у TCP.
Я не говорю, что TCP плох во всём, а говорю, что UDP лучший во многом.

Добавлено через 5 минут
Это стандартный общий ответ, не раскрывающий сути.
Но давайте не будем голословны), а составим список плюсов TCP и сравним их со списком плюсов UDP.

Добавлено через 24 минуты
И ещё...
На UDP работают все игры, и игровые сервера по нему раздают игровые файлы.
На этом протоколе работают голосовые программы.
На нём работает DHCP и DNS.
Google разработал протокол QUIC на базе UDP для браузеров взамен браузерных TCP-сессий, но он пока ещё слишком новый и мало распространён.
uTorrent работает на UDP.

TCP вытесняется UDP.
TCP имеет уязвимости, уязвимость тройного квитирования, всего 32-х разрядный счётчик пакетов, из-за чего при передаче большого объёма данных номера пакетов начнут часто повторяться, это старый протокол, он просто устарел.

Убежденный, Вы наверно часто работали с TCP, а UDP наверно особо не использовали.

Добавлено через 13 минут
Блин, точно, я слегка преувеличил, извини(. Он не может вообще не нагружать, некоторая нагрузка конечно есть. Вот здесь я лоханулся и даже не заметил. Я собою снова недоволен .

0

Убежденный

Гарантия доставки данных целостно и в правильном порядке.
Flow control (сервер и клиент свободно работают на разной
пропускной способности сети).
Full duplex
Graceful shutdown

то же самое я могу сказать про TCP.

В 99% случаев не надо изобретать велосипедо-TCP на базе UDP, надо сразу брать TCP.
IMHO.

В TCP они тоже не факт, что будут объединены.

А TCP что, не позволяет?
Вон сколько вокруг прикладных протоколов на базе именно TCP, работают годами и
меняются, как правило, лишь незначительно. Сам TCP, кстати, за многие годы существования
тоже особо не претерпел серьезных изменений.

И получим сферического коня в вакууме. Надо сравнивать не плюсы-минусы, а
эффективность и целесообразность использования протокола в конкретных задачах.

На TCP построен HTTP, почтовые протоколы, FTP и еще куча всего.

Угу. Принято в таких случаях писать "TCP больше не актуален, TCP умер".
Поживем еще лет двадцать - увидим. HTTP тоже пророчили скорую смерть, а он жив.

Изобрети аналог TCP на базе UDP и я посмотрю, сколько в нем будет уязвимостей,
функциональных недосмотров и просто архитектурных просчетов. И проживет ли он
столько же, сколько TCP, и будет ли таким же популярным.

Спор ни о чем.

0

@noname664

Убежденный, Ваше последнее сообщение показало защиту личной точки зрения. Если человек перешёл на защиту личной точки зрения, он будет её защищать даже если будет не прав. Я не защищаю свою точку зрения, у меня её как бы нет, я просто излагаю выводы, и конечно мне не приятно, если я ошибаюсь в выводах, обычно мне не интересно личное мнение, но мне всегда интересны аргументы и логика выводов.

Вот почему я увидел с Вашей стороны защиту личной точки зрения:

Я указал про протокол QUIC, но вы не указали про него, когда написали:
Они же всегда объединяются в сплошной поток, ну Вы же скорее всего об этом знаете.

Это эмоция, чтобы указать, что я неправ и не заметил "очевидного".

На нём нельзя сделать игру в стиле Action из-за пинга. На UDP принципиально можно создать TCP, поэтому UDP универсальнее, более мощнее, он не ограничивает так, как ограничивает TCP.

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

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

0

Убежденный

Да.

Нет.

А что QUIC?
Он еще слишком далек от той черты, чтобы поглотить другие протоколы.
И неизвестно, пересечет ли ее когда-нибудь или нет.

Изначально было написано иначе: "UDP позволяет отправлять несколько пакетов подряд и они не будут
объединены в один общий, как в TCP". В TCP вообще нет никаких гарантий относительно того,
какими порциями придут данные, т.е. будут ли они объединены или фрагментированы.

Нет, это ответ на реплику "Вы наверно часто работали с TCP, а UDP наверно особо не использовали".
Потому что холивар "TCP vs UDP" сразу съехал на намек на то, что я, мол, не использовал UDP и поэтому "не в теме".

Допустим.
Но TCP уже "готов", а UDP в этом случае придется еще "готовить". Попробуй-ка сделать
на UDP гарантию порядка и отправку в случае потери пакетов. Довольно сложно. Не согласен?
Кстати, если рассуждать в таком ключе, почему бы тогда сразу не спуститься на канальный уровень?
Следуя этой логике, он мощнее и универсальнее чем TCP и UDP, вместе взятые.
Хотел бы услышать твое мнение на этот счет.

Да, все верно.
Точно также, как и HTTP, который работает поверх TCP. Как пример. Но я бы не стал делать из
этого далекоидущие выводы в духе "XXX мощнее YYY, так как XXX более низкоуровневый и сырой".
Начнем с того, что для YYY может быть тонна готовых и годами проверенных реализаций, а
для XXX под эту задачу нет.

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

Да. Я не высшая материя и абсолютная истина мне неведома.

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

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

Для передачи звука в реал-тайме, очевидно, лучше использовать UDP.
Для скачивания файла - TCP.
Попытка использовать одно вместо другого приведет либо к потере эффективности,
либо к усложнизму на ровном месте.

0

@noname664

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

По поводу съезжания на канальный уровень. Нет. Это слишком низко, я думал, что Вы используете в качестве аргумента сетевой уровень, где можно работать сразу с пакетами протокола IP. Нет, там нужно самому фрагментировать пакет по MTU и там нет портов, поэтому будет проблема с доставкой пакета на уровень сокетов конкретной программе через порты. Поэтому ниже уровня UDP опускаться, значит усложнить передачу данных из-за ручного разбиения пакета и отсутствия портов как удобной концепции адресации процессов. Концепция портов не ограничивает UDP. IP адресует компьютер, интерфейс, узел, Порт адресует ещё точнее - процесс. Связка IP+Port - это сетевой адрес процесса (Net Address Process - NAP), так сказать.

Вы перешли к практическим аргументам, я не указал в самом начале, что я имел в виду теоретические возможности. Посмотрите на радикальное сравнение: допустим у нас есть только UDP, и нет TCP, и представьте что у нас есть только TCP и нет UDP.
UDP универсальнее, он не ограничивает так, как ограничивает TCP. Это имелось в виду, поэтому он лучше, только в этом, это не означает, что он сразу даёт требуемый функционал, имелась в виду теоретическая причина, что UDP прекрасно подходит для создания своего протокола.
Вы смотрели на практику, я на теорию.

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

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

0