The OpenNET Project / Index page

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



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

Оглавление

Для Chrome развивается API для прямых TCP и UDP коммуникаций, opennews (??), 22-Авг-20, (0) [смотреть все]

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


3. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"  +46 +/
Сообщение от Michael Shigorinemail (ok), 22-Авг-20, 12:06 
Гуголь -- ведущий специалист по ящикам Пандоры.
Ответить | Правка | Наверх | Cообщить модератору

66. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"  –2 +/
Сообщение от Константавр (ok), 22-Авг-20, 18:04 
Интересно, есть ли у пользователя возможность всё это блокировать? И даже не на уровне браузера, а на уровне операционки хотелось бы.
Ответить | Правка | Наверх | Cообщить модератору

67. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"  +1 +/
Сообщение от n80 (?), 22-Авг-20, 18:25 
> Интересно, есть ли у пользователя возможность всё это блокировать? И даже не
> на уровне браузера, а на уровне операционки хотелось бы.

Можно начать с man firejail. Хотя лучше, конечно, начать с конкретизации того, что именно подразумевается под «всё это».

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

69. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"  +1 +/
Сообщение от гугль (?), 22-Авг-20, 18:50 
есть, только ни один сайт кроме опеннета работать не будет.

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

167. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"  +/
Сообщение от rvs2016 (ok), 25-Авг-20, 16:09 
> И даже не на уровне браузера, а на уровне операционки хотелось бы.

Слово "операционка" знают только такие старики, как мы.
А остальным вместо "операционка" говорят - "прошивка"! 😲

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

74. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"  –5 +/
Сообщение от КПСС (?), 22-Авг-20, 20:15 
А ведь у Миши куча альтернатив. Тока сд-диски с ними не читаются.
Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

76. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"  +15 +/
Сообщение от Тот_Самый_Анонимус (?), 22-Авг-20, 21:00 
Нелюбовь к Шигорину настолько велика, что заставляет критиковать верные его утверждения. И ведь в нашей стране вся оппозиция такая.
Ответить | Правка | Наверх | Cообщить модератору

129. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"  +/
Сообщение от Аноним (129), 23-Авг-20, 15:24 
Мы воюем с людьми, а не с идеями. Если П*тин скажет "не жрать младенцев" - тем хуже для младенцев.
Ответить | Правка | Наверх | Cообщить модератору

145. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"  +2 +/
Сообщение от Брат Анон (?), 24-Авг-20, 08:50 
Давай-ка, брат анон -- за себя. Столько ответственности берёшь, что не унесёшь.
Ответить | Правка | Наверх | Cообщить модератору

149. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"  –2 +/
Сообщение от Аноним (129), 24-Авг-20, 12:27 
Кто не готов брать на себя ответственность - так и останется ведомым барашком в стаде.
И отправится с остальным стадом на заклание, если ответственные люди решат, что так лучше.
Ответить | Правка | Наверх | Cообщить модератору

199. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"  +1 +/
Сообщение от Брат Анон (?), 26-Авг-20, 11:08 
> Кто не готов брать на себя ответственность - так и останется ведомым
> барашком в стаде.

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

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

204. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"  –1 +/
Сообщение от Тот_Самый_Анонимус (?), 03-Сен-20, 08:00 
> Ещё раз тебе повторяю: отвечай за себя. Я уже давно половозрелый мальчик.

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

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

112. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"  +1 +/
Сообщение от Kusb (?), 23-Авг-20, 09:23 
Я умею читать сд-диски. Но только там, где надписи и этикетка.
Ответить | Правка | К родителю #74 | Наверх | Cообщить модератору

152. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"  +/
Сообщение от Аноним (-), 24-Авг-20, 14:08 
>сд-диски с ними не читаются.

это Вы что сейчас написали - короткое SMS-сообщение, да?

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

154. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"  +3 +/
Сообщение от Аноним (154), 24-Авг-20, 15:41 
"Гуголь" не изобрел ничего нового. Просто поймите, в корпоративном сегменте в 2020-ом году одновременно окончательно умирают Internet Explorer и лучший друг его Flash Player. Тем временем задачи, которые решала эта парочка никуда не умирают и не могут быть портированы даже на WebSocket.

Нет, ну, если вы критикуете, то предлагайте, ну или хотя бы участвуйте в обсуждениях. ИМХО, уж лучше переделать адаптировать сокеты Flash Player под новую реальность и адаптировать концепцию доверенных зон сайтов из IE (хром, на минуточку, её уважает), чем продолжать использовать IE и Flash в 2021-ом.

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

Все эти технологические решения помимо бизнес-приложений тянет VoIP. В мире VoIP необходимо не просто замерить MOS, важно разделить его на отрезки. Как вы поймете причину деградацию WebRTC-звонка без анализа потерь на отрезке Браузер <-> Блютус-гарнитура? В условиях, когда используется протокол ICE, необходимо по факту завершения звонка понять, где была деградация. Веб приложение и его Rich Client должны по-разному действовать, если у человека гарнитура разряжается или есть проблема с TURN сервером, через который пошел медиапоток или там вообще TURN-сервера нет и проблема на стыке двух ISP или может во всем виноват IPv6, который работает на клиенте, но имеет высокий Jitter по вине рукопопости провайдера последней мили. И как прикажете принимать такие решения без доступа к Bluetooth?

Ну и я не говорю о том, что в связи с грядущим RTP over QUIC https://tools.ietf.org/html/draft-rtpfolks-quic-rtp-over-qui...
Я даже не уверен, что в реалиях HTTP3 от самого WebRTC вообще что-то останется, потому что не понятно, зачем сигнализацию тогда уже гнать отдельно, да и это API в сочетании с QUIC в перспективе отправляет на свалку весь WebSocket.

Я даже не предлагаю сделать лучше, хотя бы предложите.

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

155. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"  +/
Сообщение от freehckemail (ok), 24-Авг-20, 17:06 
Плюсую. Данный аноним дело говорит. Раньше Flash предоставлял возможности работы с TCP/UDP-сокетами. Этим пользовались, и до сих пор пользуются. В частности, многие flash-игры с клиент-серверной архитектурой зависят от этого функционала: и одно дело переписать клиент, потому как flash умер де факто, а совсем другое -- переписать ещё и сервер, потому что старый протокол общения уже никак не реализовать. Это уже другие деньги, и подобная инициатива, быть может, спасёт малые проекты, которые не могут себе позволить столь масштабные изменения.
Ответить | Правка | Наверх | Cообщить модератору

162. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"  +/
Сообщение от Аноним (162), 24-Авг-20, 20:36 
> Я даже не предлагаю сделать лучше, хотя бы предложите.

Сделать из браузера ChromeOS или есть же Android.
И да, сделать лучше, кому? ;)

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

168. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"  +/
Сообщение от rvs2016 (ok), 25-Авг-20, 16:14 
> Тут главное, чтобы был выдан запрет на всё это по умолчанию,
> если разрешение не выдано явно

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

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

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

211. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"  +/
Сообщение от Аноним (-), 09-Янв-21, 17:09 
Как они представляют себе вообще запросы к DHT c подтверждениями? Это ж каждую секунду по десяток подтверждений во все стороны придется.
Ответить | Правка | Наверх | Cообщить модератору

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

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




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

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