Какую библиотеку выбрать для написания tcp сервера?
Передо мной стоит задача по сбору и обработке данных. Часть алгоритмов реализована на c++, часть на python. На данный момент используется клиент-серверная архитектура приложения, реализованная костылем, довольно громоздкая, через простые сокеты. Стоит задача заменить костыль на масштабируемое решение, кроссплатформенное (как минимум windows-linux, как максимум - ещё и мобильные платформы). Я нагуглил, что как будто бы для решения подобной задачи мне подойдёт библиотека POCO, написанная на c++. Обработка данных идёт в режиме реального времени, поэтому скорость - немаловажная составляющая. Как Вы полагаете, подойдёт ли эта библиотека под мою задачу? Можете ли посоветовать альтернативы? Нужны ли ещё какие-то вводные данные чтобы ответить на данный вопрос?
Алан Гибизов, вроде я написал, что часть алгоритмов написана на python. И если есть вариант использования для моих целей модулей python, меня эти варианты также интересуют
Pavel97P, отлично! Именно так и следует поступать. Если суть вопроса не в некорректной работе кода python, не в нюансах реализации какой-то версии python, то достаточно просто упомянуть в названии вопроса. См.п.3.1 Регламента.
То же и относительно любых других языков.
Алан Гибизов, речь идёт и непосредственно о python. Какой модуль может быть целесообразно использовать в моем случае? Разве разработчик c++, который не пишет на python, может дать совет по этому поводу? Когда речь идет о том, какое видео посмотреть, чтобы выучить python, тег уместен, а вопрос о том, какой использовать модуль - уже нет?
Pavel97P, прочтите Регламент п.3.1 и просто его выполняйте.
Подписчикам тэга python, которых 40 тыс., ни к чему знать о ваших страданиях по выбору библиотеки для работы с сетью. Те из них, кто подписан на тэг сети, обратят внимание на ваш вопрос. А кто не подписан, вам всё равно не помощник.
Алан Гибизов, действительно. Компьютерные сети - это же непосредственно программирование. К администрированию никакого отношения не имеют. И подавляющее большинство подписчиков этого тега пишут вэбсервисы на python
Pavel97P, у вас проблема конкретно с python? Где код? Где traceback? Если нет - вам не в тэг python. Точка.
Подходит ли он под тэг «сети», не берусь утверждать. Вы сами его установили.
И вообще: На вопрос «как сделать» отвечает документация и поиск в интернет.
Тут отвечают на вопросы типа «почему я сделал, как в документации, а оно не работает. Поискал в интернет, вот запросы, в ответах не нашел. Что я делаю не так?»
Покажите, как вы пробовали решить проблему, приведите код попытки (пусть неудачной), опишите, как запускали, что ожидали и что получилось.
За готовыми решениями - на фриланс. В текущем виде это не вопрос, а задание. Нарушен п.5.12 Регламента.
Если приложение нужно для анализа поступающих данных, то просто пишите все входящие запорсы тем же nginx в лог, а потом читайте его и анализируйте (складывайте в БД)
Нужны ли ещё какие-то вводные данные чтобы ответить на данный вопрос?
В текущем виде твой вопрос без воды выглядит так:
У меня есть клиент-серверное приложение написанное при помощи Python и C++, которое занимается работой, которую можно описать очень широким понятием "обработка данных".
Его хочется переписать, но я не знаю на что.
Такого количества вводных, конечно, недостаточно.
1. Сколько данных в секунду/минуту поступает? Сообщений, байт. Замеряй в несериализованном виде - чисто количество данных, как в школе на уроке информатики. Что это за данные? (Ответит на вопрос о желаемой пропускной способности)
2. Сколько клиентов? Все ли они одновременно шлют запросы и ждут ответы? (Ответит на вопрос о нужном количестве активных соединений)
3. Какая вообще задержка после отправки клиентом запроса допустима, чтобы оставаться в реальном времени? Что вообще считается за факт, что запрос обработан? Например это может быть получение клиентом http-ответа, ответное сообщение в сокете или просто факт выполнения какой-то работы без ответа. Чем обоснованная такая задержка? (Ответит на вопрос о необходимых задержках)
4. Ты упомянул мобильные устройства. На них будет клиент? Или и сервер тоже?
Ты упомянул Windows - на нём будет клиент или и сервер тоже?
Ты упомянул Linux - на нём будет сервер? Или клиент тоже?
5. Нужна ли обратная совместимость со старой версией приложения? (Ответит на вопрос, нужно ли оставаться в рамках сырых сокетов)
6. Допустимо ли переписать весь код, или хотелось бы хоть что-то использовать повторно?
Kano, "обработка данных" - это очень широкое понятие. Не советую делать поспешных предположений.
"Лог", я так понял, в вашем понимании - это Kafka, но автор может ошибочно предположить, что это диагностические логи приложения, тк он новичок, что можно понять из вопроса.
Василий Банников, я имел в виду обычный лог который пишет nginx на диск. Который может считывать и укладывать в бд какое нибудь стороннее решение (https://github.com/mintance/nginx-clickhouse). Кафка тут будет не столь эффективна и стабильна как простая запись в файл
Kano, мне кажется, это совсем не то что хочет автор вопроса.
То что ты предлагаешь - это решение для собственно анализа логов нжинкса, а у автора ни логов ни нжинкса нет.
Василий Банников, "стоит задача по СБОРУ и обработке данных" вот я и даю рекомендации по сбору которые помогут весьма не плохо уменьшить сложность разработки
Grpc например? Или zeromq например?
Весь вопрос в том, какой тип взаимодействия подразкмевается, и на каких языках...
Но в боььшинстве своем обычно выбирают http и json...
В данный момент ничего нет. Но мне нужно несколько изменить архитектуру, перейти к небольшим вэбсервисам, не только для обработки, данных, но и для визуализации результата, возможной передачи на постобработку и т.п. Если писать на сырых сокетах - весьма трудозатратное получается масштабирование, опять же будет не мало времени потрачено на отладку непосредственно сервера, а не ключевых функций. Я сомневаюсь, что моя задача уникальна, ведь есть множество серверов под http тот же. Можно использовать qt, но обычно когда я читаю отзывы о qt в контексте сервера, мнения в основном негативные (не знаю, сколько уж тут объективности).
Но мне нужно несколько изменить архитектуру, перейти к небольшим вэбсервисам, не только для обработки, данных, но и для визуализации результата
Можно использовать qt, но обычно когда я читаю отзывы о qt в контексте сервера, мнения в основном негативные (не знаю, сколько уж тут объективности).
Разработка веб-сервисов на с++ это не очень удачная идея. Практика показывает что разрабатывать
дорого а разница между реализацией апример в GoLang / Node и С++ - небольшая. Задачи
в основном - взять реквест и толкнуть данные в БД или в очередь. На таких задачах С++ не рулит.
Никаких преимуществ не имеет. Основная нагрузка идет на I/O и дисспетчеризацию сетевых
событий.
У вас есть опыт писательства С++ но нет опыта в других? Что-ж... может быть настало время
получать этот опыт.
Простой
