server framework

серверная структура

Кросс-платформенная базовая библиотека https://github.com/hujianzhe/util, загрузите и поместите ее в каталог BootServer.

Введение:
Код реализует только загрузку запуска узла службы, планирование задач и описание базового модуля. Он реализован на чистом C. Обычно он компилируется в динамическую библиотеку и остается чрезвычайно ограниченным с точки зрения функций использования. Он реализует некоторые общие потоки протоколов и поддерживает C++ 20. Расширение бесстековой сопрограммы и изолирован от некоторых кодов чистой динамической библиотеки C, чтобы предотвратить загрязнение C++ уровня инфраструктуры и влияние на создание динамической библиотеки.
Код в util отвечает за кроссплатформенность, при этом не требует установки каких-либо сторонних библиотек.

Введение в рабочий процесс:
Бизнес-процесс вызывает динамическую библиотеку, скомпилированную кодом, и вызывает для использования соответствующий интерфейс. Подробности о вызывающем процессе см. в примере тестового узла (main_template в каталоге BootServer — это набор шаблонов кода запуска на основе процесса).
Несколько потоков обрабатывают чтение и запись сетевых операций ввода-вывода внутри модуля. Отдельный поток доступа к разрешению сначала открывает рабочий поток для обработки внутренних сообщений и полученных сетевых сообщений и отправки их в логику вашего бизнес-кода.
Рабочий поток использует сопрограмму стека для планирования обработки (причину, по которой не используется сопрограмма без стека, см. ниже).
Рабочие потоки по умолчанию используют сопрограммы стека для планирования, чтобы обеспечить максимальную совместимость. Вы также можете легко использовать сопрограммы без стека C++ 20 (одна из которых реализована в библиотеке util) для планирования. Существуют сопрограммы стека и процессы без стека.

Введение в модуль и пример кода:
1. BootServer: основная часть кода, необходимая инициализация и работа сервисных узлов.
2. ServiceTemplate: шаблон кода узла службы, используемый для написания вашей бизнес-логики.
3. SoTestClient, SoTestServer: протестируйте узлы и напишите несколько примеров кода.
4. Cpp20-SoTestServer: тестовый узел, написал пример кода, включил бесстековую сопрограмму C++20 в main.cpp (с использованием планировщика бесстековых сопрограмм C++20 в библиотеке util).

Скомпилировать:
Windows Direct VS компиляция
Используйте make debug/make Release/make asan под Linux/Mac OS X.

запускать:
Отредактируйте файл конфигурации, необходимый для запуска сервисного узла (см. прилагаемый шаблон файла конфигурации для конкретного формата), и дайте каждому узлу файл конфигурации и уникальный идентификатор, идентификационное имя журнала, IP-адрес и номер порта.
Windows открывается непосредственно в VS, и проект настраивается с параметрами запуска <файл конфигурации>
После компиляции Linux/mac, sh run.sh <сервисный процесс> <файл конфигурации>

Некоторые причины и идеи дизайна:
Вопрос: Почему бы не использовать сопрограммы без стека, а использовать составные сопрограммы?
О: Легко реализовать бесстековые сопрограммы на чистом C (подробный код вы можете увидеть в библиотеке утилит, в которой реализован планировщик бесстековых сопрограмм, реализованный на чистом C), но переработка и сохранение ресурсов (особенно переменные в стеке подлежат повторному использованию сопрограммами). -вход). (последняя ситуация) крайне затруднена.
Если вы хотите плавно использовать бесстековые сопрограммы, вам все равно придется полагаться на поддержку компилятора. Это было достигнуто в C++20. В библиотеке util также есть полная реализация планировщика бесстековых сопрограмм.

Вопрос: Почему бесстековая сопрограмма предоставляет эту расширенную функцию в виде заголовочного файла?
О: 1. Потому что бесстековые сопрограммы навязывают код и изменяют большое количество форм сигнатур функций.
2. Содержит объекты C++, которые не распознаются в C, и динамическую библиотеку невозможно успешно экспортировать.
3. Передача разрешения на активацию бесстековых сопрограмм на уровень приложения в виде заголовочного файла — это способ, которым я сейчас думаю, чтобы справиться с частью динамической библиотеки на чистом C без какого-либо загрязнения.

Вопрос: Можно ли заменить его на другие планировщики?
О: Планировщик рабочего потока может быть заменен. Рабочий поток спроектирован как работающий носитель планировщика. Взаимодействие между сетевым потоком и рабочим потоком внутри структуры может соответствовать поведению планирования через перехватчик интерфейса.

Вопрос: Можно ли заменить ее другими сетевыми библиотеками?
О: 1. В настоящее время ее нельзя заменить другими сетевыми библиотеками, но этот вопрос был рассмотрен в начале разработки. Сетевая часть и часть планирования задач полностью разделены. В будущем соответствующее поведение будет аналогично рабочему потоку. крючки будут предоставлены для замены.
2. Хотя существует множество сторонних сетевых библиотек, их направленность различна. Существуют библиотеки TCP и UDP, используемые для разработки приложений, есть также библиотеки, которые хотят охватить всю вселенную, а также есть библиотеки, которые реализуют весь стек сетевых протоколов на уровне приложения, поэтому фактически эта область не унифицирована.
3. Если в будущем набор сетевых библиотек войдет в стандарт, то я его заменю.

Вопрос: Почему бы просто не использовать C++ в качестве основы?
О: 1. Когда был написан этот набор кода, C++20 еще не появился. В то время относительно наиболее зрелым решением сопрограммы была сопрограмма стека. Это можно было сделать с помощью C, вызывая соответствующий системный API платформы.
2. Функции, которые должны быть реализованы с помощью этого типа структуры, закреплены, а жизненный цикл ресурсов закреплен процессом. Достаточно реализовать его на чистом C (ранее была версия, реализованная на C ++, и. код был сложнее)
3. Если динамическая библиотека вызывается другими модулями, ей всё равно нужно запечатать интерфейс на C
4. Классы, экспортированные в C++, заразительны, а ABI не унифицирован.

Вопрос: Можно ли продолжать разработку бизнес-уровня на чистом C?
О: Крайне не рекомендуется, поскольку написание асинхронных процессов и исключений, генерируемых в модулях, написанных на языках высокого уровня, делает неопределенными сроки уничтожения ресурсов. В настоящее время управлять ресурсами вручную с помощью чистого C крайне сложно. Для решения этих задач следует использовать язык более высокого уровня. Например, вы можете использовать C++ для разработки бизнес-кода верхнего уровня, а его механизм RAII может гарантировать высвобождение соответствующих ресурсов.

Вопрос: Если я хочу преобразовать «обратный вызов» старого проекта в «сопрограмму», могу ли я просто заменить часть планировщика соответствующей точкой вызова в бизнес-коде?
О: Это не так просто. Во-первых, это вопрос рабочей нагрузки. Кроме того, независимо от того, в форме обратного вызова или в форме сопрограммы, суть состоит в том, чтобы выдать запрос и дождаться результата в течение этого периода жизненного цикла переменной. Это проблема, которую необходимо решить и которую необходимо тщательно рассмотреть. Если это необработанный указатель, то можно почти сказать, что его невозможно преобразовать, если проект использовал его. Такие средства, как std::shared_ptr, удлиняют жизненный цикл переменных, поэтому преобразование в версию «стековой сопрограммы» будет проще. Если вы хотите преобразовать в бесстековую сопрограмму C++20, это огромно. равносильно переписыванию проекта (поскольку бесстековые сопрограммы сильно вторгаются в код), поэтому не рекомендуется преобразовывать старые проекты.

Вопрос: Почему в настоящее время сопрограмму нельзя переносить в другие потоки для выполнения?
О: Миграцию сопрограмм можно легко выполнить, но причина, по которой она не предусмотрена, заключается в следующем.
1. Задачи, выполняемые между сопрограммами, неопределенны, что может привести к смешиванию операций ввода-вывода и вычислений в одном потоке планирования.
2. После миграции один и тот же процесс сопрограммы может выполняться в разных потоках. В этом случае вы должны убедиться, что ваш код не зависит от каких-либо локальных переменных потока, но вы не можете гарантировать, что сторонняя библиотека не использует локальные переменные потока. .

Вопрос: Будет ли asan аварийно завершать работу при компиляции и запуске?
О: 1. Если вы используете составную сопрограмму платформы по умолчанию, это определенно не проблема кода. Вы можете настроить размер стека составной сопрограммы в файле конфигурации узла (когда ASAN включен, будет потребляться относительно большое пространство стека). так что есть вероятность взрыва стека)
2. ASAN не полностью поддерживает API стековой сопрограммы (ucontext) в среде Unix. Хотя API сопрограммы ucontext был адаптирован к ASAN в коде утилиты, он все еще не может на 100% гарантировать отсутствие проблем при работе в ASAN. окружающая среда (пока все хорошо).
3. Если в некоторых новых дистрибутивах Linux ASAN выводит AddressSanitizer: DEADLYSIGNAL бесконечно, настройте sudo sysctl vm.mmap_rnd_bits=28, чтобы решить проблему.

ЗАДАЧА:
1. У меня действительно нет времени писать подробную документацию.
2. Обеспечить поддержку написания бизнес-логики на языке сценариев.