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

Для Chrome развивается API для прямых TCP и UDP коммуникаций, opennews (??), 22-Авг-20, (0) [смотреть все] Ддос-боты на жаваскрипте уже были Теперь точно будут, Аноним (1), 11:57 , 22-Авг-20, (1) +32 Звучит адски опасно Нужно блокировать , Аноним (2), 12:02 , 22-Авг-20, (2) +31 Гуголь -- ведущий специалист по ящикам Пандоры , Michael Shigorin (ok), 12:06 , 22-Авг-20, (3) +46 // Интересно, есть ли у пользователя возможность всё это блокировать И даже не на , Константавр (ok), 18:04 , 22-Авг-20, (66) –2 // Можно начать с man firejail Хотя лучше, конечно, начать с конкретизации того, ч, n80 (?), 18:25 , 22-Авг-20, (67) +1 есть, только ни один сайт кроме опеннета работать не будет , гугль (?), 18:50 , 22-Авг-20, (69) +1 Слово операционка знают только такие старики, как мы А остальным вместо опера, rvs2016 (ok), 16:09 , 25-Авг-20, (167) А ведь у Миши куча альтернатив Тока сд-диски с ними не читаются , КПСС (?), 20:15 , 22-Авг-20, (74) –5 // Нелюбовь к Шигорину настолько велика, что заставляет критиковать верные его утве, Тот_Самый_Анонимус (?), 21:00 , 22-Авг-20, (76) +15 // Мы воюем с людьми, а не с идеями Если П тин скажет не жрать младенцев - тем х, Аноним (129), 15:24 , 23-Авг-20, (129) Давай-ка, брат анон -- за себя Столько ответственности берёшь, что не унесёшь , Брат Анон (?), 08:50 , 24-Авг-20, (145) +2 Кто не готов брать на себя ответственность - так и останется ведомым барашком в , Аноним (129), 12:27 , 24-Авг-20, (149) –2 Ещё раз тебе повторяю отвечай за себя Я уже давно половозрелый мальчик , Брат Анон (?), 11:08 , 26-Авг-20, (199) +1 Возможно и половозрелый Тогда должен понимать что большинство протестунов именн, Тот_Самый_Анонимус (?), 08:00 , 03-Сен-20, (204) –1 Я умею читать сд-диски Но только там, где надписи и этикетка , Kusb (?), 09:23 , 23-Авг-20, (112) +1 это Вы что сейчас написали - короткое SMS-сообщение, да , Аноним (-), 14:08 , 24-Авг-20, (152) Гуголь не изобрел ничего нового Просто поймите, в корпоративном сегменте в 20, Аноним (154), 15:41 , 24-Авг-20, (154) +3 // Плюсую Данный аноним дело говорит Раньше Flash предоставлял возможности работы, freehck (ok), 17:06 , 24-Авг-20, (155) Сделать из браузера ChromeOS или есть же Android И да, сделать лучше, кому , Аноним (162), 20:36 , 24-Авг-20, (162) Идея запроса разрешений у пользователя в основном бесполезна потому, что когда д, rvs2016 (ok), 16:14 , 25-Авг-20, (168) // Как они представляют себе вообще запросы к DHT c подтверждениями Это ж каждую с, Аноним (-), 17:09 , 09-Янв-21, (211) localhost уже не безопасно , Аноним (4), 12:07 , 22-Авг-20, (4) // давно уже с читым tcp udp это вообще кошмар будет - локалки и прочие дмз будут , Аноним (9), 12:18 , 22-Авг-20, (9) +3 // если что dmz бывают хоть и редко с globally routable адресами, Аноним (9), 12:57 , 22-Авг-20, (14) Оно без спросу не полезет Ну и для админов всегда оставляли возможность отключи, Онаним (?), 21:55 , 22-Авг-20, (78) // ну да а потом читаем что-то типа WebRTC leak local address, admgoat (?), 06:43 , 23-Авг-20, (103) +2 Меня всегда удивляло пещерное скудоумие вокруг этой темы, но, видимо, это неизбе, Аноним (154), 21:47 , 25-Авг-20, (187) вкключи WebRTC и отключи UBO и зайди сюда https browserleaks com webrtcпоявил, admgoat (?), 03:44 , 26-Авг-20, (196) –1 Прочитай то что написано выше Оно ДОЛЖНО выдать твой серый IP Это протокол так, Аноним (154), 11:57 , 26-Авг-20, (200) Все запросы и подтверждения будут выпилены через пару релизов Chrome для улучшен, Аноним (129), 15:25 , 23-Авг-20, (130) +3 Не пора ли вернутся к истокам выкинуть из браузеров все кроме html Остальное т, аноним еще один (?), 12:08 , 22-Авг-20, (5) +19 // Вот-вот Предполагаю, что все те два десятка действительно полезных применеий Яв, A.Stahl (ok), 12:18 , 22-Авг-20, (11) // сортировку таблиц тормозным жабаскриптом можно заменить нативной сортировкой с а, Ананимас008 (?), 05:35 , 23-Авг-20, (99) +1 XMLHttpRequest надо , admgoat (?), 06:44 , 23-Авг-20, (104) –3 // form action method тебе хватит , A.Stahl (ok), 07:24 , 23-Авг-20, (108) не хватит каким образом мне избежать сабмита формы и перезагрузки страницы , admgoat (?), 13:23 , 23-Авг-20, (120) Никак Да и не надо это Странная хотелка-то изначально , A.Stahl (ok), 14:06 , 23-Авг-20, (123) Еще скажи что все эти RIA приложение или как они там писанные на Angular и React, Аноним (159), 19:36 , 24-Авг-20, (159) аргументы будут или продолжишь фуфло свое пихать , admgoat (?), 19:10 , 25-Авг-20, (182) –1 Он же существует не первый десяток лет Вот XMLHttpListen ListenPort, callback д, rvs2016 (ok), 16:19 , 25-Авг-20, (169) А для чего нужен-то, какую распространённую задачу предполагается решить , n80 (?), 17:04 , 25-Авг-20, (176) Вот тут в разделе в конце сообщения в разделе вот зачем я привёл пример одной , rvs2016 (ok), 17:45 , 25-Авг-20, (178) Угу, я там ответил более-менее подробно, если что 8212 могу ещё постараться р, n80 (?), 18:09 , 25-Авг-20, (180) +1 так прошла говноидея его отменить а слушать порт не получится кто будет его, admgoat (?), 19:09 , 25-Авг-20, (181) Как связаться с за-NAT-овскими браузерами - дайте программисту возможность пореш, rvs2016 (ok), 19:58 , 25-Авг-20, (184) Уже давали Один FTP на самом деле ещё IRC, SIP и ещё пачка протоколов, 171 з, n80 (?), 21:08 , 25-Авг-20, (186) что за абсурд вы несете сударь бразуер предоставляет апи, которое не работает , admgoat (?), 03:48 , 26-Авг-20, (197) Часть CSS всё равно придётся оставить , Аноним (12), 12:27 , 22-Авг-20, (12) // Выкинуть вместе с жабаскриптом и вернуться к запросу на каждое изменение поля вв, Онаним (?), 13:29 , 22-Авг-20, (20) –3 // CSS это как отображать, а HTML что отображать Т е Жабоскрипту оно, как-то, орт, Аноним (22), 13:33 , 22-Авг-20, (22) +5 Не важно, всё равно выкинуть Какой ещё вам CSS, и даже пропертю style выкинуть , Онаним (?), 21:56 , 22-Авг-20, (79) Только plane text, только хардкор , Навальный (?), 09:10 , 24-Авг-20, (147) Хардкор то твой английский , A.Stahl (ok), 09:11 , 25-Авг-20, (165) Gopher - , rvs2016 (ok), 16:21 , 25-Авг-20, (170) Который научили делать почти всё, что делалось жабаскриптом, Онаним тот самый (?), 13:30 , 22-Авг-20, (21) –2 Пришло время вернуться в Фидонет , Козлетто (?), 14:47 , 22-Авг-20, (36) –1 // Gopher , Аноним (45), 15:43 , 22-Авг-20, (45) // Hamster Xhamster , A.Stahl (ok), 15:48 , 22-Авг-20, (46) отключить розетку , asdf (?), 16:23 , 22-Авг-20, (51) +2 Обязательно гипертекстовый, как вещает камрад Мицгол , Аноним (85), 23:24 , 22-Авг-20, (85) // Ну велком че https github com vit1251 golden, Аноним (159), 19:37 , 24-Авг-20, (160) Проще выкинуть html , Fff (?), 16:21 , 22-Авг-20, (50) +3 // Ну да Есть же емайл До сих пор жив Хотя молодёжь со своими вацапо-инстаграмам, rvs2016 (ok), 16:22 , 25-Авг-20, (171) –1 Да и html стоит заменить на что-то более лаконичное и человекопонятное, вроде QM, Аноним (124), 14:20 , 23-Авг-20, (124) –2 Да как бы гофер всё ещё существует Бога ради, пользуйтесь Там правда нет нифиг, freehck (ok), 17:10 , 24-Авг-20, (156) учитывая что localhost часто не фаерволится и вообще открыто всё будет интере, grayich (ok), 12:11 , 22-Авг-20, (6) +3 И это говорят эксперты Гугла Как это защитит сервер от клиентов, собранных без , Аноним (7), 12:15 , 22-Авг-20, (7) +3 // Что значит собранного без этого говнокода Если клиент собрал другое вместо ус, Cred (??), 02:24 , 23-Авг-20, (91) +1 Действительно, не подумали как-то Значит придётся закрыть исходники , Аноним (119), 11:10 , 23-Авг-20, (119) +1 Я и в прошлый раз говорил, и сейчас говорю - вебсокетс кривое поделие студентов , Урри (?), 12:18 , 22-Авг-20, (8) +1 // Если и менять, то на что-то ещё более кривое и убогое Надеюсь, гугл и в этот раз, Аноним (129), 15:28 , 23-Авг-20, (131) То есть простые сокеты не безопасны, давайте добавимв веб сокеты , Аноним (10), 12:18 , 22-Авг-20, (10) // Им нужна прибыль, а это новые приложения, а на вашу безопасность они сс , Аноним (84), 22:35 , 22-Авг-20, (84) +3 В помощь т майору для деанонимизации пользователей в луковых сетях , Аноним (22), 12:55 , 22-Авг-20, (13) +1 В каких браузерах это можно будет отключить , user (??), 13:09 , 22-Авг-20, (15) –1 // пс я из будущего, в тех в которые дабавят это Апи и функцию его отключения, Аноним (84), 21:46 , 22-Авг-20, (77) web-разработчики как раковая опухоль - всё хотят поглотить А браузер так и не мо, Аноним (16), 13:17 , 22-Авг-20, (16) +9 // Лихо вы веб-разработчиков в разработчиками браузера смешали Как раз браузер уже, Cred (??), 02:30 , 23-Авг-20, (92) // Производительность вебасма нынче выше только на этапе парсинга , Lex (??), 07:13 , 23-Авг-20, (107) –1 Браузер совсем не ок , Аноним (124), 14:23 , 23-Авг-20, (125) Да почему приложения должны быть в браузере Зачем пихать в него всё ОС тогда н, Аноним (-), 13:22 , 22-Авг-20, (17) +9 // Потому что удобно, и нет проблем с обновлением пользователей - не надо держать к, Онаним (?), 13:28 , 22-Авг-20, (19) –4 // Мой провайдер имеет приложение для IPTV и доступа к пиратским фильмам Так вот э, Аноним (23), 13:47 , 22-Авг-20, (23) +4 // Зато приложение не отказывается работать в отличие от этого Стима и приложения п, Роман (??), 14:14 , 22-Авг-20, (28) Очень мелкий провайдер Омска Сам удивляюсь как они ещё не спалились со своей фи, Аноним (23), 14:18 , 22-Авг-20, (30) Очень просто раньше Вы не хвалились фильмотекой , n00by (ok), 14:23 , 22-Авг-20, (31) +10 А чего с вами знакомиться Вы каждый год новые , Аноним (141), 03:53 , 24-Авг-20, (141) Неужели таки можно будет нормальный сип-клиент сделать без угрёбища под название, Онаним (?), 13:27 , 22-Авг-20, (18) // а чем вебсокета не достаточно такой же raw сокет, только с хендшейком по хттп, think (ok), 16:07 , 22-Авг-20, (47) +1 // Тем, что это костыль, поверх которого укладывается SIP И RTP напрямую не загнат, Онаним (?), 19:44 , 22-Авг-20, (72) // Теперь появятся SIP клиенты на Electron и браузерные p2p botnet, Аноним (84), 22:06 , 22-Авг-20, (80) +1 Уроды, Онаним (?), 13:49 , 22-Авг-20, (24) +3 Это было реализовано в API флеша ещё 100 лет назад Некоторые потом даже делали , Аноним (25), 13:54 , 22-Авг-20, (25) +2 // Стоило ли убивать проприетарную вечно дырявую потому что такой подход к разрабо, n80 (?), 15:03 , 22-Авг-20, (40) +1 // Зато оно производительное, позволяет делать очень красивые стильные вещи, наверн, Kusb (?), 09:22 , 23-Авг-20, (111) Стоило Мир стал чище без флеша , Ordu (ok), 16:12 , 22-Авг-20, (49) // Только, судя по текущей новости, ненадолго И, как по мне, лучше уж флэш, чем это, Дон Ягон (ok), 20:51 , 22-Авг-20, (75) –1 // Это сомнительный аргумент Отключить всё лишнее ты можешь, взяв links Или не со, Ordu (ok), 00:13 , 23-Авг-20, (88) Я бы с радостью пользовался чем-то легковесным, типа links, если бы бОльшая част, Дон Ягон (ok), 03:28 , 23-Авг-20, (97) –1 Благодаря тому, что html css и js догоняли флеш, флеш не стал необходимостью Ес, Ordu (ok), 11:08 , 23-Авг-20, (118) +1 Слов цензурных на Вас не хватает То есть если мы возьмём полноценный html-движо, Аноним (23), 20:27 , 23-Авг-20, (134) Совершенно верно Именно поэтому нативный офис подходит разве что для индивидуал, Аноним (137), 21:47 , 23-Авг-20, (137) Главном MS об этом не говорить https support microsoft com ru-ru office я п п , Аноним (23), 05:52 , 24-Авг-20, (142) Парсер зараза В общем ms офис тоже так умеет , Аноним (23), 05:54 , 24-Авг-20, (143) Не знаю чего он там так умеет Ссылка не работает, как ты уже заметил Но я слыш, Ordu (ok), 23:57 , 25-Авг-20, (192) Ну надо же как то продавать свои облака Ведь у офиса также проблема, что и у ви, Аноним (23), 03:32 , 26-Авг-20, (195) Можно и не устанавливать Есть переносимые варианты и достаточно просто запустит, Д1110ма (?), 22:15 , 25-Авг-20, (188) Хыхы Лол То есть я профессору должен заслать экзешник, чтобы тот его использов, Ordu (ok), 23:59 , 25-Авг-20, (193) Да, но получется что одну монополию Microsoft заменяем на дргую Google с его , Д1110ма (?), 12:16 , 18-Дек-20, (208) То есть с этой точки зрения без разницы Я не собираюсь выбирать офисный пакет по, Ordu (ok), 01:56 , 21-Дек-20, (210) Он никогда и не был необходимостью Аналогичные по смыслу вещи можно было делать, Дон Ягон (ok), 20:30 , 23-Авг-20, (135) Сделать, может, и нет проблем Но не взлетит Если онлайн офис не доступен всем,, Аноним (137), 21:44 , 23-Авг-20, (136) Я не знаю, мне точно не нужен Ни как веб приложение, ни как доп функция в нати, Дон Ягон (ok), 23:56 , 23-Авг-20, (140) Это проблема Мне хочется скинуть ссылку человеку, чтобы тот посмотрел и внёс пр, Ordu (ok), 23:54 , 25-Авг-20, (191) Я офисом не пользуюсь, так что в полной мере не могу оценить боль от проблем с в, Дон Ягон (ok), 02:38 , 26-Авг-20, (194) Тут потребуется какой-то особый протокол общения клиентского приложения с сервер, Ordu (ok), 09:07 , 26-Авг-20, (198) gt оверквотинг удален Всёе так, но посколько все эти гугл доки 8212 ущербно, Д1110ма (?), 12:09 , 18-Дек-20, (207) Десктопные офисные пакеты не заменяют онлайн-офиса Они совершенно не годятся дл, Ordu (ok), 17:38 , 18-Дек-20, (209) Бред, бред, бред , Д1110ма (?), 22:18 , 25-Авг-20, (189) Попробуй Если не веришь попробуй Седым стариком, так и не достигнув успеха, ты, Ordu (ok), 23:07 , 25-Авг-20, (190) Сравнил проприетарный плагин с открытым стандартом , Cred (??), 02:34 , 23-Авг-20, (93) Пока его использование не обязательно - пускай хоть и проприетарный Мне безразл, Дон Ягон (ok), 03:30 , 23-Авг-20, (98) –1 конечно стоило - там были просто бесполезные нам дыры, которые к тому же легко, гугль (?), 17:07 , 22-Авг-20, (57) +2 разве вебкит не гугл разрабатывает , Аноним (26), 13:56 , 22-Авг-20, (26) // Нет Гугл - блинк, яблоко - вебкит, Аноним (53), 16:39 , 22-Авг-20, (53) Кем игноироваться Системой, а это нагрузка Так что, это теперь лишь вопрос сил, fdght (?), 14:13 , 22-Авг-20, (27) // Очевидно что хромой реализацией этого API и будет , Аноним (54), 16:39 , 22-Авг-20, (54) Ну и хорошо А я пользуюсь Мозиллой Мне нравится Уже лет десять Все устраивае, Ingener (??), 14:14 , 22-Авг-20, (29) // Мы не спрашиваем, мы заставляем, microsoft (?), 14:30 , 22-Авг-20, (32) –1 // А вы тут причем Я вас уже давно тоже не спрашиваю Вы можете заставить только вы, гугль (?), 17:08 , 22-Авг-20, (58) У Мозиллы 1 Беда с руководством 2 Маленькая аудитория по сравнению с хромом Та, Аноним (127), 15:00 , 23-Авг-20, (127) +1 какая красота , Аноним (33), 14:33 , 22-Авг-20, (33) +1 Кто то там обеспечивал безопасность операционной системы Теперь забудьте про не, Ананоним (?), 14:34 , 22-Авг-20, (34) +4 // это только в операционных системах, где нет нормального файрволла для приложений, Microsoft (?), 17:10 , 22-Авг-20, (59) // Ваши сами вам отправят всё что вам интересно , Ананоним (?), 18:03 , 22-Авг-20, (65) // Жизнь хомячков нам совершенно неинтересна , Microsoft (?), 18:55 , 22-Авг-20, (70) –1 Расказывайте эти сказки бабушкам , Ананоним (?), 23:55 , 22-Авг-20, (87) +1 плюсик, Аноним (84), 22:23 , 22-Авг-20, (83) –2 Ага, в ваших операциооных системах файервол абсолютно управляемый Наставил гало, Аноним (151), 13:43 , 24-Авг-20, (151) Пользуй snap в нем приложение не имеет прямой доступ к ресурсам ОСь, и можно рул, Cred (??), 02:37 , 23-Авг-20, (94) –1 Ну а чо, скоро JS скрипты напрямую окна на XServer-e рисовать будут , Ананоним (?), 14:41 , 22-Авг-20, (35) +2 // И можно будет запускать браузер в браузере , Annoynymous (ok), 14:54 , 22-Авг-20, (38) +1 // systemd интегрируют в Chromium и ядро будет сразу грузить браузер В нём уже дав, Андрей (??), 15:21 , 22-Авг-20, (44) +1 // ChromeOS - с разморозкой , Cred (??), 02:38 , 23-Авг-20, (95) –2 Заходишь на сайт 171 Разрешите сайту присылать уведомления 187 171 Разрешит, Annoynymous (ok), 14:53 , 22-Авг-20, (37) +14 // Ну ктож так делает Так только неудачники делают Надо так 171 Введите ваш номе, Аноним (43), 15:13 , 22-Авг-20, (43) +4 // вот дятлы Что, вот так, каждый может ввести номер телефона и не поделиться УЧИ, магазин перекресток (?), 17:13 , 22-Авг-20, (60) Вы используете устаревшую прошивку BIOS с которой наш сайт может работать неправ, Kusb (?), 09:49 , 23-Авг-20, (113) +1 // Разрешите установидь видеонаблюдение в вашей спальне, ванной, туалете и трусах , Ананоним (?), 14:50 , 23-Авг-20, (126) Быстрое опознавание говносайтов - это хорошо Предпочитаю paywall , user (??), 16:40 , 22-Авг-20, (55) // А мы и не прячемся Что, жрать сегодня не будешь по этому поводу P S учти, у оз, магазин перекресток (?), 17:14 , 22-Авг-20, (61) –1 - 171 Вы используете блокировщик рекламы 187 На этом месте лично моё общение , Онаним (?), 19:45 , 22-Авг-20, (73) +2 Так это Надо дополнение сделать ну чтобы оно между пользователями обменива, Gefest (?), 14:03 , 23-Авг-20, (122) +1 Таким образом скоро все новые ОС будут работать через вэб-броузер И даже ядро О, Француз (?), 14:57 , 22-Авг-20, (39) +1 // На этом не остановятся Найдуться абстракционисты следующих уровней Это когда я, Ананоним (?), 15:10 , 22-Авг-20, (41) +1 // Вот к чему приводит отрыв от BIOS , Ананоним (?), 15:11 , 22-Авг-20, (42) +1 А возможно - просто выпустят новую архитектуру процов, у которых JS будет нативн, Lex (??), 07:46 , 23-Авг-20, (109) // Как-то так Js будет нативным, html будет командами графического терминала, то , Kusb (?), 10:26 , 23-Авг-20, (115) На самом деле, было бы интересно на подобное глянуть На процы, где нативными , Lex (??), 10:38 , 24-Авг-20, (148) Здравствуйте, меня зовут NetBSD, и у меня есть такое ядро , Аноним (172), 16:40 , 25-Авг-20, (172) Совершенно верно Процесс идёт уже не первый год , xm (ok), 00:16 , 23-Авг-20, (89) +1 // Заметь причем вытеснили всех игроков с мировой арены и сделал использование их я, Аноним (159), 19:44 , 24-Авг-20, (161) // Прямо таки сами Или может быть кто то подталкивает Гугель например , Аноним (162), 20:59 , 24-Авг-20, (163) Отличная идея для клиентских сред Использование WebSockets Proxy для доступа к , Аноним (48), 16:10 , 22-Авг-20, (48) // Скрыто модератором, ананасус (?), 16:27 , 22-Авг-20, (52) +4 Если опасения связаны с тем, что он заскриншотит что-то приватное вне хрома, то , Дон Ягон (ok), 02:24 , 23-Авг-20, (90) –1 Остановитесь , Аноним (56), 16:51 , 22-Авг-20, (56) +2 П 8470 сы конченные То есть со временем обеспечить безопасность какой-нибудь с, Аноним (62), 17:47 , 22-Авг-20, (62) так это всё уже давно существует, Аноним (63), 17:49 , 22-Авг-20, (63) // Через браузерное расширение и NaCl Или с использованием чего-то там, дополнител, Аноним (64), 18:03 , 22-Авг-20, (64) В давно существующем есть целых два фатальных недостатка 1 NIH2 Результирует и, Аноним84701 (ok), 23:47 , 22-Авг-20, (86) +1 Наконец то можно будет напрямую общаться с базой данных, без прослоек в виде бек, Аноним (68), 18:40 , 22-Авг-20, (68) // Обращаемся к базе и на клиенте все рисуем Http не нужен Только фронтенд Тольк, Kusb (?), 10:38 , 23-Авг-20, (117) Я таким макаром делал интересные юзерскрипты Но возни многовато, да и в паблик , Аноним (144), 07:19 , 24-Авг-20, (144) Что может не только клиента но ещё давайте серверную часть что б можно было ещё , Аноним (53), 19:05 , 22-Авг-20, (71) –1 Отличный botnet получится, Аноним (84), 22:11 , 22-Авг-20, (81) +1 Может хватит из браузера делать ось , Аноним (96), 03:04 , 23-Авг-20, (96) // Emacs с тобой несогласен , Аноним (-), 06:32 , 23-Авг-20, (100) +2 Почему то просьба витает в мыслях всем кто ро против этого, а напомню недавние о, Аноним (101), 06:38 , 23-Авг-20, (101) Нехило они таким образом функционал своего ChromeOS хотят повысить , Аноним (105), 06:51 , 23-Авг-20, (105) +1 Мне эта идея кажется очень странной И сейчас пишу, это может быть даже дырой в б, Kusb (?), 09:13 , 23-Авг-20, (110) –1 // Можно будет эксплоиты для локальной сети тестировать на подопытных не выходя из , Аноним (114), 09:53 , 23-Авг-20, (114) // Локальная сеть Ха Теперь глобальная , Kusb (?), 10:28 , 23-Авг-20, (116) Эта новость разжигает гнев, возбуждает ненависть и вражду , Аноним (121), 13:33 , 23-Авг-20, (121) +1 // Вэлкам то XXI век Тут везде так , Аноним (127), 15:03 , 23-Авг-20, (128) Нас это не волнует Нет в стандарте Всё равно приступаем к реализации, всем ост, Google (?), 15:56 , 23-Авг-20, (132) В Китае WeChat обогнал веб по числу пользователей, а по пользовательским поисков, Аноним (133), 18:28 , 23-Авг-20, (133) –1 Вот такой из коробки должна быть операционная система , BrainFucker (ok), 22:47 , 23-Авг-20, (138) // Если б не было бы дырНа вендах и вёдрах,Никогда б не знали мыЭтих дней весёлых , Аноним (150), 13:36 , 24-Авг-20, (150) Еще один зонд, аноним12345 (?), 09:03 , 24-Авг-20, (146) Вот так вот обезьянки и наживете себе еще одну проблемку, гг Гугл конечно единс, user90 (?), 15:12 , 24-Авг-20, (153) –1 // О чём ты Самый бесполезный и никчёмный продукт гугла это поисковик Уже 10 лет, Аноним (144), 17:38 , 24-Авг-20, (157) // Так переводчик ещё дообучают, поди , Michael Shigorin (ok), 17:44 , 24-Авг-20, (158) +1 Правильно, нужно больше костылей, больше граблей и тупых технологий А то как-то, Аноним (164), 21:02 , 24-Авг-20, (164) Тю Вообще бесполезная система Исходящие-то соединения я и через Ajax наваяю В, rvs2016 (ok), 16:03 , 25-Авг-20, (166) // Под Ajax подразумевается XHR Ну наваяй через него банальный чат реального време, n80 (?), 16:41 , 25-Авг-20, (173) // тут столько агрессии ужасно, kkostintimur (ok), 16:52 , 25-Авг-20, (174) // Эм, вообще-то её тут примерно ноль Эмоции вообще не очень-то сочетаются с техни, n80 (?), 17:03 , 25-Авг-20, (175) Долбёжка постоянным опросом - это, конечно, нехорошо Но я в браузере запускаю le, rvs2016 (ok), 17:05 , 25-Авг-20, (177)   // А теперь представим, что клиентов подключено хотя бы 1000 Решение хорошо знаком, n80 (?), 18:05 , 25-Авг-20, (179)   Согласен Для большей нагрузки решения нужны более элегантные, чем простой, топо, rvs2016 (ok), 19:42 , 25-Авг-20, (183)   Гм, аргумент с нагрузкой относился к CGI, а не к EventSource который сам по себ, n80 (?), 20:59 , 25-Авг-20, (185)   Ну правильно ж EventSource пусть себе расходы накладные в браузере несёт весьма, rvs2016 (ok), 15:44 , 26-Авг-20, (201)   Всё сильнее ощущение, что меня сравнительно тонко троллят Ведь очевидно же, ч, n80 (?), 19:07 , 29-Авг-20, (203)   Что годится для соединений долгоживущих Чем на сервере генерируют динамику незак, rvs2016 (ok), 18:03 , 04-Сен-20, (205) +1   По этой части моего доклада сообщаю В Апач можно из браузера WebSocket ное соеди, rvs2016 (ok), 19:14 , 04-Сен-20, (206)   Сколько бы не критиковали тут эту инициативу - это вполне закономерный и ожидаем, Linuxforse (ok), 17:08 , 26-Авг-20, (202) 1,2,3,4,5,6,7,8,10,13,15,16,17,18,24,25,26,27,29,33,34,35,37,39,48,56,62,63,68,71,81,96,101,105,110,121,132,133,138,146,153,164,166,202

Сообщения

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

	177. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	+/–
	Сообщение от rvs2016 (ok), 25-Авг-20, 17:05
	>> Тю. Вообще бесполезная система. Исходящие-то соединения я и через Ajax наваяю. > Под Ajax подразумевается XHR? Ну наваяй через него банальный чат реального времени > без долбёжки сервера постоянным опросом Долбёжка постоянным опросом - это, конечно, нехорошо. Но я в браузере запускаю: let eventSource = new EventSource("урл_к_моему_cgi_скрипту"); и после этого браузер держит с моим cgi-скриптом постоянный канал связи и даже переустанавливает его сам, если канал разрывался. А серверный cgi-скрипт каждые N секунд шлёт в этот канал данные: Вот пример, в котором серверный cgi-скрипт ежесекундно секунд шлёт в браузер номер пакета и его время, а через 5 пакетов завершает свою работу, закрывая тем самым канал: Серверный Perl: foreach my $num (1..5) {   my $t = time();   print "data: num = $num, t = $t<BR>\n";   sleep 1; }; print "data: <HR>\n\n"; Браузерный JavaScript: let eventSource = new EventSource("урл_к_моему_cgi_скрипту"); eventSource.onmessage = function(event) {   console.log(event.data);   if (а не закрыть ли нам канал?) {      // а закрыть!      eventSource.close()   } else {      // а не надо! :-)      // NOOP   } } Браузер-то потом автоматически переоткрывает этот канал повторным запросом к cgi-скрипту, если в браузерном JavaScript не остановить автоматической восстановление канала, когда он уже не нужен: Это простейший пример - отправка в браузер пакета ежесекундно. А можно ж не ежескундно, а по другим условиям - например, когда пакет сформировался - хоть через час, хоть через сутки, хоть через месяц, год, век. >> Входящие нужны! > Зачем? Закладываться на наличие у пользователя белого IP (ещё и не порезанного > межсетевым экраном провайдера или работодателя) — уже давно безумие. Вот зачем: Мне нужно отправить юзеру пакет. Обычно это в браузерах 30 лет делают так: Браузер шлёт пакет на сервер, а получатель пакета в другом браузере получает этот пакет с сервера. Но сервер же может отвалиться. Может отвалиться даже кластер серверов. И когда не останется ни одного доступного сервера-посредника, тогда надо иметь возможность отправить пакет из браузера в браузер напрямую без посредников в виде веб-серверов. А если такая возможность будет, то веб-серверы для межбраузерного обмена информацией будут и не нужны (кроме начальных этапов типа построения в браузерах таблиц/списков других браузеров, готовых участвовать в межбраузерном обмене пакетами).
	Ответить | Правка | К родителю #173 | Наверх | Cообщить модератору

	179. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	+/–
	Сообщение от n80 (?), 25-Авг-20, 18:05
	> А серверный cgi-скрипт каждые N секунд шлёт в этот канал данные А теперь представим, что клиентов подключено хотя бы 1000. Решение хорошо знакомое, классическое, даже рабочее, но по многим причинам дикое. А ещё EventSource — довольно бестолковая штука, ИМХО: в дикой природе я его не встречал и сам так нигде и не применил (хотя и были порывы). С одной стороны, требует довольно нового браузера (к счастью, теперь-то IE уже закапывают официально, но сколько лет к этому шли), с другой — всё равно мало что даёт (одно направление, прибитый гвоздями формат сообщений и т.д.). Так что если важны клиенты, используют long polling с GET/POST-запросами, а если можно надеяться на свежий браузер у клиента, давно есть WebSocket'ы, в которых возможностей куда больше при той же нагрузке на сервер и клиент. Только не надо рассказывать про то что это плохо совместимо со столь родными CGI-скриптами, с которыми прожил много лет и не поднимается рука выкинуть, это несерьёзно. Затраченные в прошлом ресурсы не должны быть определяющим аргументом в пользу оставлять/не оставлять. Да, себя иногда тоже на подобном ловлю, но стараюсь пресекать. > Мне нужно отправить юзеру пакет. > Обычно это в браузерах 30 лет делают так: Браузерам в современном понимании «немножко» меньше 30 лет, на минуточку. Не могу не позанудствовать в данном вопросе, пардон. > Браузер шлёт пакет на сервер, а получатель пакета в другом браузере получает этот пакет с сервера. Эту задачу WebSocket прекрасно решает. В смысле, уже лет пять (если не восемь, а до этого аналогичное делалось на Flash и тому подобных отвратительных, но работающих технологиях), как для решения такой задачи браузер не шлёт пакет на сервер. Устанавливает соединение один раз при заходе на сайт и дальше через него может получать пакеты от сервера в любой момент (пока соединение не отвалится или сервер, но это уж с каждым может случиться). > И когда не останется ни одного доступного сервера-посредника, тогда надо иметь возможность отправить пакет из браузера в браузер напрямую без посредников в виде веб-серверов. А если такая возможность будет, то веб-серверы для межбраузерного обмена информацией Так ведь такая возможность давно есть. Локальные браузер-совместимые peer-to-peer программы (типа IPFS или Mastodon) уже давно существуют, в сами браузеры WebRTC тоже завезли уже довольно давно. Т.е. разные возможности есть, организовать транспорт — не проблема. Проблемы возникают куда более интересные, особенно с активным содержимым (скриптами и тому подобным), ну и банально с тем что контент нужно где-то хранить, а его очень много.
	Ответить | Правка | Наверх | Cообщить модератору

	183. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	+/–
	Сообщение от rvs2016 (ok), 25-Авг-20, 19:42
	> А теперь представим, что клиентов подключено хотя бы 1000. > Решение хорошо знакомое, классическое, даже рабочее, > но по многим причинам дикое. Согласен. Для большей нагрузки решения нужны более элегантные, чем простой, топорный EventSource. > браузер у клиента, давно есть WebSocket'ы, > в которых возможностей куда больше > при той же нагрузке на сервер и клиент. Вебсокеты - технология какая-то странная с привязкой к http, если даже не вообще к https вроде - точнее не помню: успел не применить их у себя нигде, а теперь благодаря сабжу их время/эпоха подходит к концу. А если мне надо отправить запрос на 110-й порт моего_почтового_сервера? Или на любой другой порт, если меня на другом конце ждёт моя программа-сервер, работающая хоть по телнету и обрабатывающая мои команды на моём спец-языке? Ну это я всё клоню к тому, что нужна просто простая штука для просто подключений на указанный хост по указанному порту без всяких странных наворотов. Ну типа как просто берёшь, например, tcpcat и "горя не знаешь": pkg info tcpcat ... Description    : From the tcpcat README: Tcpcat is a simple program that is like `cat' but it works over TCP streams to allow you to cat from one host to another. The host common way to use this program whould be something like this: on host a: $ tcpcat -l 93255 | gzip -dc | tar xvf - on host b: $ tcpcat -h hosta:93255  file.tar.gz Another good use for this program is debugging network stuff. When debugging a newtork client or server you can pipe the output of tcpcat to a hex dump (I recomend xxd which comes with vim). Also it can act as a crude telnet server when invoded with --listen, --input, and --output, this mode is quite useful for network program debugging as well. > Браузерам в современном понимании «немножко» меньше 30 лет, > на минуточку. Не могу не позанудствовать в данном вопросе, пардон. Конечно-конечно! 30 - это сильно приблизительно! С небольшой погрешностью лет в 7. :-) (для браузеров в современном понимании, когда во 2-й половине 90-х уже пошли Нетскейпы после Мозаик да Арахн :-) ) > Так ведь такая возможность давно есть. > Локальные браузер-совместимые peer-to-peer программы Тут "прикол" в том, что требуется работа с пользователями, которые даже слова "браузер" не знают (хотя пользуются им), а не только слова типа "Локальные браузер-совместимые peer-to-peer программы". :-) Слушаешь, бывает, юзера по телефону. Он говорит - запускаю Интернет! И думаешь - какой ещё интернет он там запускает, если у него сеть давно настроена? Переподключается что ли к провайдеру? Оказывается, что интернетом юзер называет браузер. Поэтому требуется такие задачки решать в среде, в которой люди, уж извините, ни бум-бум в том, что такое компьютер и программы, которые им нынче теперь называют: "устройство" вместо "компьютер", "приложения" вместо "программы". И так далее. > в сами браузеры WebRTC тоже завезли уже довольно давно Попытался я, было, в своё время возрадоваться появлению WebRTC. Но какой-то он мутный. Это не простые прямые соединения, а через кучу каких-то странных предварительных настроек. Этот WebRTC со своей не простой системой установки связи между браузерами напоминает мне старую историю из тех же 90-х, когда программисты ("до изобретения Delphi") для создания окна в Windows читали страниц пять толстой книги по программированию в ней. :-) Вот так и WebRTC. Хочу открыть исходящее соединение по адресу хост:порт. Ну сделайте простую функцию с этой парой аргументов (хост, порт) ну и возможно с назначением callback и т.п., если что, да и всё. Так нет же. Там нужны ещё сервера сигнальные и TURN. И объясняют всю эту сложность в WebRTC - необходимостью гарантированного пробивания NAT. А если мне не надо пробивать NAT и оба браузера находятся в одной локальной сети, даже не подключенной к интернету? Браузеру_А надо подключиться к браузеру_Б на порт_Б: взять бы просто да подключиться, если я точно знаю (а это я программно решу сам), что браузер_Б уже слушает порт_Б. Так нет же - иди бери бубен, и танцуй с ним вокруг сигнальных и TURN-серверов. :-)
	Ответить | Правка | Наверх | Cообщить модератору

	185. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	+/–
	Сообщение от n80 (?), 25-Авг-20, 20:59
	>> А теперь представим, что клиентов подключено хотя бы 1000. >> Решение хорошо знакомое, классическое, даже рабочее, но по многим причинам дикое. > Согласен. Для большей нагрузки решения нужны более элегантные, чем простой, топорный EventSource. Гм, аргумент с нагрузкой относился к CGI, а не к EventSource (который сам по себе имеет весьма малые накладные расходы). Мне это показалось очевидным, ну да ладно. > Вебсокеты - технология какая-то странная с привязкой к http, если даже не вообще к https вроде - точнее не помню: успел не применить их у себя нигде Да, с привязкой к HTTP(S) (HTTP поверх SSL/TLS всё-таки не стоит считать отдельным протоколом), но в контексте браузера это не очень-то большая проблема. На самом деле эта привязка очень мало мешает (в т.ч. потому что клиентскую сторону на JS всё равно писать придётся, а серверную можно обернуть в вебсокеты, готовых решений полно). ИМХО, существенно она мешает только там, где не то что HTTP(S) не очень-то подходит, а и вообще TCP (так что начинаются всякие SCTP или, напротив, Enet). > а теперь благодаря сабжу их время/эпоха подходит к концу. Хе-хе, сабж если когда-нибудь и внедрят, то очень нескоро, особенно с учётом армии пользователей с мобильных устройств, которые никогда уже не обновятся. Некоторые и на десктопе предпочитают сидеть либо на неподдерживаемых версиях браузера (опасные люди, практически вредители, ибо ловят эксплоиты, а потом другим жизнь портят), либо на особо порезанных (не от хорошей жизни), где вся подобная функциональность зарезана. Тут и про вебсокеты-то до сих пор лишний раз приходится подумать, внедрять или опять извернуться и обойтись без него, а уж это — дожить бы. > А если мне надо отправить запрос на 110-й порт моего_почтового_сервера? Оффтоп, но как же у меня припекает от пользователей POP3: вот вообще ничем он не лучше IMAP4, но всё равно находятся упёртые странные пользователи, которые будут страдать, но продолжать заставлять меня держать лишний сервис на сервере, да загаживать логи своим опросом, не говоря уж про прочие неудобства («пошли мне это письмо ещё раз, а то оно на домашнем компе забралось»). Понимаю, что просто пример, но аргх. > Или на любой другой порт, если меня на другом конце ждёт моя программа-сервер, работающая хоть по телнету и обрабатывающая мои команды на моём спец-языке? ИМХО, лучше всё-таки с такой программой-сервером общаться не через браузер. И так у браузера слишком много функций и это трагично. > Ну это я всё клоню к тому, что нужна просто простая штука для просто подключений на указанный хост по указанному порту без всяких странных наворотов. Такая штука упростит жизнь нескольких разработчиков (хочется сказать каких, ну ладно), но сильно испортит жизнь остальным, т.к. открывает большой просто для злоупотреблений. Тут и так умудряются всякие XSS проворачивать, а с такой штукой (надо быть честным с собой и не верить в то что пользователи будут умные и будут раздавать права только на нужное) открываются невообразимые возможности делать ботнеты на ровном месте. А если вводить аналоги same origin policy и CORS, штука будет довольно бесполезная (и всё равно будут возможности злоупотребления). > Ну типа как просто берёшь, например, tcpcat и "горя не знаешь" Да-да, netcat, socat и т.д. Это всё прекрасно в локальной сети (сам часто пользуюсь), но в дикой природе кроме горя ничего так и не познать. > Конечно-конечно! 30 - это сильно приблизительно! С небольшой погрешностью лет в 7. > :-) (для браузеров в современном понимании, когда во 2-й половине 90-х > уже пошли Нетскейпы после Мозаик да Арахн :-) ) Да, я именно про конец 90-х (а то и начало 2000-х), а это всё-таки совсем не 30 лет. > Оказывается, что интернетом юзер называет браузер. > Поэтому требуется такие задачки решать в среде, в которой люди, уж извините, > ни бум-бум в том, что такое компьютер и программы, которые им > нынче теперь называют: "устройство" вместо "компьютер", "приложения" вместо "программы". > И так далее. Вот именно из-за необходимости ориентироваться на таких пользователей, браузерные (да и вообще сетевые) технологии и стали такими, какие есть. Они (технологии) могут выглядеть жутко, дико, непонятно для разбирающегося на низком уровне, но это результат тяжёлого труда по поиску компромиссов. > Вот так и WebRTC. Хочу открыть исходящее соединение по адресу хост:порт. Ну > сделайте простую функцию с этой парой аргументов (хост, порт) ну и > возможно с назначением callback и т.п., если что, да и всё. В современном мире прежде чем хотеть чтобы что-то появилось, нужно сначала хорошенько подумать: а кто и как этим может злоупотребить? Потому что если что-то может пойти не так, оно обязательно пойдёт худшим из возможных сценариев. Нужно ли разворачивать эту мысль применительно к этому конкретному желанию? > Так нет же. Там нужны ещё сервера сигнальные и TURN. [...] > И объясняют всю эту сложность в WebRTC - необходимостью гарантированного пробивания NAT. И абсолютно правильно объясняют. В современном мире (опять, хех) даже если какой-то провайдер вдруг даёт белый IP, по умолчанию часто на него нельзя подключиться даже с хоста из той же подсети (!). А всё почему? Потому что «требуется такие задачки решать в среде, в которой люди, уж извините, ни бум-бум», отсюда и умолчания соответствующие. > А если мне не надо пробивать NAT и оба браузера находятся в одной локальной сети, даже не подключенной к интернету? То это настолько специфичное исключение, что админ этой корпоративной/институтской сети может обойти (не обязательно ногами) оба этих ПК и установить и настроить там не только браузер, но и другой нужный софт. --- На самом деле, всё ещё намного хуже: в современном мире приходится учитывать не только то что проблемных пользователей и порезанных окружений большинство, так ещё и что программисты по большей части криворуки и не думают о последствиях (а некоторые ещё и при этом очень великого о себе мнения, ведь они не орган собачий, а что-то там писали на чистом WinAPI, ууу), поэтому массовые технологии приходится, гм, делать очень ограниченными и дуракоустойчивыми (как следствие, довольно усложнёнными). Это печально, но приходится смириться с тем что усидеть на всех стульях (чтобы решение было в 5 строчек, и работало устойчиво, и нужды 99% пользователей покрывало) не выйдет и искать компромиссы, выжимая 80% пользы с помощью 20% усилий, а не наоборот.
	Ответить | Правка | Наверх | Cообщить модератору

	201. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	+/–
	Сообщение от rvs2016 (ok), 26-Авг-20, 15:44
	> Гм, аргумент с нагрузкой относился к CGI, а не к EventSource (который > сам по себе имеет весьма малые накладные расходы). Мне это показалось > очевидным, ну да ладно. Ну правильно ж. EventSource пусть себе расходы накладные в браузере несёт весьма малые. Но если этих EventSoure начнёт одновременно набираться тысячами для долбёжки cgi-скрипта, то у машины с веб-сервером, на котором этот скрипт трудится, может появиться напрряг - ну смотря как систему настраивать, конечно. >> а теперь благодаря сабжу их время/эпоха подходит к концу. > Хе-хе, сабж если когда-нибудь и внедрят, то очень нескоро, особенно с учётом > армии пользователей с мобильных устройств, которые никогда уже не обновятся. Есть такая идея, что мобильные, как раз быстрее обновляют свои железки, чем десктопные, т.к. мобилы нынче делают так, что не успел повернуться, а уже "устройство исчерпало память, будет работать плохо, медленно, прегадко и т.д." - после этого простые смертные (которые ни разу не программисты) просто выбрасывают свои мобилы и идут покупать новые. Конечно, какая-то часть населения железяки свои не обновляет. Но это во многом - не платёжеспособная часть населения, которая многим сайтам, увы, всё-равно бесполезна. >> А если мне надо отправить запрос на 110-й порт моего_почтового_сервера? > Оффтоп, но как же у меня припекает от пользователей POP3: вот вообще > ничем он не лучше IMAP4, но всё равно находятся упёртые странные > пользователи, которые будут страдать, но продолжать заставлять меня держать лишний сервис > на сервере, да загаживать логи своим опросом, не говоря уж про > прочие неудобства («пошли мне это письмо ещё раз, а то оно > на домашнем компе забралось»). Понимаю, что просто пример, но аргх. Ну "для сэбэ трошки" POP3 при грамотной настройке работает нормально. И проблем не возникает, если грамотно настроить маршрутизацию почты так, чтоб она была доступна везде в нужных местах. Но это, повторю, верно "для сэбэ трошки" - для людей, умеющих работать грамотно - програмимстов, сисадминов и т.п. А для смертных в промышленных масштабах про POP3 сказать ничего не могу - не работал с почтой масштабно аки крупный почтовый провайдер. >> Или на любой другой порт, если меня на другом конце ждёт моя программа-сервер, работающая хоть по телнету и обрабатывающая мои команды на моём спец-языке? > ИМХО, лучше всё-таки с такой программой-сервером общаться не через браузер. И так > у браузера слишком много функций и это трагично. Если задача стоит так, что общаться должен только браузер (юзеру ж не скажешь - установи себе программу какую-то), то получается, что надо именно браузер заставлять коннектиться к серверу. >> Ну это я всё клоню к тому, что нужна просто простая штука для просто подключений на указанный хост по указанному порту без всяких странных наворотов. > невообразимые возможности делать ботнеты на ровном месте. А если вводить аналоги > same origin policy и CORS, штука будет довольно бесполезная (и всё > равно будут возможности злоупотребления). Да-да. Я тоже думал про то, что эти фичи упростят жизнь злоумышленникам. И тоже думал про то, что нужны ограничители, которые регулирует не юзер (которые макисмальные разрешения навыдаёт), а такие, которые помогают коннкетиться только к "своему сайту/домену" - для многих задач этого достаточно. Ну, например, чат без сервера. Ну не будут же браузеры участников чата коннкетиться куда попало, если им сообщения надо гонять только в своём чате. > Да, я именно про конец 90-х (а то и начало 2000-х), а > это всё-таки совсем не 30 лет. Да это я просто грубо с плеча рубанул - получилось аж 30 лет. Ну по сильно грубому прикиду и без апроксимаций. :-) >> А если мне не надо пробивать NAT и оба браузера находятся в одной локальной сети, даже не подключенной к интернету? > То это настолько специфичное исключение, что админ этой корпоративной/институтской сети > может обойти (не обязательно ногами) оба этих ПК и установить и > настроить там не только браузер, но и другой нужный софт. Ну браузеры внутри одной локалки - это сильно упрощённый пример. А я ж могу точно знать, что у юзера, например, в Уфе браузер на белом IP и к нему можно отправить запрос, например, из Магадана. Я же точно знаю, что NAT между обоими браузерами отсутствует. Ну откуда я это знаю - это "по условиям задачи". Но не смотря на это всё-равно получается так: "мы вам упростили жизнь и теперь вам самим не надо пробивать NAT" (даже если никаким NAT'ом по дороге и не пахнет). Да это ж какая-то медвежья услуга получилась: NAT пробивать не надо, а всё-равно фичи пробивания в нагрузку бери, пожалуйста, и не сетуй. :-) > На самом деле, всё ещё намного хуже: в современном мире приходится учитывать > не только то что проблемных пользователей и порезанных окружений большинство, так > ещё и что программисты по большей части криворуки Эх, да... Мир сложен... Работает, бывает, хороший сайт и через некоторое время работать нормально перестаёт - после прихода на работу в этот сайт вебмастера, который начальству говорит: мой предшественник - профан и мне теперь придётся у вас тут всё перенастроить по другому. Результат - сайт нормально работать перестаёт. Да и не только сайт и не только компьютеры. Во всех отраслях такое бывает... Беда прям...
	Ответить | Правка | Наверх | Cообщить модератору

	203. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	+/–
	Сообщение от n80 (?), 29-Авг-20, 19:07
	> > Гм, аргумент с нагрузкой относился к CGI, а не к EventSource (который > > сам по себе имеет весьма малые накладные расходы). Мне это показалось > > очевидным, ну да ладно. > Ну правильно ж. EventSource пусть себе расходы накладные в браузере несёт весьма малые. Но если этих EventSource начнёт одновременно набираться тысячами для долбёжки cgi-скрипта, то у машины с веб-сервером, на котором этот скрипт трудится, может появиться напрряг - ну смотря как систему настраивать, конечно. Всё сильнее ощущение, что меня (сравнительно тонко) троллят. Ведь очевидно же, что накладные расходы клиента здесь вообще не являются тем, о чём имеет смысл беспокоиться, да и вообще: клиентов тысячи, а сервер на них один. Равно как и очевидно, что CGI не годится для долгоживущих соединений чуть более, чем совсем. Да и вообще ни для чего (кроме махрового legacy и некачественных сайтов, особенно внутренних) не годится, как ни настраивай систему. Можно сколько угодно оптимизировать fork+exec (vfork+exec, spawn, не важно), подгонять размер стека потоков ядра, подстраивать планировщик и всё равно это будет много хуже (в плане отношений полезной работы к потребляемым ресурсам как сервера, так и разработчика/поддержки), чем сразу делать по уму. Но да, CGI — одна из «святых коров» закостенелых админов (не старых, не опытных, а именно закостенелых, это не от возраста зависит), не желающих даже смотреть на что-либо новое, ведь позволяет писать серверную часть абы как и долго не замечать (читай, игнорировать) проблемы разной степени серьёзности (вплоть до чего-нибудь типа повреждения кучи). А если под «cgi-скриптом» подразумевалось вообще любое серверное ПО для генерации динамики (а не конкретно используемые через CGI программы) — лучше так всё-таки не вводить в заблуждение, у термина есть вполне конкретное значение. > Есть такая идея, что мобильные, как раз быстрее обновляют свои железки, чем десктопные, т.к. мобилы нынче делают так, что не успел повернуться, а уже "устройство исчерпало память, будет работать плохо, медленно, прегадко и т.д." - после этого простые смертные (которые ни разу не программисты) просто выбрасывают свои мобилы и идут покупать новые. > > Конечно, какая-то часть населения железяки свои не обновляет. Но это во многом - не платёжеспособная часть населения, которая многим сайтам, увы, всё-равно бесполезна. Идея интересная, но дело-то не в железках, а в софте. И если на десктопе вроде как программы так или иначе обновляются регулярно (хотя ещё не так давно на это рассчитывать не приходилось), то лепить новые мобильные устройства со старым вшитым софтом (и не выпускать обновления) производители ох как любят. Это не говоря уж про изначально урезанные версии софта по сравнению с исходными версиями. Отдельного гнева, кстати, заслуживает то что в новых версиях мобильных ОС из-за засилья низкосортных кодеров (ну и по коммерческим причинам, конечно) всё сильнее продавливают использование push-уведомлений (в т.ч. в браузере, с необходимостью использовать соответствующий API) вместо поддержания долгих соединений самим приложением. Доходит до того, что очень многие разработчики свято верят, что если программа (какой-нибудь XMPP или IMAP клиент, например) для получения данных с сервера без задержки не использует push-уведомления, то обязательно должна выжирать батарею на глазах (в итоге в свежих версиях ОС уже и нет возможности без этого обойтись, а балбесы и рады). Вот это случай, когда действительно программистов ограничили не по делу, хотя умом и понятно, что «рыночек порешал». > Ну "для сэбэ трошки" POP3 при грамотной настройке работает нормально. И проблем не возникает, если грамотно настроить маршрутизацию почты так, чтоб она была доступна везде в нужных местах. Но это, повторю, верно "для сэбэ трошки" - для людей, умеющих работать грамотно - програмимстов, сисадминов и т.п. А для смертных в промышленных масштабах про POP3 сказать ничего не могу - не работал с почтой масштабно аки крупный почтовый провайдер. Ну начинается. Вкратце — нет, не работает. Можно сколько угодно обкладывать старый протокол костылями (там маршрутизацию подстроить, там плюнуть, тут подпереть, опросом сервер задолбить, опять же), но это называется «закат Солнца вручную». Т.е. вместо того чтобы сразу взять нормальный протокол (который тоже не сказать, что сильно молодой, между прочим) и получить массу полезных фич бесплатно, начинается накостыливание ради, вероятно, поддержки чувства собственной важности. В итоге полученный франкенштейн и будет заведомо хуже работать (не иметь ряда полезных возможностей, создавать лишнюю активность на сервере), и ресурсов будет тратиться (как на настройку/поддержку, так и сервером и клиентами на работу) куда больше. Причём, тут не надо никаких масштабов крупного провайдера. Даже для переписки двух человек важно иметь нулевую (за вычетом собственно времени перекачки по каналам связи) задержку получения новых сообщений (да здравствует достающаяся по сути бесплатно возможность общаться в режиме чата, никак не ломающая возможность общения и в более традиционном формате) и возможность иметь с любого устройства доступ к своим перепискам, заботливо рассортированным по папкам (причём, и отправленные письма, и ответы на них хранятся вместе и отображаются цепочками, ровно как тут на форуме, без всяких нелепых костылей, типа Bcc на себя). Попытка изобразить эту функциональность на базе POP3 обречена на провал, хотя формально часть (но только часть) возможностей и можно кое-как накостылить дополнительными телодвижениями (теша себя тем что, чай, не простой смертный, а ого-го какой нормальный пользователь). Нет ни одной разумной причины использовать POP3 вместо IMAP4 (даже миф про разницу в потреблении трафика оказался мифом), ровно так же как и нет ни одной разумной причины использовать EventStream вместо WebSocket. Есть разве что одна полуразумная причина «у меня так уже было настроено и работает, мне не нужны фичи и я очень не хочу ничего сломать», но это применимо только к машинно-машинному взаимодействию, а для живых пользователей всё-таки плохо подходит (рано или поздно вносить изменения приходится и нужно заранее представлять их цену в случае одной реализации и другой). И уж точно не нужно тащить это барахло в новые инсталляции. Да, очень часто новые технологии хуже старых (в чём-то или, нередко, вообще во всём), регулярно такое вижу, но эти примеры — редкий случай, когда это точно не так, но находится целая армия упирающихся тупо ради своих, сугубо субъективных причин. И вот это явление, называемое «закат Солнца вручную» много где проникает. И полбеды что люди своё время тратят на такую кочергу, так ещё и другим частенько этим создают неудобства. > Если задача стоит так, что общаться должен только браузер (юзеру ж не скажешь - установи себе программу какую-то), то получается, что надо именно браузер заставлять коннектиться к серверу. Как это не скажешь (если только это не восточный пользователь, у которого все сайты через мини-приложения внутри одного комбайна под названием gosuslugi^W WeChat), столько лет ставили программы и продолжают ставить (хотя и всё менее охотно). Успех ряда проприетарных программ (неэтично их лишний раз называть, но мы понимаем о каких программах для обмена сообщениями и файлами, просмотра карт и, например, удалённого доступа к рабочему столу может идти речь) ясно показывает, что если оно того стоит и сделано по уму — пользователь ещё как поставит. Как тут не вспомнить слова (цитирую по памяти, так что не совсем дословно, но суть должна была сохраниться) из полурекламной статьи одного хостера: «не стоит недооценивать пользователей; по нашему опыту, нет таких скриптов, с установкой которых на сервер не разобралась бы очередная instagram-дива ради накрутки +30% like'ов на своих фотографиях». > Да-да. Я тоже думал про то, что эти фичи упростят жизнь злоумышленникам. И тоже думал про то, что нужны ограничители, которые регулирует не юзер (которые максимальные разрешения навыдаёт), а такие, которые помогают коннектиться только к "своему сайту/домену" - для многих задач этого достаточно. Ну, например, чат без сервера. Ну не будут же браузеры участников чата коннкетиться куда попало, если им сообщения надо гонять только в своём чате. А совсем без сервера не получится в любом случае, проблему bootstrap'а никто не отменял. Т.е. либо придётся на старте вбивать адреса руками (опять закатываем вручную?), либо пользоваться своим сервером, либо общественным (к этому в т.ч. относится использование DNS, например). Причём, «либо» тут в смысле неисключающего или. А если полагаться на общественную инфраструктуру, то использование общедоступных STUN/TURN серверов для начального соединения не сильно отличается от того чтобы полагаться на работу DNS. Это не говоря уж про такие занятные штуки, как mDNS. > Ну браузеры внутри одной локалки - это сильно упрощённый пример. Он не столько упрощённый, сколько ИМХО самый распространённый пример такого стечения обстоятельств. > А я ж могу точно знать, что у юзера, например, в Уфе браузер на белом IP и к нему можно отправить запрос, например, из Магадана. Я же точно знаю, что NAT между обоими браузерами отсутствует. Ну откуда я это знаю - это "по условиям задачи". Это замечательно, верю, но теперь нужно не забыть прикинуть, кому нужны именно так построенные задачи. Даже если таких случаев в окружении много (и потому кажется, что их вообще много), они составляют невесомые доли процента от общего числа пользователей. И если дать возможность такие задачи решать так, как этого хочется отдельным, гм, специфичным разработчикам, хорошо жить станет долям процентов, зато остальным участникам процесса (т.е. многим девяткам) станет хуже. Т.е. повторюсь, когда речь идёт о массовых решениях, нужно думать не только о возможной пользе для лично себя и ближайшего окружения, но и потенциальных проблемах для остальных. > Но не смотря на это всё-равно получается так: "мы вам упростили жизнь и теперь вам самим не надо пробивать NAT" (даже если никаким NAT'ом по дороге и не пахнет). Да это ж какая-то медвежья услуга получилась: NAT пробивать не надо, а всё-равно фичи пробивания в нагрузку бери, пожалуйста, и не сетуй. :-) Опять же, ИМХО, эти фичи достаются бесплатно. Т.е. когда они не нужны, они ничего плохого и не делают, а когда нужны (и тут слишком много девяток) — просто работают. Да, есть некоторое неприятное ощущение от того что нужно или иметь свой сервер сигнализации, или пользоваться любыми общественными (а их более чем достаточно, чтобы совсем уж без связи не остаться, не говоря уж про возможность в этом случае поднять свой на любом из хостов участников, раз они все по условию задачи без NAT), но сейчас (в мире отсутствия полного глобального запрета на торренты и прочий P2P) наличие общедоступного STUN/TURN сервера является чем-то столь же само собой разумеющимся, как и наличие работающего DNS. Так что, ИМХО, не тот случай, когда нужно воротить нос и из-за заморачивания по поводу мелкой потенциальной проблемы устраивать реальную и большую (ударение и так, и так). > Работает, бывает, хороший сайт и через некоторое время работать нормально перестаёт - после прихода на работу в этот сайт вебмастера, который начальству говорит: мой предшественник - профан и мне теперь придётся у вас тут всё перенастроить по другому. Результат - сайт нормально работать перестаёт. Да и не только сайт и не только компьютеры. Отож, классика жанра, к сожалению. Но, справедливости ради, у таких историй есть, как минимум, две стороны. Одна (вина которой чаще всего очевидна) — пришедший профан, который полез вносить изменения, не удостоверившись в понимании что, как и _зачем_ было сделано, в наличии бекапов (и того что восстановление из них работает) и, собственно, плана постепенных изменений (включающего в т.ч. некоторое понимание того, что делать, если в какой-то момент поведение системы идёт не по плану). Вторая — предыдущий админ, который мог неограниченно копить технический долг (не устанавливать обновления, втыкать всё новые и новые костыли, регулярно вручную «подшаманивать» отваливающиеся куски системы, борясь вручную с симптомами вместо исправления проблем, настраивать что-то без понимания копипастой и т.д.; и всё это документировать, в лучшем случае, только в унесённой с собой тетрадке, а то и вообще в голове, да и то через раз). Пока такой админ регулярно занимается своим «закатом Солнца вручную», снаружи может быть обманчивая иллюзия идиллии (которая и откладывается в голове у начальства, так что вина этой стороны может быть крайне неочевидной), но настроенная таким образом система имеет свойство быстро и, что важно, неожиданно (через недели или месяцы после ухода шамана) ломаться сама, даже без всяких изменений. А кому не повезёт в этот момент оказаться рядом, на того все шишки и посыпятся, даже если он и бекапами озаботился и разобраться пытался, прежде чем менять. А в силу отсутствия документации и ряда чудом работавших решений (которые даже сам предыдущий админ не понимает как работали) такие системы очень трудно чинятся и, тем более, переносятся на новую платформу. Клубок очень легко запутывается и очень трудно распутывается, скажем так. Бывает, впрочем, и третья сторона, которая наблюдает со стороны и, в силу устройства своей психики (это вообще довольно стандартный защитный механизм у мозга, просто в разной мере проявляется), легко забывает о прошлых проблемах и столь же легко раздувает нынешние, в итоге текущий админ постоянно (до самого его ухода в более здоровое место) поливается отборными помоями и по делу, и без дела, но когда он становится бывшим админом, то новому получателю помоев постоянно упоминается как пример идеала. Это уже, конечно, не из технической области фактор, но тоже важный для полноценного рассмотрения вопроса. Как говорится, плавали, знаем.
	Ответить | Правка | Наверх | Cообщить модератору

	205. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	+1 +/–
	Сообщение от rvs2016 (ok), 04-Сен-20, 18:03
	> CGI не годится для долгоживущих > соединений чуть более, чем совсем. Что годится для соединений долгоживущих? > CGI — одна из «святых коров» закостенелых админов (не старых, > не опытных, а именно закостенелых, это не от возраста зависит), не > желающих даже смотреть на что-либо новое, ведь позволяет писать серверную часть > абы как и долго не замечать (читай, игнорировать) проблемы разной степени > серьёзности (вплоть до чего-нибудь типа повреждения кучи). > А если под «cgi-скриптом» подразумевалось > вообще любое серверное ПО для генерации > динамики (а не конкретно используемые через CGI программы) Чем на сервере генерируют динамику незакостенелые админы? >> Ну "для сэбэ трошки" POP3 при грамотной настройке работает >> нормально. И проблем не возникает, если грамотно настроить >> маршрутизацию почты так, чтоб она была доступна везде в >> нужных местах. Но это, повторю, верно "для сэбэ трошки" >> - для людей, умеющих работать грамотно - програмимстов, >> сисадминов и т.п. А для смертных в промышленных масштабах >> про POP3 сказать ничего не могу - не работал с почтой >> масштабно аки крупный почтовый провайдер. > ради, вероятно, поддержки чувства собственной важности. Возможно, что где-то такие конфигурации используются по причине поддержки этого чувства. Но мой случай более прост: Мне надо сделать, чтоб система работала. Я так сделал. Других задач у меня нет. :-) > Нет ни одной разумной причины использовать > POP3 вместо IMAP4 (даже миф про разницу в > потреблении трафика оказался мифом), ровно > так же как и нет ни одной разумной причины > использовать EventStream вместо WebSocket. Для настройки WebSocket в браузере хорошие описания по интернетам существуют. А для настройки серверной стороны хороших описаний, показывающих простоту настройки, нет. Вот загрузилась, например, в браузер страница с веб-сервера Апач. Из страницы с помощью WebSocket отправляется по некому адресу запрос на установку соединения. Пока всё хорошо, т.к. действия из пары предыдущих предложений выполнить очень легко. Дальше начинается что-то мало понятное: Кто на сервере должен принять запрос на установку соединения WebSocket? Ну первоначально-то запрос может принять и Апач: ну, например, Апач принял запрос, отдал его обработку моему перл-скрипту, который выдал правильные заголовки, включающие Upgrade и т.п. А дальше что да как? В обычной системе браузер отсылает запросы на веб-сервер отдельными подключениями и веб-сервер даёт на них ответы, после чего соединение сразу же закрывается. А когда соединение из браузера по протоколу WebSocket установлено и является продолжительным, то кто на сервере может это соединение держать и работать с ним? Тут уже хорошие примеры по интернетам на глаза не попадаются. Кто-нибудь может по шагам описать простую и понятную схему настройки серверной части для работы с WebSocket?
	Ответить | Правка | Наверх | Cообщить модератору

	206. "Для Chrome развивается API для прямых TCP и UDP коммуникаций"	+/–
	Сообщение от rvs2016 (ok), 04-Сен-20, 19:14
	> Кто-нибудь может по шагам описать простую и понятную > схему настройки серверной части для работы с WebSocket? По этой части моего доклада сообщаю: В Апач можно из браузера WebSocket'ное соединение и не отправлять. Оно-то и так понятно, что Апач не обязателен. Но просто по привычке хотелось сперва замутить серверную часть с его применением. Многие советы в интернетах советуют запускать сервер на nodejs. Но "не нравится мне этот гусь". :-) Запустил сервер простеньким перловым скриптом с использованием этого: use AnyEvent::Socket; use AnyEvent::Handle; use Protocol::WebSocket::Handshake::Server; use Protocol::WebSocket::Frame; Помогли немного получше осознать "происходящее" примеры со страницы Прагматик перла аж за 2015-й год: http://pragmaticperl.com/issues/26/pragmaticperl-26-%D1... В 15-то году я эту статью читал, но тогда дальше чтения дело не пошло. А нынче руки дошли ещё и до запуска примеров у себя. В примерах там будьте внимательны. Если клиента и сервера запускаете на разных хостах, то в клиенте замените ws://localhost:3000 на ws://хост_вашего_websocket_сервера:3000 А то я и сам на этом сперва попался: сервер работал нормально и локально я к нему телнетом на 3000-й порт подключался успешно, а Файрфоксом со своей рабочей станции подключение к этому не локальному серверу не срабатывало (ибо он же не на моей станции подключения ожидал), пока в клиенте не исправил адрес вебсокетного сервера. А то уже даже на браузер грешить почти начиал уж. :-)
	Ответить | Правка | Наверх | Cообщить модератору

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

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