На чем сейчас многопоточные TCP сервера на си++ пишут

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

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

Не доверяю всяким современным штучкам вроде брокеров сообщений.

А ты попробуй. Что доверять то? :) Тем более, делается очень быстро.

у тебя нет нагрузки (пока) но есть необходимость доставить сообщение как можно быстрее. или ты берешь готовый брокер/клиент mq который решает за тебя задачу по пересылки сообщений и дает тебе время сосредоточится на самой задаче или ты пилишь велосипед с которым потом огребаешь.

с первой страницы ему вещаем про mq

Клиенты на линуксе, разные SoC

А что с ограничениями SoC? Насколько узкие каналы? Насколько надежная сеть? Будешь ли ты проверять состояние сети руками(всякие half-closed)? Нужно ли шифрование? Сколько у тебя железа и какого?

Самый простой вариант Go + gRPC или http2/3. http3 хорош тем, что в нем нет TCP(местами из-за этого и плох). Если с неба свалится пара тысяч новых железок, то ты всегда можешь поставить машину с XDP/ipvs балансером, который уже будет разбрасывать нагрузку по нескольким инстансам Go/серверам, если упрешься в CPU/сеть etc. Go это Си с GC и указателями(без арифметики). Свой веб сервер имеет смысл писать только в том случае, если у тебя есть много свободного времени и морально ты готов по завершению процесса написать rm -rf server и взять nginx/envoy/haproxy/etc в зависимости от хотелок.

Kore.io

Железо на raspberry pi, еще там разные специфические платформы с линуксом. Надежность каналов, очень сложно сказать, часто что-нибудь отваливается, так что реконнект с клиента должен быть как с добрым утром. Шифрование не нужно.

Perl это прекрасно, жаль коллеги не понимают

Странные вы ребята. Если мне сказали, что кто-то начал писать собственный tcp сервер на С++, я бы его уволил за профнепригодность.

за проф не пригодность увольняют тех кто пишет тцп удп серверы не на С++

Если мне сказали, что кто-то начал писать собственный tcp сервер на С++, я бы его уволил за профнепригодность.

Хорошо, что у тебя нет таких полномочий

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

Тебе не кажется, что это зависит от того, что именно делает сервер? Или у таких профессионалов как ты, количество обслуживаемых запросов в секунду от решаемых по запросам задач не зависит?

А ты наверное из тех, кто думает, что написав велосипед на С++ ты получишь значительныей прирост в производительности? Я тебя огорчу. Программа на perl может оказаться быстрее твоего кривого велосипеда, поскольку ее писали очень опытные люди.

Ну я выбрал си с классами, т.к. там больше контроля над сокетом и т.д. меньше всего скрыто под капотом. Тут все понятно socket, bind, listen, accept. А то сейчас стало модно

server= CreateTcpServer(ip='127.0.0.1', port=31337, num_threads=10001"); server.run()

Как это связано с тем, на что ты отвечаешь? Ты в лучших традициях «эксперта» сделал нелепейшее заявление о C и C++. Не уточнил даже, о какого рода задачах, решаемых сервером, идет речь.

Программа на perl может оказаться быстрее твоего кривого велосипеда

Почему ты считаешь, что на перл у тебя будет программа, а на С++ будет велосипед? Это не от языка зависит.

А чтобы нормальная программа на перл оказалась быстрее нормальной программы на плюсах, тебе нужно очень постараться на перл и/или очень «постараться» на плюсах.

Так можно и на плюсах.

Зачем тебе для твоей задачи «контроль над сокетом»? Что ты собрался контролировать?

Реконнект, я пока даже не совсем понял, что с этим делать, вот клиент вызовет коннект с сервером, а потом ведь надо как-то проверять, что соединение не разорвано. Это интересный вызов.

Точно не на C++

Это интересный вызов.

Вот скажите, вы там у себя на работе работу делаете или личные вызовы сами себе устраиваете?

Или это не работа, а курсач в универе?

ты уже второй день тут лясы точищ. а мог бы уже сделать прототип на MQTT.

Я бы сказал так, что если я налажаю, будут очень печальные последствия. Если что-то пойдет не так, будут тоже очень печальные последствия, а в выборе технологий я свободен и по времени тоже не то что бы очень ограничен. Для меня главное, что бы ничего ни при каких обстоятельствах не отваливалось никогда, а если отваливалось, то само восстанавливалось, т.к. устройства будут установлены на удаленных промышленных объектах, где персонал, максимум по питанию сможет их перегрузить. Из-за этого я немного опасаюсь брать всякие аналоги mqtt, что там у них под капотом. Устройств будет ну максимум 200-400. Сейчас они на гет запросах работают, но гет запросы идут раз в минуту, хотелось бы уйти от модели пассивного сервера к активному серверу.

Я вообще запланировал недели три выбирать на чем делать.

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

Ну и еще было время, работал в одной компании, там был сервер на несколько тысяч устройств на перле. Затем его решили на си++ перепсать, но первое переписывание было запорото. Одна команда ушла, а вторая не смогла разобраться в коде предыдущий. На перле где-то за пару месяцев один человек сделал, а на си++ второй раз около года переписывало трое как раз на boost asio.

Ок. Убедили. Попробую очередь.

Для меня главное, что бы ничего ни при каких обстоятельствах не отваливалось никогда, а если отваливалось, то само восстанавливалось

Если при всех этих требованиях вы не имеете представления о том, как делать контроль жизнеспособности соединения и реконнект, то налажаете обязательно. Се-ля-ви. Когда делаешь что-то с нуля в первый раз, то лажаешь.

Мне другое непонятно: неужели вы думаете, что вы способны в одиночку сделать лучше, чем то, что за много лет разные люди совместно сделали в таких проектах, как Paho и libmosquitto?

Нет конечно. Все что мне нужно, слать три-четыре команды в ASCII от сервера устройствам.

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

а на си++ второй раз около года переписывало трое как раз на boost asio

Т.е. ты рассчитываешь, что тебе год будут платить за такую работу? Я думаю, тебя надо уволить.

после тсп сервера на перле, идите дальше админьте

Какие конкретно претензии к «тсп серверу на перле»? Несколько тыс. коннектов в секунду мало?

Может он работает где-нибудь в Урюпинске в госконторе с зарплатой в 15K rub/месяц.

Я вообще не понимаю логику ТС. У него уже был опыт. «На перле где-то за пару месяцев один человек сделал, а на си++ второй раз около года переписывало трое как раз на boost asio.» Но он решает повторить ошибку коллег.

Мы не знаем, кто были эти трое. Если с таким же уровнем, как у ТС-а, то неудивительно.

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

масштабировать когда девайсов выросте до сотни тысяч

Думаешь перепишешь с перла на с++ и он автоматом начнет поддерживать «сотни тысяч»? Я тебе сразу скажу, у тебя не получится. Это решается совсем другими методами.

Ну это не у меня был опыт, проблема с perl встала когда человек уволился, а код его поддерживать стало некому. Претензий у меня к perl никаких, наоборот, я люблю perl, но никто из окружающих меня коллег и знакомых perl не знает и знать не хочет. Количество устройств скорей всего будет максимум 2-3 сотни. Меня больше настораживает момент активного сервера, ведь клиетам постоянно будет реконнект делать, т.к. соединение будет за NAT. Может быть проще клиентам раз в секунду пытаться к серверу присоединиться и получить команду, но это создаст ненужную нагрузку, ведь логичней клиенту один раз подсоединиться, затем проверять соединение и ждать пока сервер ему отдаст команду.

На оконечных устройствах клиентская часть может быть на чем угодно, perl, python. Там очень урезанный linux, так что можно что попроще.

это ты мне после 10 лет сетевых разработок будешь рассказывать ?
питонь дальше свое админство

вы архитектор ? если все так просто(а это не так), то зачем эта тема ? для поговорить ? идите запускайте на питоне или перле

Питон.

Изначально я даже не задумывался, что можно использовать протоколы класса AMQP, а теперь буду рассматривать эту возможность. Тема для меня относительно новая, хочется послушать кто и как делал, попробовать.

можно использовать протоколы класса AMQP

Ну как бы протоколы AMQP и MQTT сильно разные по своей «тяжести», поэтому их можно рассматривать как относящиеся к разным классам. И если MQTT для вашей задачи (на основании того, что вы здесь уже написали) выглядит вполне естественным, то вот для затаскивания AMQP нужны серьезные основания.

Хотя, есть подозрение, что вы просто не понимаете, чем AMQP отличается от MQTT.

Не верю, что я это пишу, но попробуй на Go запилить. Или хотя бы глянь его. Мне кажется, меньше проблем будет, чем с плюсами. Сам язык в восторг меня не приводит, но своеобразная обработка ошибок в нем, на мой взгляд, повысит надежность твоего проекта.

P.s. я не гошник, хотя этот язык использую - камнями не кидать.

на Go

на bash

Вы правы, я абсолютно не понимаю, что это такое, но планирую в тестовом режиме внедрить. Имел в виду конечно MQTT.

Не верю, что я это пишу, но попробуй на Go запилить. Или хотя бы глянь его. Мне кажется, меньше проблем будет, чем с плюсами. Сам язык в восторг меня не приводит, но своеобразная обработка ошибок в нем, на мой взгляд, повысит надежность твоего проекта.

С go-lang почти не знаком. Там обработка в стиле языка rust? То есть, она явная, и пока ты ошибки все не обработаешь, то компилятор от тебя не отстанет?