Выбор технологии для сервера TCP-соединений

Question

[levap]

Помогите определиться с технологией (а еще лучше — готовой библиотекой) для реализации сервера TCP-соединений. Количество одновременных соединений максимально большое, объем передаваемого трафика при этом минимальный. Обмен двунаправленный.

Проект — сервер сбора телеметрической информации с GSM-терминалов. Целевая платформа Linux. Язык не особенно важен, вероятнее всего С++, Java.

Answer 1

[Wedmer]

Самый быстрый старт дает libSockets, но могут быть проблемы с гибкостью.
Asio дает кроме самих сокетов инструмент сервисов, которые, если понять как они устроены, позволяют получать очень гибкие решения.
Ну и есть классика реализации на нативных сокетах без лишних обвязок.
libevent не пробовал.
Ну и не стоит забывать о Qt. Второй по скорости старт из вышеперечисленных.

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

Answer 2

[ixSci]

boost::asio?

Comments

[levap]

С boost::asio работал, это было бы для меня неплохим решением, но по результатам разных тестов производительности, найденных в инете, библиотека не слишком тороплива. Был ли у вас личный опыт использования ее при большом числе одновременных соединений? 99% времени соединения не будут генерировать трафик.

[ixSci]

Личного опыта нет. Что за тесты? Я, как раз, слышал обратные утверждения.

[levap]

Ну хотя бы вот эта статья рядышком: habrahabr.ru/post/152345/
Хотя у ее автора несколько иная задача — там веб-сервер.

[Владислав]

Есть положительный опыт использования при сотнях соединений (до 1024 пока что) и сотнях мегабит прокачиваемого трафика (пока до 900).

По своему опыту могу сказать, что если Вы еще не писали на ASIO высокопроизводительных серверов, то с первого раза будет медленно. Но с применением профайлера, выкидыванием лишнего копирования данных (мне пришлось написать обертку вокруг цепочек буферов, которая хранит указатель на цепочку, а интерфейс как у цепочки (const/mutable_buffers), чтобы избежать копирования этих цепочек внутри ASIO), лишних аллокаций памяти (с использованием Custom Memory Allocation, forum.vingrad.ru/forum/topic-321111/view-all.html) и т.д. можно написать быстрый сервер.

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

[levap]

Ну, напильник в руках держать вроде еще не разучился, так что думаю разберусь :) Хотя опыт программирования на Java немного расслабил за последнее время.

Answer 3

[unSeen]

Обратите свое внимание на libuv: github.com/joyent/libuv

Answer 4

[Ramires]

Немного похожий вопрос. Там было много интересных ссылок.

Answer 5

[Stdit]

К перечисленному добавлю, что многие хвалят nodejs в плане «огромное количество соединений» и скорости разработки. Я его тоже использовал в качетсве tcp-сервера в двух проектах, но они не особо наргужены, поэтому рекомендвоать однозначно пока рановато. Асинхронная архитектура ECMAScript вкупе с событийной моделью понравились. Скорость работы хорошая. Сборщик мусора пока что не подводил. Хотя могут быть и грабли. Например, я не нашел там поддержки TCP_KEEPCNT и других опций setsockopt.

Answer 6

[levap]

Спасибо всем за ответы! Буду теперь перелопачивать информацию. Помечу последний ответ как решение.

Answer 7

[v- smerti]

golang без всяких библиотек вам подойдёт. сервер на нём поднимаю за 5 минут (написал, скомпилил, запустил) так что дерзайте)