C ++ TCP-сервер Дизайн класса

Question

Я разрабатываю TCP-сервер на C ++ (win32 / linux), который обслуживает несколько клиентов. Сервер предназначен для потоковой передачи видео. Клиент запрашивает видео на сервере, и сервер получает его от шлюза, связанного с камерой.Я застрял в классе Design.I нашел три класса

1. Peer
2. Session и
3. ConnectionMgr.

Такздесь ConnectionMgr отвечает за управление другими классами.

Я хотел бы получить ваши отзывы об этом.

1. какую информацию должен иметь Peer и сеанс;
2. Как Peer и сеанс
3. какая информация должна быть смоделирована здесь.
4. как это сделать Сеанс сопровождающий.
5. Для управления несколькими клиентами потребуются потоки, которые могут понадобиться этой информации.

Пожалуйста, оставьте свой отзыв, чтобы я мог обновить свой дизайн.

Answer 1

Как отметили @nabulke и @Jan Hudec в своих комментариях, Boost.Asio - очень хорошее решение для вашей проблемы. Взгляните на довольно простой пример "Async TCP Echo Server" . Он использует только 2 класса: server и session. Нет session_manager. Сеансы управляются автоматически с помощью умных указателей, очень удобный и простой подход.

Используя Boost.Asio , вы можете сохранить сетевую часть простой (и почти оптимальной по эффективности, используя асинхронную обработку). В качестве бонуса, добавив пару строк кода, вы получите многопоточный сервер без головной боли (я бы рекомендовал следующий пример: "HTTP-сервер, использующий один io_service и пул потоков, вызывающий io_service :: run ()." , просто игнорируйте HTTP-компоненты. Обратите внимание на boost::asio::io_service::strand, используемый в connection классе)

Answer 2

Глядя на проблемное пространство с нуля:

• с каждым клиентом, который подключается, есть какое-то состояние - вы, кажется, разделите это между Peer и Session, и я не вижу реальной ценности в том, что если они 1: 1 - можно пропустить такие пустяки на этапе проектирования высокого уровня.
  • «какая информация должна быть у Peer и сеанса»: дескриптор сокета является единственной важной вещью, при условии, что у вас есть только одна камера и поток для всех клиентов с одинаковой скоростью (потеря данных, когда сокет send () блокирует / не может завершено из-за полного буфера), в противном случае буфер тоже ...
• у вас есть ConnectionMgr, хорошо - да ... он должен прослушивать и принимать клиентов на сокете сервера, возможно запускать новый поток для каждого клиента или отслеживать набор текущих клиентских подключений и событий отправки
• вам нужно будет принять некоторые решения относительно модели ввода-вывода и модели параллелизма (например, выбрать / опрос / неблокирование, асинхронность, блокировка, однопоточный, поток-на-клиент, поток-пул и т. Д.)
  • это, очевидно, повлияет на ваш дизайн: вы должны решить, какой - или какой выбор - вам нужно поддерживать ...

Чтобы почувствовать эту проблемную область, я предлагаю вам создать очень простую клиент-серверную программу - вероятно, использующую потоки, если вы знакомы и знакомы с многопоточностью, в противном случае вы можете взломать примеры GCC libc TCP клиент / сервер. для решения на основе select () (http://www.gnu.org/s/libc/manual/html_node/Server-Example.html#Server-Example) или попробуйте boost :: asio или ACE и т. д.). Для начала просто включите его, чтобы вы могли подключиться к серверу через telnet, и все, что вы вводите в любом соединении, отображается во всех соединениях. Это должно дать вам достаточно понимания, чтобы начать задавать более конкретные вопросы.