Опрос: websocket и socket.io

NAT

Пофиг на НАТ. Соединение инициирует клиент, а не сервер.

Это то да, но для чего-то socket.io сделали? Актуально ли это сейчас?

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

С их помощью наконец-то стало возможным уйти от этих долбанных синхронных запросов! Нафиг CGI!! Да здравствуют вебсокеты!!!

но для чего-то socket.io сделали

Для браузеров, которые не умели вебсокеты.

Сейчас в нём смысла маловато.

Вот чего еще не хватает - так это возможности пересылать бинарные данные. А то хочу я вебсокетами видео транслировать, а оно тупит как собака, потому что нужно декодировать сначала в текст (как там этот код называется?), а потом раскодировать средствами браузера и менять кадр.

В общем, до сих пор ни одного вменяемого способа делать рилтаймовую трансляцию в браузерах не придумали. Так и пользуемся, как динозавры, mjpeg'ом (а то и вообще внутри фрейма жопег перезагружаем с разными ?xxx=123123123123, чтобы из кэша не бралось).

вебсокетами видео транслироват

это как?

Вот так

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

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

И да, вебртц никакого отношения к рилтаймовому вещанию не имеет, он только между браузерами может работать. А не так, что взял кадр с ПЗС, обработал, выкинул пользователю.

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

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

Никто не спорит, что веб - это набор уродливых во всех отношениях костылей, но никто не виноват, что ты ни в чем не разобрался. Да, есть потоковое видео, которое поддерживают все броузеры. Тебе просто на сервере надо было реализать интерфейс, где твои кортичочечки будут передаваться в виде потокового видео, а не бейс64 кадрами, или что ты там сделал.

Для браузеров, которые не умели вебсокеты.

Да наверное вы правы, это было главным.

https://ru.wikipedia.org/wiki/WebSocket
В настоящее время WebSocket поддерживается в следующих браузерах:
Google Chrome (начиная с версии 4.0.249.0);
Apple Safari (начиная с версии 5.0.7533.16);
Mozilla Firefox (начиная с версии 4);
Opera (начиная с версии 10.70 9067);
Internet Explorer (начиная с версии 10);

Судя по этому: https://www.w3schools.com/browsers/browsers_explorer.asp кто-то еще и на древних IE сидит.

Тогда переформулирую свой вопрос: можете назвать какой-то известный сервис типа gmail который отказывается работать скажем со всем что ниже IE10? Опять же стоит ли сейчас в 2017 году городить костыли типа socket.io либо забить на старые браузеры доля которых уже ничтожна? Как на это смотрят коммерческие сервисы?

Вопрос в том на сколько адекватно вебсокет работает на мобильных платформах.

Прекрасна передаются бинарные данные через вебсокет, причем практически с самой первой версии оных

Переведи. Мне твой поток бреда непонятен.

Тебе просто на сервере надо было реализать интерфейс, где твои кортичочечки будут передаваться в виде потокового видео

Я не встречал ни одной библиотеки, которая это умеет делать. И без библиотек тоже реализаций не встречал. Потому что с минимальной задержкой отправлять очередной кадр можно лишь в формате mjpeg, либо какое-то другое сжатие использовать, которому не нужна система прогнозов.

мобильных платформах

Этой дряни хватит plain html, даже css там нафиг не нужно.

Proof or fuck off!

Я полгода убил года три назад, когда хотел принципиально новую реализацию написать. Вебсокеты могут хоть черта лысого передать, но браузер бинарную информацию из этого потока выделить не сможет. Ему сериализация нужна. Либо пользоваться какими-нибудь велосипедами, которые сначала собирают пакет кадров, сжимают и передают в браузер; в итоге видео идет неравномерно, с рывками, да еще и задерка по нескольку секунд бывает!

Как известно вебсокеты данные передают фреймами, у фреймов есть заголовок, в заголовке есть поле type. У type есть несколько стандартных значений - например TEXT и BIN. Если браузер получает фрейм с типом TEXT то msg.data будет строка, если тип фрейма BIN то msg.data будет ArrayBuffer. Как посылать BIN фреймы зависит от платформы, например в томже JavaScript для отправки BIN фрейма достаточно в качестве аргумента метода send указать ArrayBuffer а не строку. Вот простой пример (нагуглил за 1 минуту): https://gist.github.com/atsuya/1437249

Советую уже погуглить, как из бинарного массива — рисунка в jpg/png/etc формате — получить браузером сам рисунок. Ответ: никак! Разве только на канве «рисовать», но это еще медленнее будет, чем даже base64 дешифровать!

Советую уже погуглить, как из бинарного массива — рисунка в jpg/png/etc формате — получить браузером сам рисунок. Ответ:

https://gist.github.com/candycode/f18ae1767b2b0aba568e

Разве только на канве «рисовать», но это еще медленнее будет, чем даже base64 дешифровать!

https://fccdl.in/GtnNfLmkW

И сам плеер и реалтайм screen cast viwer получает данные в бинарном виде из вебсокета, декадирует их на JS и отрисовывает на канвасе ...

https://gist.github.com/candycode/f18ae1767b2b0aba568e

Тоже мне, открытие! Я так уже 10 лет картинки отсылаю. Что и ругаюсь: очень черезжопное решение.

https://fccdl.in/GtnNfLmkW

Где исходники серверной части посмотреть?

Там обфусцированный код плеера в три экрана не влезает! Нафиг этот график! Это ж еще большее черезжопие!!! Если жабоскрипт элементарной функции превышает 1 экран, то явно что-то не так сделано.

Где исходники серверной части посмотреть?

Серверная часть вся на С++

Да пофиг. А еще лучше — не исходники, а описание алгоритма и протокола. Потому что до меня не доходит, как это можно сделать!

Если действительно это можно, и не будет тупить хотя бы на 5 кадрах в секунду, сделаю себе такое же!

А ты действительно хочешь работать с голыми вебсокетами и каждый раз городить свой велосипед с комнатами/хабами?
Все эти инструменты socket.io/SignalR etc. не просто дают фаллбек для старья, но и предоставляют некоторые абстракции типа комнат.

Проблема была не с NAT, а с прозрачными прокси, которые знали про HTTP, но не умели проксировать websocket.

Тоже мне, открытие! Я так уже 10 лет картинки отсылаю. Что и ругаюсь: очень черезжопное решение.

это же XMLHttpRequest а не websocket. можно попробывать еще сразу на сервере base64 отдавать и его в картинку вставлять по типу '<img src=«data:image/png;base64,' или сразу на канвасе рисовать

просто оно за собой тянет еще ответную серверную часть и навязывает писать на nodejs. мне бы хотелось какого-то другого решения типа websocketd но он не умеет пакетную обработку (на каждый запрос клиента заново запускает воркер) и совершенно не ясно что делать если произошло какое-то внешнее событие и мне нужно отправить какому-то клиенту сообщение. вот подключились у меня к wensocketd 10 клиентов и молчат, а в это время что-то случилось и мне нужно понять кому и как что-то оправить. как я понимаю websocketd такое не умеет. если бы умел все это - я думаю он был бы идеальным решением

Проблема была не с NAT, а с прозрачными прокси, которые знали про HTTP, но не умели проксировать websocket.

как с этим сейчас?

Без понятия. Либо всё везде работает, либо мне больше не попадались кривые провайдеры.

Удивительно: обычно когда люди что-то непонимают, они считают глупыми не себя, а того, кого не понимает :)

Поясни за «получить рисунок».

навязывает писать на nodejs

Отнюдь

http://search.cpan.org/~vti/PocketIO-0.17/lib/PocketIO.pm

фига, но perl не легче

если бы умел все это - я думаю он был бы идеальным решением

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

в стиле CGI это конкретно у websocketd, но ничто не мешает сделать свой аналог уже в стиле fastCGI

а тебе нужен сервер

сервер это процесс, это набор функций в конечном итоге. можно подумать backend на php это не сервер, а nodejs сервер

backend на php это не сервер

если он работает в mod_php, то естественно нет. Какой-нибудь phpDaemon - другое дело

$опа есть, а слова нет. пофигу что там на серверной стороне - факт в том что это серверная сторона которая реализует функции серверной стороны. а то что это отдельные процессы запускаемые на каждый чих как CGI, отдельные процессы обрабатывающие пакет запросов как FastCGI или отдельный демон выгребающий через epoll как nodejs - это все пофигу. так вот при подходе FastCGI есть возможность набросать быстро набросать прототип хоть на bash, а потом его конкретно ускорить переписав скажем на C++ и не заморачиваться на реализацию самих вебсокетов. а если мы изначально пишем на nodejs у нас такой возможности нет - все это прототипом и останется)))

http://img1.joyreactor.cc/pics/post/full/Комиксы-php-50-оттенков-серого-18945...