Вопрос о сервере снабжает сокетом [закрытую] модель программирования
Как я понимаю ваш вопрос, очень хороший пост в блоге, посвященный этому, можно найти в git-automatic-merges-with-server-side-hooks , включая скрипты.
6 ответов
Похоже, у вас есть пара вопросов. Я сделаю все возможное, чтобы ответить на то, что я вижу.
1. Как мне обрабатывать потоки на моем сетевом сервере?
Я бы внимательно посмотрел, какую работу вы выполняете над рабочими потоками, которые порождаются вашим сервером. Создание нового потока для каждого запроса - не лучшая идея ... но это может ничего не повредить, если количество параллельных запросов невелико, а задачи, выполняемые в каждом потоке, выполняются быстро.
Если вы действительно хотите сделать это все правильно, у вас может быть настраиваемый / динамический пул потоков, который будет перерабатывать рабочие потоки по мере их освобождения. Таким образом вы можете установить максимальный размер пула потоков. Тогда ваш сервер будет работать до размера пула ... а затем заставить дальнейшие запросы ждать, пока рабочий поток не станет доступен.
2. Как мне отформатировать данные в моих пакетах?
Если вы не разрабатываете совершенно новый протокол ... это не то, о чем вам действительно нужно беспокоиться. Если вы не имеете дело с потоковым мультимедиа (или другим приложением, в котором допустима потеря / повреждение пакетов), вы, вероятно, не будете использовать UDP для этого приложения. TCP / IP, вероятно, будет вашим лучшим выбором ... и это будет определять дизайн пакета за вас.
3. Какой формат использовать для сериализации?
Способ сериализации данных по сети зависит от того, какие приложения будут использовать вашу службу. Двоичная сериализация обычно выполняется быстрее и приводит к меньшему количеству данных, которые необходимо передавать по сети. Обратной стороной использования двоичной сериализации является то, что двоичная сериализация на одном языке может не работать на другом. Поэтому клиенты, подключающиеся к вашему серверу, скорее всего, должны быть написаны на том же языке, который вы используете.
XML-сериализация - еще один вариант. Это займет больше времени и приведет к передаче большего объема данных по сети. Преимущество использования чего-то вроде сериализации XML заключается в том, что вы не будете ограничены типами клиентов, которые могут подключаться к вашему серверу и использовать ваши услуги.
Вы должны выбрать то, что лучше всего соответствует вашим потребностям.
. .. поиграйте с различными вариантами и выясните, что лучше всего подходит для вас. Надеюсь, вы найдете что-то, что будет работать быстрее и надежнее, чем все, что я здесь упоминал.
должен быть написан на том же языке, который вы используете.XML-сериализация - еще один вариант. Это займет больше времени и приведет к передаче большего объема данных по сети. Преимущество использования чего-то вроде сериализации XML заключается в том, что вы не будете ограничены типами клиентов, которые могут подключаться к вашему серверу и использовать ваши услуги.
Вы должны выбрать то, что лучше всего соответствует вашим потребностям.
. .. поиграйте с различными вариантами и выясните, что лучше всего подходит для вас. Надеюсь, вы найдете что-то, что будет работать быстрее и надежнее, чем все, что я здесь упоминал.
должен быть написан на том же языке, который вы используете.XML-сериализация - еще один вариант. Это займет больше времени и приведет к передаче большего объема данных по сети. Преимущество использования чего-то вроде сериализации XML заключается в том, что вы не будете ограничены типами клиентов, которые могут подключаться к вашему серверу и использовать ваши услуги.
Вы должны выбрать то, что лучше всего соответствует вашим потребностям.
. .. поиграйте с различными вариантами и выясните, что лучше всего подходит для вас. Надеюсь, вы найдете что-то, что будет работать быстрее и надежнее, чем все, что я здесь упоминал.
Преимущество использования чего-то вроде сериализации XML заключается в том, что вы не будете ограничены типами клиентов, которые могут подключаться к вашему серверу и использовать ваши услуги.Вы должны выбрать то, что лучше всего соответствует вашим потребностям.
. .. поиграйте с различными вариантами и выясните, что лучше всего подходит для вас. Надеюсь, вы найдете что-то, что будет работать быстрее и надежнее, чем все, что я здесь упоминал.
Преимущество использования чего-то вроде сериализации XML заключается в том, что вы не будете ограничены типами клиентов, которые могут подключаться к вашему серверу и использовать ваши услуги.Вы должны выбрать то, что лучше всего соответствует вашим потребностям.
. .. поиграйте с различными вариантами и выясните, что лучше всего подходит для вас. Надеюсь, вы найдете что-то, что будет работать быстрее и надежнее, чем все, что я здесь упоминал.
Что касается дизайна сервера, я бы сказал, что вы правы: хотя ОДНА НИТЬ НА РОЗЕТКУ - простой и легкий подход, это не лучший способ, поскольку он выиграл не масштабируются, как и другие шаблоны проектирования серверов.
Мне лично нравится подход COMMUNICATION-THREADS / WORKER-THREADS, когда пул динамического числа рабочих потоков обрабатывает всю работу, генерируемую потоками-производителями.
В этой модели у вас будет несколько потоков в пуле, ожидающих задач, которые будут сгенерированы из другого набора потоков, обрабатывающих сетевой ввод-вывод.
Я обнаружил Сетевое программирование UNIX Ричарда Стивенса и отличный источник такого рода подходов к сетевому программированию. И, несмотря на название, он также будет очень полезен в среде Windows.
Хотя предыдущие ответы дают хорошее направление, просто для полноты, я хотел бы указать, что потоки не являются абсолютным требованием для высокой производительности сервера сокетов. Некоторые примеры здесь . Также существует множество подходов к масштабируемости - пулы потоков, предварительно разветвленные процессы, пулы серверов и т. Д.
вам все равно понадобится сокет для обработки каждого клиента, но идея состоит в том, чтобы создать пул из X сокетов (скажем, 50), а затем, когда вы приблизитесь (скажем, 90 %) для использования всех этих сокетов, создайте еще один пул сокетов X. В какой-то момент после того, как клиенты подключились, отправили данные и отключились, некоторые из ваших сокетов будут доступны для использования, и вы сможете их использовать (пулы сокетов Google для этой информации)
Расположение данных всегда сложно. Если все ваши клиенты и серверы будут использовать одно и то же оборудование и операционную систему, вы можете отправлять данные в двоичном формате, но там много отключений и ловушек (выравнивание байтов находится в верхней части списка). отправлять форматированный текст всегда проще,
А как насчет использования объекта FileInfo для извлечения имени каталога?
В Vb.Net:
fi = New FileInfo(System.Reflection.Assembly.GetExecutingAssembly.Location)
path = fi.DirectoryName
1) И последнее , есть ли какая-либо простая в использовании библиотека, которая обычно используется, которая поддерживает переносимость (например, разработка на компьютере с Windows и развертывание на компьютере с Linux), кроме boost asio.
Другой альтернативой является библиотека ACE . Он очень зрелый (существует с начала 90-х) и широко используется. Краткое обсуждение того, как это выглядит в сравнении с Boost ASIO , доступно на сайте Riverace здесь . Имейте в виду, что ACE долгое время поддерживал большое количество устаревших платформ, поэтому он не использует современные функции C ++ в такой степени, как, например, Boost ASIO.
2) Пусть ' Скажем, я хотел бы создать сервер на C ++, который бы обрабатывал ввод от тысяч автономных и / или веб-приложений, как мне тогда спроектировать свой сервер? До сих пор я обычно создаю новый и уникальный поток для каждого пользователя, который подключается, но я сомневаюсь, что это правильный путь.
Существует ряд часто используемых подходов, включая, но не ограничиваясь: thread-per -соединение (подход, который вы описываете) и пул потоков (подход, описанный Джастином). У каждого есть свои плюсы и минусы. Многие смотрели на компромиссы. Хорошей отправной точкой могут быть ссылки на странице Википедии Thread Pool Pattern .
Веб-страница Дэна Кегеля « The C10K Problem » также содержит много полезных замечаний об улучшении масштабируемости. .
3) Также, Как определить расположение пакетов, отправляемых по сети; данные обычно отправляются по сети в двоичном или текстовом состоянии? Как вы обрабатываете сериализованные объекты при отправке данных на разные носители (например, сервер C ++ во флэш-приложение)?
Я согласен с другими в том, что отправка двоичных данных, как правило, будет наиболее эффективной. Библиотека ускоренной сериализации может использоваться для маршалинга данных в двоичную форму (а также текст). Зрелые двоичные форматы включают XDR и CDR . CDR - это формат, используемый, например, CORBA . Компания ZeroC определяет кодировку ICE , которая должна быть намного более эффективной, чем CDR.
Существует множество двоичных форматов на выбор. Я предлагаю не изобретать колесо, по крайней мере, читая о некоторых из этих двоичных форматов, чтобы вы не столкнулись с теми же подводными камнями, для решения которых были разработаны существующие двоичные форматы.
Тем не менее, многие существует промежуточное ПО , которое уже предоставляет готовое решение для большинства ваших нужд. Например, OpenSplice и OpenDDS являются реализациями стандарта OMG Data Distribution Service . DDS фокусируется на эффективном распределении данных, например, с помощью модели публикации-подписки , а не на удаленном вызове функций. Я больше знаком с технологиями, определенными OMG, но уверен, что есть и другие реализации промежуточного программного обеспечения, которые соответствуют вашим потребностям.
В конечном итоге они сталкиваются с теми же ловушками, для устранения которых были разработаны эти существующие двоичные форматы.Тем не менее, существует множество промежуточного программного обеспечения , которое уже предоставляет готовое решение для большинства ваших потребностей. Например, OpenSplice и OpenDDS являются реализациями стандарта OMG Data Distribution Service . DDS фокусируется на эффективном распределении данных, например, с помощью модели публикации-подписки , а не на удаленном вызове функций. Я больше знаком с технологиями, определенными OMG, но уверен, что есть и другие реализации промежуточного программного обеспечения, которые соответствуют вашим потребностям.
В конечном итоге они сталкиваются с теми же ловушками, для устранения которых были разработаны эти существующие двоичные форматы.Тем не менее, существует множество промежуточного программного обеспечения , которое уже предоставляет готовое решение для большинства ваших потребностей. Например, OpenSplice и OpenDDS являются реализациями стандарта OMG Data Distribution Service . DDS фокусируется на эффективном распределении данных, например, с помощью модели публикации-подписки , а не на удаленном вызове функций. Я больше знаком с технологиями, определенными OMG, но уверен, что есть и другие реализации промежуточного программного обеспечения, которые соответствуют вашим потребностям.
существует множество промежуточного программного обеспечения , которое уже предоставляет готовое решение для большинства ваших нужд. Например, OpenSplice и OpenDDS являются реализациями стандарта OMG Data Distribution Service . DDS фокусируется на эффективном распределении данных, например, с помощью модели публикации-подписки , а не на удаленном вызове функций. Я больше знаком с технологиями, определенными OMG, но уверен, что есть и другие реализации промежуточного программного обеспечения, которые соответствуют вашим потребностям. существует множество промежуточного программного обеспечения , которое уже предоставляет готовое решение для большинства ваших нужд. Например, OpenSplice и OpenDDS являются реализациями стандарта OMG Data Distribution Service . DDS фокусируется на эффективном распределении данных, например, с помощью модели публикации-подписки , а не на удаленном вызове функций. Я больше знаком с технологиями, определенными OMG, но уверен, что есть и другие реализации промежуточного программного обеспечения, которые соответствуют вашим потребностям. а не удаленный вызов функций. Я больше знаком с технологиями, определенными OMG, но уверен, что есть и другие реализации промежуточного программного обеспечения, которые соответствуют вашим потребностям. а не удаленный вызов функций. Я больше знаком с технологиями, определенными OMG, но уверен, что есть и другие реализации промежуточного программного обеспечения, которые соответствуют вашим потребностям.О серверных сокетах и сериализации (маршалинге). Самая главная проблема - рост числа сокетов - это состояние readable и writable в select. Я не говорю об ограничении в FD_SET. Это решается просто. Я говорю о росте времени сигнализации и накоплении проблемных данных в нечитаемых сокетах при обработке данных, имеющихся в оцениваемом сокете. Поэтому решение может быть даже вне границ SW и требовать многопроцессорной модели, когда роли процессоров ограничены: один читает и пишет, N обрабатывают. В этом случае все доступные данные сокета должны были быть прочитаны при возврате select и отправлены на другой процессор.
То же самое касается входящих данных.
О маршалинге. Конечно, бинарный формат предпочтительнее из-за производительности. Кстати, XML в терминах UNICODE имеет ту же проблему. Но,... товарищи, это не просто копирование длинного или целого значения в поток сокета. Но в этом случае даже htons, htonl могли бы помочь (они отправляют/принимают в формате NW и ОС отвечает за преобразование данных). Но безопаснее посылать данные, следуя заголовку представления, где раскрыт формат размещения старших/малых значащих бит, порядок байтов и тип данных IEEE. Это работает, у меня не было случая, когда это было бы не так.
Добрые пожелания и больших успехов всем. Simon Cantor