Websocket server c linux

библиотека для WebSocket сервера

Какую библиотеку для работы с WebSocket в качестве сервера можете порекомендовать для применения для языка C/C++? Разумеется, кроссплатформенную, чтобы и под UNIX-like была и под оффтоп.

Гугл дает несколько вариантов, так как нуб — хотел бы послушать советов.

и так далее, в общем, до чертиков, не могу определиться что же лучше?

Появилось недавно, Since: Qt 5.3. Был не в курсе. Крутобл! Просто я Qt-шнег 🙂

Just read incoming text from stdin and write outgoing text to stdout. Messaging is simple.

Прикольно! А под оффтоп это есть?

PS Но я скорее на qwebsocketserver уже настроился.

Available for Linux, OSX, Windows, FreeBSD, OpenBSD and Solaris

Web приложение на c++, да ещё и на Qt, это слегка моветон — много усилий ради никакого профита, и потери горизонтальной масштабируемости как минимум в гетерогенной среде(разумеется если речь идёт о минимальных издержках).

Либо у тебя там нужна аццки низкая латентность, но Qt тогда всё равно мимо. Либо твоё решение изначально рассчитанно на небольшую аудиторию и отсутсвие её роста.

может он просто веб-морду к qt-шной проге пишет.

Буду краток: это мелкосерийная поделка, связь аппаратного устройства с большим web-приложением на серверной стороне. WebSocket удобный интерфейс в данном случае, хотя не мне было решать.

Web приложение на c++, да ещё и на Qt, это слегка моветон

Какая разница, что на бэкэнде, если работа бэкэнда чаще всего сводится до получения данных из БД и примитивной обработке?

много усилий ради никакого профита

Слишком опрометчивое заявление. Тот, кто хорошо знает C++, напишет на нём достаточно быстро. На Qt это вообще пишется в пару строчек.

и потери горизонтальной масштабируемости как минимум в гетерогенной среде

Почему? И что за «гетерогенная среда»? Как по мне, так достаточно поставить спереди HAProxy, пусть раскидывает коннекты на бэкэнды.

Либо у тебя там нужна аццки низкая латентность, но Qt тогда всё равно мимо.

Мимо. Qt достаточно эффективно работает. Внутри имеем poll, который хорошо работает на десятках и сотнях коннектов. Реализация протокола в QtWebSockets адекватная, и с обычной оптимизацией -02 показывает хорошие результаты. Я делал такое для внутренних нужд предприятия, но тогда я вообще писал свою реализацию, которая хуже по производительности, чем в QtWebSockets, и, тем не менее, она была очень быстрая, и её хватало с запасом. Даже переписывать на что-то другое не было смысла.

Не вводи людей в заблуждение.

Либо твоё решение изначально рассчитанно на небольшую аудиторию и отсутсвие её роста.

1. Не всё решает масштабы аудитории, есть ещё и «качество». В некоторых проектах аудитория маленькая, но лучше монетизируется.

2. Порой быстрое появление прототипа важнее.

Я не хочу сказать, что QtWebSockets — это мегакруто, но оно имеет свою область использования. И зачем программисту на C++/Qt тратить кучу времени, чтобы написать что-то на «модном» языке и фреймворке, если он это же может сделать намного быстрее и удобнее на «родном» для него языке?

В основном разница в том как это потом поддерживать и масштабировать. Кресты тут не в лидерах, хотя разумеется с ними можно делать и то и то.

Ммм, это такая вот среда где на сервера кластера разные оси поставленны, возможно с разными архитектурами.

Qt, работает достаточно эффективно для ui фреймворка, а не для серверного приложения, в сети есть тесты, погугли как бы.

Я просто к тому, что автор мог бы написать своё поделие на торнадо или рельсах за 2 часа, и решать проблемы с производительностью докупанием сервера в кластерок, заместо поедания кактуса. Либо он таки знает что делает и смело пропустит моё сообщение мимо глаз.

Ну я как бы на всякий, а то некоторые любят пожёще, а потом хорошие проекты скатываются в уг из за этого 🙂

Неее, мои проекты самые лучшие всегда 🙂

Моя задача простейшая — получать команды от другого приложения на node.js (не я пишу его) и работать типа с аппаратным устройством, команды простейшие, обращения редкие, производительность не критична и QtWebSockets хорошо подходят для обмена с таким вэбанутым приложением 🙂 Я даже сделал предварительно на python + какой-то код для WebSocket дёрнул — всё работает, если бы не проблемы деплоя — так и заюзал бы python, просто с py2exe не очень работал и мне проще Qt.

Ну кстати для такого рода поделок питончик крайне неплохо подходит, только под винду да, бывают сюрпрайзы 🙂

Какая разница, что на бэкэнде, если работа бэкэнда чаще всего сводится до получения данных из БД и примитивной обработке?

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

Как бы надо выбирать инструмент под задачу 🙂

Юзал http://libwebsockets.org , что-то не понравилось (что-то падало), запилил свою либу с нуля. Проект: http://obsuditor.ddns.net/ftt/ (всё на плюсах, кроме клиента — JS). Исходники пока дать не могу, их надо почистить. Под винду собирать не пробовал.

А если а сообщении перевод строки?

Ну пайпы же как-то справляются с этим :3

Ну там по всех примерах циклы с обычными print/ printf, а в WebSockets явный deliminiting, получается может улететь два сообщения от неудачного перевода строки

Источник

Как использовать Websocket на примере простого Express API?

Краткое описание технологии

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

Для установления соединения WebSocket клиент и сервер используют протокол, похожий на HTTP. Клиент формирует особый HTTP-запрос, на который сервер отвечает определенным образом.

Несмотря на «похожесть» новых запросов и ответов на запросы и ответы протокола HTTP, они таковыми не являются. Например, в запросе есть тело, но в заголовках поле «Content-Length» отсутствует (что нарушает соглашения HTTP). Подробнее об этом можно прочитать в Википедии.

Одним из главных преимуществ технологии — это ее простота. На клиенте и сервере есть всего 4 события для обработки:

Почему Websocket?

Кроме ws существуют еще два способа непрерывной передачи данных: Server-Sent Events (SSE) и Long Polling.

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

Одним из главных преимуществ технологии ws — это скорость передачи данных. SSE и LP используют протокол HTTP(S) и работают примерно так:

1. Делаем запрос на изменения;
2. Если изменения на сервере появились, то сервер их отправляет;
3. Когда клиент получает изменения, клиент делает новый запрос.

Выводы:

1. Вебсокет не требует от клиента постоянно запрашивать изменения и именно поэтому он быстрее.
2. Вебсокет позволяет передавать бинарные данные, что не позволяет протокол HTTP(S).
3. Вебсокет не нужно использовать, если проект требует совместимость со старыми версиями браузеров. Читать о совместимости с браузерами

Пример работы простейшего api.

Что здесь происходит?

Чтобы создать сервер поддерживающий ws, мы создаем обычный http сервер, а потом привязываем к нему при создании websocket сервер.

Функция “on” помогает управлять событиями websocket. Самым примечательным является событие message, так что рассмотрим его подробнее.

Здесь функция получает параметр m — сообщение, то есть то, что отправил пользователь. Таким образом мы можем отправить с клиента строку и обработать ее на сервере. В данном случае сервер просто пересылает это сообщение всем, кто подключен к серверу websocket. Массив clients объекта webSocketServer содержит все подключения к серверу. Объект ws в то же время хранит данные только об одном подключении.

Не стоит использовать такой подход в реальном приложении. Если описать api таким образом, то сервер не может отличить один запрос от другого. О том, как можно построить api на основе websocket будет написано далее.

Взаимодействие с сервером на клиенте будет выглядеть так:

API на основе Websocket

В отличие от REST API, где запросы распределены по разным url, Websocket API имеет только один url. Для того, чтобы построить полноценное API на основе вебсокетов, необходимо научить систему отличать один запрос от другого. Это можно реализовать следующим образом:

1) С клиента мы будем передавать запросы в виде строки-json, которую распарсим на сервере:

2) На сервере мы распарсим строку и выделем в ней поле event — тип запроса. Пропишем для каждого типа соответствующий ответ:

Таким образом мы можем отправлять разные запросы на сервер и обрабатывать ответ в зависимости от запроса.

Источник