Agile
конечно нет: there is no guarantee of delivery, ordering, or duplicate protection (https://en.wikipedia.org/wiki/User_Datagram_Protocol)
А ничего, что UDP не обеспечивает гарантированной доставки?
TCP не справится с объемом данных, поэтому гибрид:
UDP для котировок (см. схему и текст на стр. 9-10),
https://www.eurexchange.com/resource/blob/1470872/a9e0d336...
TCP для информации по своим ордерам/сделкам (ETI),
https://www.eurexchange.com/resource/blob/1394340/e8b4cc73...
Канбан отлично работает на поддержке - баги фиксить и инциденты закрывать. Ну или для задач "а теперь то же самое, но розовенькое". Как только что-то новое, которое команда ещё не делала и канбан сыпется, на доске чёрт знает что, или новым занимается один-единственный разработчик, а остальные радостно проводят другие тикеты.
Вот я и удивляюсь:
коммерческая инфа без гарантии доставки?
По Вашему это допустимо с точки зрения логики?
Именно с точки зрения логики это не только допустимо но и необходимо.Другой пример это eventual consistency, ну типа все будет ok, но это не точно. Так что все эти ACIDы и гарантии это уже давно религиозные предрассудки ну или для распальцовки среди тех, кто в этом ничего не смыслит.
Вообще, слухи про ненадежность UDP сильно преувеличены. Если с сетью все нормально, то получишь ты свой пакет и "усе будет в лучшем виде". А если не получишь, значит в сети затор, но тады и TCP тебя не спасет - он будет тупо ждать пропавшие части, и повторно их запрашивать (чем еще больше усугублять ситуация). Гарантия TCP это типа как гарантия доставки пиццы в городе в случае пробок: гарантия у тебя есть, а пиццы нет.
Если немного пофлудить, то в наше время все эти fault tolerance, high availability, scalability, consistency, ACID и пр. заклинания, это часто от лукавого менеджеров с целью раздуть бюджет. (За что им конечно огромное прагматическое спасибо.) Это типа как при строительстве дорог раздувают бюджет: тут надо гидро-пневмо-анализ на 10 км в глубину сделать, там изучить влияние дороги на частоту сношений в семье бобров на соседней реке, а также специальное покрытие против свечения метеоритов, если таковые будут падать. А для всего этого сверху нам надо еще скрам, чтобы при максимально раздутом бюджете, еще и максимально сократить расходы за счет
толпы быдлокодеров, которые слепо верят, что это и есть программистская вальгалла.
Так что все эти ACIDы и гарантии это уже давно религиозные предрассудки ну или для распальцовки среди тех, кто в этом ничего не смыслит.
Толсто. Хочется пожелать чтобы лично ваш банк думал так же, ну и те же билеты на самолёт чтобы вы покупали через системы, разработанные такими же не страдающими религиозными предрассудками.
Если немного пофлудить, то в наше время все эти fault tolerance, high availability, scalability, consistency, ACID и пр. заклинания, это часто отлукавогоменеджеров с целью раздуть бюджет.
А тут согласен. Часто всё это не надо. Надо уметь понимать когда надо а когда - нет. (p.s. partition tolerance незаслужено забыто)
Вообще, слухи про ненадежность UDP сильно преувеличены. Если с сетью все нормально, то получишь ты свой пакет и "усе будет в лучшем виде".
Ну как бы нет... Лет 30 назад может быть. А сегодня TCP может летать через рутер, а UDP ползти с потерей половины пакетов. Очень они умными стали, то приоритеты TCP выставлены, то QoS решит что важнее вот эти пакеты отправить, а UDP оно ж не важно, потом. А потом буфер для UDP переполнился и всё, нет пакетов.
Прохождение UDP датаграм сильно зависит от сетевого железа. Например, на роутере DLink серии DI достаточно просто переполнить 8кб буфер для того чтобы пакеты UDP вообще перестали ходить по сети.
На роутерах Zyxel UDP может просто внезапно перестать ходить без видимых причин.
Можно очень долго отлаживать софт, сидя под одним роутером, а потом когда компания купит другой роутер, все придется повторно переотлаживать... Поведение UDP нерегламентировано

