PIC32 Bootloader V1.2 почему UDP протокол?

[vladtv]

Собственно вопрос в названии темы, почему для обновления прошивки через Ethernet выбран протокол UDP, а не TCP.

[Vint]

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


udp - это простое бесконтрольное пихалово
данных в приемник. а здесь надо непрерывно
и быстро. tcp - начнет проверять доставку и т.д.
процесс рвется на куски.

[besogon]

vladtv
если boot flash 12 KiB(а то и 3КiB), то в него может не влезть TCPIP.

[Pridnya]

Сообщение от Vint

udp - это простое бесконтрольное пихалово
данных в приемник. а здесь надо непрерывно
и быстро. tcp - начнет проверять доставку и т.д.
процесс рвется на куски.

UDP - простой и удобный протокол поверх TCP/IP, а контроль за доставкой (при необходимости) осуществляется на стороне приемника. Это вам не простое "простое пихалово".

Сообщение от besogon

vladtv
если boot flash 12 KiB(а то и 3КiB), то в него может не влезть TCPIP.

Вот это ближе к истине - код UDP-сервера компактнее.

[Vint]

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

[Pridnya]

Сообщение от Vint

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

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

А вы вообще в своей практике использовали UDP протокол? В расширенном поиске набрал "Vint" "UDP". Вы за почти 12 лет на форуме дважды про UDP упомянули - в 2008 году и в 2019 году (в этой ветке, сегодня). Провал какой-то.
PS: Был знаком с программистом, который использовал PIC32, но никогда не работал с TCP/IP (Цифровые входы, выходы, АЦП и RS485). А на вопрос "а почему PIC32" ответ - а на нем проще, чем на PIC18, PIC24, памяти много.

[Vint]

давайте все перйдем на pic16 с ультрафиолетовым стиранием
и на асемблер, чтобы память не занимать...


а для tcp делал и делаю, спросили бы, зачем
следствие открывать.

[pal1222@yandex.ru]

Сообщение от Vint

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

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