LINUX.ORG.RU

Пример разработки простого многопоточного сетевого сервера: Часть 4. Обзор методик ввода/вывода в применении к сетевым соединениям

 многопоточный сетевой сервер


0

0

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

В предыдущих статьях цикла мы рассматривали некоторые стороны внутренней работы и внутреннего устройства нашего сервера. Теперь приступим к разбору сетевого взаимодействия нашей программы с другими: посмотрим, как можно организовать серверную часть соединения по протоколу TCP и познакомимся с несколькими вариантами ожидания входящих данных. Кстати, вопрос ожидания данных не так прост, как может показаться на первый взгляд, так как чем дальше (в контексте сетевой топологии) программа-клиент от нашего сервера и чем хуже канал связи с ней, тем сложнее наладить надёжное взаимодействие между программами. Задача разработчика на этом этапе – приложить максимум усилий к тому, чтобы на серверной стороне эффективно использовались все возможные средства и способы для надёжной передачи данных. Хорошая новость здесь в том, что многие задачи уже решены разработчиками TCP, однако нам нужно не похоронить толковые идеи разработчиков TCP, а использовать их на благо своего приложения.

>>> Подробности

Ответ на: комментарий от Kompilainenn

> неужели я первый? видать тема весьма интересная для лоровцев...

Даже Силви смотрит сериал с Эдуардом Шишкиным! Остальные окунулись в дизайн Ubuntu.

Интересно, если на ЛОРе нет пользователей Linux, то где они?

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

Так и есть, по сцылке видим
Дата:  24.06.2010
Уровень сложности:  средний
Активность:  187 просмотров

valich ★★★
()

Пичаль.

Возмжно, убогим, ниасилившим Стивенса, сия статья будет полезна.

anonymous
()

> Соединение клиента с сервером можно представить как некоторый разъём, в котором гнездовая часть расположена на стороне сервера, а штыревая – на стороне клиента. Геометрию (физическую форму) разъёма можно рассматривать как аналог сетевого протокола. Штыревая часть обычно создаётся клиентом непосредственно перед его обращением к серверу, тогда как гнездовая часть должна быть доступна всё время работы серверной стороны, так как заранее неизвестно, когда очередной клиент решит запросить соединение.

Я уже закурил. Автор немного пошло расписывает трудовые будни серверного гнезда.

anonymous
()

> домен: в качестве аналога подойдёт что-то вроде вида разъёма (силовой, высокочастотный, оптический и т.д.);

попытки разжевать материал для новичка в духе Дали и Пикассо

И да, Стивенс попонятнее будет.

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

>Какой суровый копипастинг.

Автору нужно назначить лоботомию, т.к. здесь уже ничего другое не поможет.

Dimanc ★★
()

А я скопировал пример из boost::asio и счастлив как слон.

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

видать тема весьма интересная для лоровцев...

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

jtootf ★★★★★
()

>познакомимся с несколькими вариантами ожидания входящих данных Дальше не читал. В то время, как белые люди пользуются wcf-ами позволяющий вертеть любыми биндингами с любыми транспортными протоколами, да с любой безопасностью, быдло продолжает «эффективно» дрочить байтики.

anonymous
()
Ответ на: комментарий от Kompilainenn

видать тема весьма интересная для лоровцев...

Ну как бы и так. Было бы описание каких-нибудь «Рельсов» или Erlang-а, было бы интересней, а так тупой пример TCP-сервака на Сях, которых полным полно.

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

> тупой пример TCP-сервака на Сях, которых полным полно

Это верно, проблема в том, что «умных» примеров нет. Кода с неблокирующим I/O, корректного в условиях многопоточности и хартбитом на внеполосных данных.

А TCP-сервер средствами функционального программирование - это жесткое сексуальное извращение.

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

Я бы почитал, но суровый перевод меня испугал, читать в 10001 раз про сокеты не интересно (много буков), тема про еполл не раскрыта вообще, он даже там не упомянут... Ну и чего его читать то? Обычный сокетный хелловорлд.

Вот покажи мне Ъ-сервер с еполлом, нптл и балансировкой нагрузки обработчиков между ядрами CPU - это будет веселее и пользительнее.

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

Первое, что надо знать при разработке сервера - это libevent. Тем более, что она работает на Linux, BSD, Solaris, Windows. Под Linux она использует epoll, под остальными - тоже native эквиваленты.

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

Это не Ъ, надо юзать низкоуровневые элементы системы самому, без лишних прослоек, только так можно получить истинный дзен красноглазия и производительности. Если же нам надо «just works», то сойдет любой семпл, а в большинстве случаев даже обычный апач, ибо зачастую все в хттп+хмл завернуть можно (порождая огромные оверхеды, но главное just works).

Ну и зачем этот libevent, если он не нужен?

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

libevent нужен, чтобы создавать переносимый код. Делать что-то на epoll значит создавать Linux-only систему. Делать же приличный сервер на апаче .. :)

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

> Делать что-то на epoll значит создавать Linux-only систему.

А теперь перечитай название сайта, где ты пишешь. Кому-то еще нужны игровые платформы?

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

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

1) Писать программы Linux-only сейчас - просто глупо, если, конечно, это не спец проект под конкретную задачу.

2) Апач при написании сервера не поможет никаким боком. Или ты пишешь сайты на PHP (как ты, видимо, привык) - это не есть написание сервера. Кроме того, если ты пишешь сервер почты, сообщений, коммуникаций с железом и тд - apache тебе просто никак ни поможет. Ну и напоследок. Самые быстрые тесты apache (на статических страницах!) показывают примерно 2000 requests/sec. Это 500 mсs на запрос. Тот сервер, который я сейчас пишу на базе libevent тратит 18 mcs на запрос, разница понятна?

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

> Писать программы Linux-only сейчас - просто глупо, если, конечно, это не спец проект под конкретную задачу.

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

Или ты пишешь сайты на PHP (как ты, видимо, привык) - это не есть написание сервера

Я не пишу, а вот похапешники именно так и делают, причем весьма успешно зарабатывают деньги. Завернуть в http можно что угодно, хоть ip-пакеты, в таком виде и сдать заказчику. И на производительность обычно всем пофиг. Потом в крайнем случае прикручивают сквиды и прочее говно, дабы оно не разваливалось во время работы. Я этим не занимаюсь, но если надо будет «сдать успешный проект», который должен работать и в линуксе, и в венде - я знаю решение.

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