RTSP — это простой сигнальный протокол, который уже много лет не могут ничем заменить, и надо признать, что не особо стараются.
Скажем, есть у нас IP камера с поддержкой RTSP. Всякий, кто щупал трафик акула-кабелем, расскажет, что там сначала идет DESCRIBE, потом PLAY, и вот полился трафик напрямую по RTP или завернутый в тот же TCP канал.
WebSocket — это прогрессивный стандарт полнодуплексной (двусторонней) связи между клиентом и сторонним сервисом в режиме реального времени. Веб-сокеты используются для организации непрерывного обмена данными без разрыва соединения и дополнительных HTTP-запросов.
И мы рады сообщить вам, что все это стало возможным в Voximplant благодаря новому модулю VoxEngine, который называется – сюрприз – WebSocket. Отныне вы сможете передавать текст и аудио, пользуясь преимуществами веб-сокетов в полной мере. Проще говоря, у вас появился еще один инструмент, чтобы прокачать ваше приложение.
Из этой статьи вы узнаете, как создать исходящее WebSocket-соединение, передать через него аудиопоток и преобразовать его в текст с помощью Google Cloud Speech-to-Text API.Читать полностью »
Привет!
Меня зовут Саша и я работаю архитектором в Тинькофф Бизнес.
В этой статье хочу рассказать о том, как преодолеть ограничение браузеров на количество открытых долгоживущих HTTP-соединений в рамках одного домена при помощи service worker.
Если хотите — смело пропускайте предысторию, описание проблемы, поиск решения и сразу переходите к результату.
Работа с веб-сокетми позволяет в веб-приложении или в мобильном приложении организовывать отправку сообщений с сервера на клиент, что невозможно сделать средствами REST-API. Для работы с веб-сокетами часто используется библиотека socket.io, или же разработчики работают с нативными объектами веб-сокет браузеров. В этом сообщении я попытаюсь показать, что оба пути не решают всех проблем, и гораздо лучше использовать для работы с веб-сокетами специализированные серверы, например mqtt-сервер (раньше его назвали mqtt-брокер).
Справедливости ради, и чтобы избежать ненужных споров, сразу замечу, что кроме mqtt-сервера может быть использован еще целый ряд серверов, например rabbitmq.
Читать полностью »
О технологии websocket часто рассказывают страшилки, например что она не поддерживается веб-браузерами, или что провайдеры/админы глушат трафик websocket — поэтому ее нельзя использовать в приложениях. С другой стороны, разработчики не всегда заранее представляют подводные камни, которые имеет технология websocket, как и любая другая технология. По поводу мнимых ограничений сразу скажу, что технологию websocket сегодня поддерживают 96.8% веб-браузеров. Вы можете сказать, что оставшиеся за бортом 3,2% — это много, это миллионы пользователей. Я с Вами вполне соглашусь. Только все познается в сравнении. Тот же XmlHttpRequest, который все и уже не первый год используют в технологии Ajax, поддерживается 97.17% веб-браузеров (не сильно больше, правда?), а fetch — вообще, 93.08% веб-браузеров. В отличие от websocket, такой процент (а раньше он был еще меньше) уже давно никого не останавливает при использовании технологии Ajax. Так что использовать в настоящее время fallback на long polling не имеет никакого смысла. Хотя бы потому, что веб-браузеры, которые не поддерживают websocket — это те же самые веб-браузеры, которые не поддерживают XmlHttpRequest, и в реальности никакого fallback не произойдет.
Вторая страшилка, про бан на websocket со стороны провайдеров или админов корпоративных сетей — также необоснованный, так как сейчас все используют протокол https, и понять что открыто соединение websocket (не взломав https) невозможно.
Что же касается реальных ограничений и способах их преодоления, я расскажу в этом сообщении, на примере разработки веб-админки приложения.
Читать полностью »
Для приготовления асинхронных уведомлений из PostgreSQL в websocket нам понадобится сам nginx и его плагины postgres, push-stream, set-misc. (Я дал ссылки на свои форки, т.к. делал некоторые изменения, которые пока не удалось пропихнуть в оригинальные репозитории. Можно также воспользоваться готовым образом.)
Читать полностью »
Тема Websocket`ов уже не раз затрагивалась на Хабре, в частности рассматривались варианты реализации на PHP. Однако, с момента выхода последней статьи с обзором разных технологий прошло уже более года, а миру PHP есть чем похвастаться за прошедшее время.
В данной статье я хочу представить русскоязычному сообществу Swoole — Асинхронный Open Source фреймворк для PHP, написанный на Си, и поставляемый в виде pecl-расширения.
Посмотреть получившееся в итоге приложение(чат) можно: здесь.
Исходники на github.
Читать полностью »
Чтобы разработать современное веб приложение, необходимо иметь навыки как в создании серверной части, так и клиентской. Наиболее часто встречаемое в последнее время сочетание в корпоративной среде — это Java c использованием Spring Framework для сервера и React для клиента. Однако не все разработчики обладают Full stack навыками (знаниями как в серверной так и в клиентской части), а для начинающих разработчиков создание такой конфигурации оказывается совсем непосильной задачей.
Итак, вот готовое решение, которое позволит научиться создавать подобные конфигурации, а также экономить время при старте нового проекта.
Читать полностью »
При решении повседневных задач с интерфейсом настольного приложения, реализованного на JavaFX, приходится в любом случае делать запрос на веб-сервер. После времен J2EE и страшной аббревиатуры RMI многое изменилось, а вызовы на сервер стали более легковесными. Как нельзя кстати для подобной проблемы подходит стандарт веб-сокетов и его обмен простыми текстовыми сообщениями любого содержания. Но проблема корпоративных приложений в том, что разнообразность и количество запросов превращает создание и отслеживание EndPoint-ов при наличии отдельно выделенных бизнес-сервисов в жуткую рутину и добавляет лишних строк кода.
А что если взять за основу строго типизированную стратегию с RMI, где между клиентом и сервером существовал стандартный java interface, описывающий методы, аргументы и возвращаемые типы, где добавлялось пару аннотаций, и волшебным образом клиент даже не замечал, что идет вызов по сети? Что если по сети передавать не просто текст, а сериализованные java-объекты? Что если добавить к этой стратегии легкость веб-сокетов и их преимущества возможности push-вызовов клиента со стороны сервера? Что если асинхронность ответов веб-сокета для клиента обуздать в привычный блокирующий вызов, а для отложенного вызова добавить возможность возвращения Future или даже CompletableFuture? Что если добавить возможность подписки клиента на определенные события от сервера? Что если на сервере иметь сессию и подключение к каждому клиенту? Может получиться неплохая прозрачная связка привычная любому java-программисту, так как за интерфейсом будет скрыта магия, а в тестировании интерфейсы легко подменить. Но вот только это все не для нагруженных приложений, обрабатывающих, например, котировки с фондовой биржи.
Для тех кто не в курсе: LAppS — Lua Application Server, это почти как nginx или apache, но только для WebSocket протокола, вместо HTTP.
HTTP в нём поддерживается только на уровне Upgrade запроса.
LAppS изначально затачивался на высокую нагрузку и вертикальную масштабируемость, и сегодня достиг пика своих возможностей на моём железе (ну почти, можно и дальше оптимизировать, но это будет долгий и упорный труд).
Самое главное, LAppS по производительности WebSocket стека, превзошёл библиотеку uWebSockets, которая позиционируется как самая быстрая WebSocket имплементация.
Заинтересованных прошу под кат.
