The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

W3C начал подготовку старндарта WebTransport, opennews (??), 07-Май-21, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


28. "W3C начал подготовку старндарта WebTransport"  +/
Сообщение от Аноним (28), 07-Май-21, 12:32 
С другой стороны, например ненадежный канал штука полезная. Какие-нибудь не особо критичные вещи, типа, допустим heartbeat или апдейта температуры с вон того сенсора так вполне логично пулять. Прикиньте, температура эн-минутной давности при доступности актуальной - могла уже и не интересовать, так что про#$%ть ее вполне ОК.

А если допустим связь отпала, TCP вытворит нечто совершенно непотребное, во первых выпав в идиотские таймауты что абсолютно фатально для (около)реалтаймных с одной стороны, а во вторых забуферив кучу опциональщины которую можно было профакать и всем чихом потом #$%нув это на сервер из вооооооон того буфера сокета на добрвй мег, когда линк восстановится. Это порой вызывает интересные эффекты, когда кого-то раз в год сервер банит нахрен на ровном месте за "флуд запросами". Так то сервера должны себя защищать от агрессивных клиентов, иначе их DoS'ить могут видите ли, но порой "якобы агрессивные" клиенты случаются за счет вот такой вот ломовой буферизации при временном отвале мобильного линка и т.п..

Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

43. "W3C начал подготовку старндарта WebTransport"  +3 +/
Сообщение от YetAnotherOnanym (ok), 07-Май-21, 13:07 
То есть, это tcp плохой и виноват в том, что вы используете его для задачи, для которой он не предназначен?
И ещё - если у вас бабахнет жбан, в котором варились десятки тонн какой-нибудь отравы, то для последующего разбора полётов принципиально важно узнать, росла ли температура (а также давление, скорости подачи ингредиентов и всякое такое) медленно, или вдруг подскочила ни с того ни с сего на ровном месте.
Ответить | Правка | Наверх | Cообщить модератору

47. "W3C начал подготовку старндарта WebTransport"  +/
Сообщение от Аноним (-), 07-Май-21, 13:31 
То-есть вот прямо здесь и сейчас, в браузерах - на минуточку - Форд может быть любого цвета, при условии что он черный, а протокол TCP-based. И вон то из TCP при всем желании особо не делается.

Вот сделать из UDP кастомное подобие TCP - без вопросов. А наоборот вообще совсем нет. Очевидно, по этой причине браузеры сейчас толком неспособны к околореалтаймным или ненадежным линкам в нормальном виде.

> И ещё - если у вас бабахнет жбан, в котором варились десятки тонн какой-нибудь отравы

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

Поэтому таки околореалтаймные вещи типа телеметрии в том числе пуляют и не очень надежными методами, по мере получения данных. Ну как, в случае #$%са лучше получить хоть какие-то данные зеброй с выпадениями, зато близко к реалтайму, по мере фактической живости линка, чем вообще совсем ничерта. Так АКТУАЛЬНОЕ состояние объекта ЗДЕСЬ И СЕЙЧАС может быть сильно понятнее чем его буферизованый лог на пару минут который может вообще никогда никуда не прилететь.

p.s. а вон у элонмаска udp:// на видео с ракеты отклеился, инетовский айпишник при том :). И если что, у него хватает ума слать телеметрию отдельным low-bandwidth линком, так что когда видео отпадает из-за неидеальностей линка телеметрия все же сильно более живуча. Но у нее и бандвиз иной, так что и линк низкоскоростной зато трудноубиваемый.

Ответить | Правка | Наверх | Cообщить модератору

52. "W3C начал подготовку старндарта WebTransport"  +1 +/
Сообщение от Онаним (?), 07-Май-21, 13:39 
> браузеры сейчас толком неспособны к околореалтаймным или ненадежным линкам

Не задумывался, почему?
Потому что БРАУЗЕРЫ.

Ответить | Правка | Наверх | Cообщить модератору

62. "W3C начал подготовку старндарта WebTransport"  +/
Сообщение от Аноним (-), 07-Май-21, 13:57 
Да, а вон то - космический корабль элонмаска. И у него на морде браузер. Ну да, дублированый более надежными системами, ибо понт понтом а надежность надежностью.

И таки знаешь, мне и со стороны сервера так-то удобнее в клиента пульнуть апдейт каких там температур-статусов, а если это профакалось - ну, получит через цать секунд актуальный отсчет, если линк ожил. А вот буферизовать мег гамна которое допустимо профакать - оперативу жрет, если клиентов много. Особо ушлые программы по этому поводу делают очень навороченый кастомный менеджмент буферов и даже форс-дисконект клиента когда тот закончился, но это сложно, hard to get it right, так умеют очень немногие программы, и в ряде случаев можно вместо всего этого миндфака просто пульнуть данные, а если их не поймали - ну и черт с ними, попозже получат апдейт состояния еще раз. А резко парсить все отсчеты за последние цать минут "потому что линк вернулся" так себе радость.

Ответить | Правка | Наверх | Cообщить модератору

68. "W3C начал подготовку старндарта WebTransport"  +/
Сообщение от Онаним (?), 07-Май-21, 14:01 
В случае браузера весь этот майндфак по сути не оправдан.
По поводу "особо ушлых" - это и есть ответ по сути.
Для майндфака есть клиент, который знает, зачем ему это, и как с этим жить.
Ответить | Правка | Наверх | Cообщить модератору

82. "W3C начал подготовку старндарта WebTransport"  +/
Сообщение от Аноним (82), 07-Май-21, 14:23 
> В случае браузера весь этот майндфак по сути не оправдан.

В случае браузеров прямо сейчас...
- Вообще нет настоящих message-based протоколов.
- С хоть каким-то подобием околореалтайма или опциональщины полный аут.

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

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

Тем не менее, еще основатели интернета показали каким это должно быть на самом деле. И это даже мегакорпы типа гугла понимают. Хотя-бы потому что проксировать через себя терабайты хомячкового крапа, особенно типа видео, дороговато когда хомяков миллиарды, а напрямую их сконектить именно что майндфак в этом вашем v4. Изначально оно было так и задумано, но с 32 битами на адрес вышел эпикфейл, IP-capable устройств уже больше чем 2^32...

Ответить | Правка | Наверх | Cообщить модератору

83. "W3C начал подготовку старндарта WebTransport"  +/
Сообщение от Онаним (?), 07-Май-21, 14:30 
Тем не менее, весь гугл прекрасно работает через v4 :D
Ответить | Правка | Наверх | Cообщить модератору

87. "W3C начал подготовку старндарта WebTransport"  +/
Сообщение от Аноним (-), 07-Май-21, 14:40 
> Тем не менее, весь гугл прекрасно работает через v4 :D

1) Понятия о прекрасном у всех разные.
2) Классика по Форду про более быстрых лошадей во весь рост. Ну а им вот западло лошадей выводить когда, вот, нащупался вариант авто на конвейере собрать...

Ответить | Правка | Наверх | Cообщить модератору

95. "W3C начал подготовку старндарта WebTransport"  +1 +/
Сообщение от Жироватт (ok), 07-Май-21, 15:19 
Хм. А чегой-та так полыхнуло, если браузер предназначен для работы в режиме "собрал и загрузил интерактивный документ из кучи файлов, скриптов, картинок и б-г знает чего еще - отрисовал интерактивный документ, интегрировав все в 1 хтмл"? Причем тут реалтаймовые значения датчиков, если с ними на низком уровне работает специальная кэширующая (и увязывающая в БД) софтина, у которой изначально стояла цель НЕ "скачать документ-отрисовать документ", а обработка пакетов в реальном времени (приходящих откуда угодно - с СОМ, с UART, с промышленной сетки по самописному протоколу на уровне или ниже чем пресловутый TCP)?
Ответить | Правка | Наверх | Cообщить модератору

152. "W3C начал подготовку старндарта WebTransport"  +/
Сообщение от Аноним (-), 08-Май-21, 09:41 
> Хм. А чегой-та так полыхнуло, если браузер предназначен для работы в режиме

В режиме панели управления космического корабля - больше соответствует наблюдаемой реальности.

> 1 хтмл"? Причем тут реалтаймовые значения датчиков, если с ними на
> низком уровне работает специальная кэширующая (и увязывающая в БД) софтина,

А юзер, особенно ремотный, все-равно зачастую захочет и будет видеть нечто такое как-то так. И я не понимаю почему веб должен быть принципиально обделен на message-based протоколы, которые там сейчас вообще принципиально не реализуемы в нормальном виде из-за завязки на TCP.

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

> у которой изначально стояла цель НЕ "скачать документ-отрисовать документ", а обработка
> пакетов в реальном времени (приходящих откуда угодно - с СОМ, с
> UART, с промышленной сетки по самописному протоколу на уровне или ниже
> чем пресловутый TCP)?

Спасибо, я в куре и протоколов такого плана видел поболее вашего, и даже свои иногда запиливаю. А вот TCP я таки недолюбливаю за характетный букет дурацких свойств. И в частности из него принципиально нельзя сделать message-based протокол. Более того, делать даже какой-нибудь чатик как stream а не message based вообще-то является инженерной идиотией, называя вещи своими именами. Просто людям приходится натягивать сов на глобус т.к. по другому их "подложка" не умеет. А тут вот идея научить и веббраузеры этому наконец.

Ответить | Правка | Наверх | Cообщить модератору

175. "W3C начал подготовку старндарта WebTransport"  +/
Сообщение от Dzen Python (ok), 08-Май-21, 11:54 
1. Не космического корабля, а ракеты-носителя Маска, если ты об этом. Чей путь вполне одноразов и крайне ограничен по времени чистой эксплуатации на приборах. Почему на МКС/китайской что-там-они-выводят-прямо-сейчас такого нет? Там-то оно показало свою надежность во всей красе - длительный срок эксплуатации, невозможность держать фуллстак-веб-макаку рядом, обработка космических задержек при связи с землей. Может быть НЕ Маску не плевать на своих граждан, им нужно гарантированная реакция на показания сотни тысяч раз выверенных и оттьюстированных приборах, не? Пример неудачный, на уровне "Если роскосмос повесит в транспорного робота Протона крестик, чтобы по мнению мужика в рясе оно не разбилось о небесную твердь - значит гимнаста надо вешать везде".

2. А юзер, особенно ремонтный будет видеть ровно то, что наваяли ему разрабы или он сам в качестве гуя, хотя бы результаты грепа текстового лога. Юзеру, особенно ремонтному, на самом деле достаточно грепа и текстового лога. А софтине, на низком уровне агрегирующей пакетвы откуда удобно вообще все равно, на чем based протокол - в нормальной архитектуре оно вообще вынесено в динамические модули.

3. Еще раз. Веб работает на потоках байтов не потому, что страшные жидорептилоиды хотят поглумиться или инженеры настолько тупы, что не видят назревшую в нем необходимость. Нет. Иначе даже потоковое вещание того же IPTV было бы не поверх UDP, а через установку сессий TCP. Уже два человека тебе талдычат, что браузер - программа, загружающая кучу файлов, а затем, с взаимодействием с сервером рисующая из них красивый документ в хтмл. Все. Он для этого не предназначен бай дизайн. Твои "терабайтные кэши" - в реальных сценариях гарантированной доставки не играют особой роли. То, что поколение зумеров привыкло использовать браузер как ОС, а не как инструмент веба - это проблемы уже конкретных зумерков.

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

Ответить | Правка | Наверх | Cообщить модератору

188. "W3C начал подготовку старндарта WebTransport"  +/
Сообщение от Аноним (-), 09-Май-21, 07:40 
> 1. Не космического корабля, а ракеты-носителя Маска, если ты об этом.

Я о сенсорной панели корабля SpaceDragon в которую космонавты пальцетыкают. См. новость на опеннете и видео запуска.

> Чей путь вполне одноразов и крайне ограничен по времени чистой эксплуатации

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

> приборах. Почему на МКС/китайской что-там-они-выводят-прямо-сейчас такого нет?

А посмотришь на интерьер SpaceDragon'а и скафандры, и понимаешь где будушее наступило и где оно делается людьми, для людей.

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

Вебморда там гламурный интерфейсик к бортовым системам, продублированный. И все же есть такой юзкейс.

> Может быть НЕ Маску не плевать на своих граждан

Странно что автомобили не выкинули - телеги по началу были сильно надежнее. Но потом технологию отладили и где ваши телеги теперь?

> им нужно гарантированная реакцияна показания сотни тысяч раз выверенных
> и оттьюстированных приборах, не?

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

> вообще все равно, на чем based протокол - в нормальной архитектуре
> оно вообще вынесено в динамические модули.

Поэтому до большинства земных юзерей все эти прелести никогда не долетят. Я не понимаю, почему веб должен принципиально быть обделен на message-based, где надежность, in-order и квитирование таки опциональны.

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

Как показал пример сабжа - уже таки видят.

> было бы не поверх UDP, а через установку сессий TCP.

Ну, вообще, ютуб примерно так и работает...

> Уже два человека тебе талдычат, что браузер - программа, загружающая кучу файлов,

Наблюдаемые факты в виде морды корабля элонмаска не объясняются этой теорией. Значит она никуда не годится.

> "терабайтные кэши" - в реальных сценариях гарантированной доставки не играют особой роли.

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

> То, что поколение зумеров привыкло использовать браузер как ОС, а
> не как инструмент веба - это проблемы уже конкретных зумерков.

Все это не объясняет почему веб такой особенный что должен быть обделен на message based протоколы, которые там невозможно реализовать нормально. Пока еще.

> 4. Мерятся не стоит, а то попрошу пустить к тебе на реальное
> производство, посмотреть на эти самописные решения. Просто сравнить, в чем они
> отличаются от моих самописных решений.

На самом деле, я и сам не фанат вебмакакинга и запихивания все и вся в браузер. Однако даже для меня вон те фичи, пожалуй, найдут пару юзкейсов. Просто в данном случае я признаю за инженерами гугла некий пойнт. А что в этом такого? Я обязан из вредности отмораживать уши назло бабушке, только потому что это гугл озвучил?

Ответить | Правка | К родителю #175 | Наверх | Cообщить модератору

139. "W3C начал подготовку старндарта WebTransport"  +/
Сообщение от YetAnotherOnanym (ok), 07-Май-21, 22:23 
Ну, как бы, чёрная краска не виновата в бизнес-решениях Форда, ровно так же tcp не виноват в том, что какие-то крети... умники придумали гонять видео через http.
Ну, и насчёт жбана - получилось, как будто я за то, чтобы в телеметрии использовать именно tcp. Я просто возражал против того, что с потерянными данными можно пренебречь.
Ответить | Правка | К родителю #47 | Наверх | Cообщить модератору

153. "W3C начал подготовку старндарта WebTransport"  +/
Сообщение от Аноним (-), 08-Май-21, 10:31 
> Ну, как бы, чёрная краска не виновата в бизнес-решениях Форда, ровно так
> же tcp не виноват в том, что какие-то крети... умники придумали

На какой там год до них доперло что это не очень хорошо работает для некоторых вещей. Алилуя.

> гонять видео через http.

С цифровым видео есть фирменная проблема: терять пакеты - оскорбляет современные кодеки, где error resilence по остаточному принципу. Посмотреть что я имею в виду можно на свежей трансляции элонмаска, где видно что линк не выдюжил, а error resillence местами работал "как обычно". Т.е. порушив картинку и вызвав дерг и шевеление. Что-то серенькое и шевелится. Много толку с такого видео, хоть оно и реалтаймное? Кодек танцует от порушеного кадра, покаааа там еще новый I-frame получит, чтобы нейтрализовать, молитесь чтобы за это время ничего не выпало, особенно на новом жирном I-frame, иначе будет то же самое.

> Ну, и насчёт жбана - получилось, как будто я за то, чтобы
> в телеметрии использовать именно tcp. Я просто возражал против того, что
> с потерянными данными можно пренебречь.

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

А проблема браузеров - в том что они с этим дурацким TCP вообще совсем не имеют контроля над такими вещами. Ну вот не делается из поточного протокола, all inclusive, какой либо кастом...

Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру