LINUX.ORG.RU

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

 ,


0

0

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

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

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

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

pon4ik ★★★★★
()
Последнее исправление: pon4ik (всего исправлений: 1)
Ответ на: комментарий от pon4ik

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

I-Love-Microsoft ★★★★★
() автор топика
Ответ на: комментарий от pon4ik

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

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

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

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

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

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

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

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

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

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

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

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

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

Chaser_Andrey ★★★★★
()
Ответ на: комментарий от Chaser_Andrey

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

И что за «гетерогенная среда»

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

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

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

pon4ik ★★★★★
()
Ответ на: комментарий от I-Love-Microsoft

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

pon4ik ★★★★★
()
Ответ на: комментарий от pon4ik

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

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

I-Love-Microsoft ★★★★★
() автор топика
Ответ на: комментарий от I-Love-Microsoft

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

pon4ik ★★★★★
()
Ответ на: комментарий от Chaser_Andrey

Таки не удержусь:

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

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

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

pon4ik ★★★★★
()
Ответ на: комментарий от pon4ik

А если это ещё и поддерживать надо, то смысл для примитивного кейса брать кресты?

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

Chaser_Andrey ★★★★★
()
Ответ на: комментарий от pon4ik

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

Согласен, что Qt - далеко не Boost.Asio, но, тем не менее, производительность может быть очень не плохой, если перед нами нет проблемы 10k соединений (из-за poll внутри). Тесты я делал сам, жаль они не сохранились, но оно работало достаточно быстро для поставленных задач.

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

Chaser_Andrey ★★★★★
()
Ответ на: комментарий от Chaser_Andrey

Поддержка (в общем случае), это не когда аффтору удобно, а когда, если автора сбил камаз, можно спокойно взять нового специалиста и его wtf p/s будут < 1.

pon4ik ★★★★★
()
Ответ на: комментарий от pon4ik

Это уже выходит за рамки технического обсуждения, и пусть этим занимаются менеджеры/тимлиды.

Chaser_Andrey ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.