Слияние кода завершено, страница обновится автоматически
NFShmServer — это облегчённый, гибкий и распределённый плагин для разработки на C++, который можно использовать в трёх основных режимах:
С помощью общей памяти и сценариев Lua были реализованы две игры: аркадная игра про ловлю рыбы в Unity 3D. Заинтересованные могут присоединиться к группе 762414765 для обучения.
Информация о лицензии
Статистика проекта
.
.
.
.Ссылки
.
.
.| CI | master | develop |
|---|---|---|
| Github Actions |  |
 |
PVS-Studio — статический анализатор для кода C, C++, C# и Java.
Если ваш проект использует NFShmServer, вы можете связаться с автором, который будет рад представить вашу работу. Например, среднеазиатский дракон (связался с пользователями, но похоже, что проект позже был закрыт).
Недавно на собеседовании интервьюер спросил, зачем писать сервер с открытым исходным кодом. Я ответил, что пишу из интереса и хочу создать самый крутой сервер.
Чем отличается мой сервер от других? Если то, что я пишу, может быть сразу же написано другими людьми, или если оно не сильно отличается от того, что уже существует, то это просто тренировка навыков, которая не имеет большой ценности.
В процессе разработки игровых серверов я столкнулся с рядом проблем, которые привели к созданию NFShmFrame. За последние 10 лет разработки игр я часто сталкивался с различными проблемами серверов. Чтобы решить эти проблемы, я обычно сначала реализовывал решения на NFShmFrame, и постепенно за 6 лет накопилось достаточно опыта, чтобы сформировать этот открытый сервер.
Вот некоторые из проблем, с которыми я столкнулся:
Проблема №1: сбой сервера на C++. Независимо от причины сбоя, будь то ошибка указателя, функции memcpy или memset, переполнение стека или массива, сервер на C++ в конечном итоге выйдет из строя, а данные будут потеряны.
Проблема №2: сложность реализации функций горячего обновления, подобных LUA, на C++.
Проблема №3: большинство распределённых игровых серверов состоят из множества различных функциональных процессов, связанных через TCP или общую память, что затрудняет их настройку.
Проблема №4: многопроцессные распределённые серверы требуют одновременного запуска нескольких процессов. Даже при использовании VS для отладки в Windows необходимо запускать множество окон, что становится громоздким при большом количестве. В Linux использование gdb для отладки нескольких серверов может стать настоящим кошмаром.
Проблема №5: при реализации системы баз данных игрового сервера с большим количеством рукописных SQL-запросов написание становится утомительным, просмотр — утомительным, обслуживание — утомительным, и легко допустить ошибки, особенно при написании сложных запросов. С помощью storeserver, использующего protobuf для отражения, можно автоматически создавать базы данных, таблицы и добавлять столбцы без необходимости написания каких-либо SQL-запросов вручную.
Проблема №6: написание многопоточных приложений на C++ может быть сложным, независимо от того, требуется ли реализовать многопоточность для TCP-сетей или баз данных.
Проблема №7: некоторые игровые серверы, например, от компаний, связанных с Tencent, используют общую память и TCP для связи между серверами и для связи серверов с клиентами. Интерфейс между общей памятью и TCP сложно унифицировать, и замена одного на другой может вызвать проблемы.
Проблема №8: в большинстве игровых компаний код сервера имеет высокую степень сцепления между модулями, что затрудняет разделение и обновление.
Проблема №9: некоторые компании, в основном связанные с Tencent, решают проблемы сбоя сервера C++ и потери данных после сбоя, а также проблему горячего обновления C++, используя общую память. Однако создание классов с использованием общей памяти обходится дорого из-за отсутствия поддержки контейнеров STL. Можно сделать распределённую архитектуру без необходимости модификации исходного кода, реализовать однопроцессное выполнение всего набора распределённой системы (для серверов прокачки, можно одновременно запускать несколько серверов, что удобно для отладки между серверами), ускорить разработку сервера в штатном режиме.
При этом также можно добиться максимального возможного сокращения использования памяти при разработке и отладке. Для работы в распределённом режиме требуется только изменить параметры запуска программы.
C++ горячее обновление: сервер реализовал совместное использование памяти C++ горячего обновления (для чистого C++, это единственный эффективный способ горячего обновления, конечно, предпосылкой горячего обновления является отсутствие изменения структуры класса совместного использования памяти).
Сервер не теряет данные при сбое: для популярных прибыльных игр это всё ещё очень важно. После сбоя сервера он перезапускается без потери каких-либо физических данных, и даже данные внутренней сети протокола не будут потеряны.
Все игровые данные находятся в общей памяти: архитектура общей памяти прошла множество проверок в крупных проектах MMO, а при использовании общей памяти для связи внутренней сети, данные протокола игрока не будут утеряны при сбое сервера.
(2022.9–2023.9 завершено) Реализована структура данных SGI-STL, которая может быть безопасно использована в общей памяти, что значительно упрощает написание кода с использованием общей памяти (существует несколько проектов с открытым исходным кодом от Tencent, которые используют только простую хеш-таблицу, а остальная бизнес-логика требует использования массивов на языке C). За исключением предварительного определения необходимого объёма памяти, остальные методы использования такие же, как и у STL. NFShmVector — std::vector использует: NFShmVector<int, 5> — std::vector. Помимо определения 5 как максимального объёма памяти, другие методы использования NFShmVector и std::vector полностью совпадают, включая использование их итераторов и алгоритмов STL.
(2022.9–2023.9 завершено) Конфигурация игрового сервера, от Excel до кода общей памяти и SQL-операторов, требует только определения прототипа структуры, чтобы сгенерировать большое количество полезного кода. Вы можете использовать эту структуру прототипа для чтения данных Excel, создания соответствующей структуры класса общей памяти для хранения данных или генерации SQL-данных и импорта таблицы Excel в базу данных без изменения исходного кода.
(2022.9–2023.9 завершено) Личные данные игрока требуют только определения структуры прототипа, автоматически генерируют данные общей памяти, SQL-данные и завершают доступ к данным MySQL через излучение прототипа. Вам не нужно писать SQL-запросы самостоятельно.
Подобно внутренним серверам Tencent, каждый серверный процесс имеет независимый идентификатор, похожий на сетевой IP, который представляет этот сервер. Вам не нужно знать, где развёрнут любой серверный процесс, вам нужно только знать уникальный идентификатор этого сервера, чтобы взаимодействовать друг с другом.
(2022.9–2023.9 завершено) Многопроцессная однопоточная Lua горячая замена, реализована поддержка плагинов Lua. Вы можете писать бизнес-код с помощью Lua и обновлять серверы.
(Не завершено) Многопроцессорная система Actor, многопоточная горячая замена Lua, в настоящее время находится в стадии разработки. Она немного похожа на Skynet, но нижний уровень по-прежнему NF, основная архитектура — C++, а основная логика — Lua.
(2022.9–2023.9 завершено) Дружественная система RPC, реализована система RPC для игровых серверов, простая в использовании и хорошо адаптированная к протоколу игровых серверов.
Высокопроизводительная коммуникационная подсистема, поддерживает многопоточную сеть TCP, UDP, HTTP на разных физических машинах, а также однопоточный обмен данными по шине на одной физической машине. В то же время унифицированы интерфейсы конфигурации для сети и шины, и требуется лишь небольшая модификация конфигурации, чтобы легко переключаться.
Высокая доступность системы. Архитектура разделена на архитектурный слой, слой сервера и конкретный игровой бизнес-слой. Конкретные слои имеют конкретные каталоги, верхний слой не зависит от нижнего слоя, структура ясна. Архитектурный слой и слой сервера являются общими, разные игры имеют разные каталоги.
(2020.1–2023.9 завершено) Система базы данных многократного использования, система баз данных использует механизм отражения Protobuf для реализации. Не нужно вручную писать SQL-запросы, не нужно определять таблицы MySQL. Требуется только структура прототипа, и система базы данных автоматически создаст базу данных и таблицы, добавит столбцы. Запросы, вставки, сохранения и удаления базы данных также требуют вызова структуры прототипа системы для завершения.
(2022.9–2023.9 завершено) Redis кэш реализован с использованием механизма отражения Protobuf, без необходимости написания какого-либо кода вручную. Требуется только настроить простой механизм кэширования системы storeserver.
(2022.9–2023.9 завершено) Унифицированный механизм загрузки конфигурации, независимо от того, загружаете ли вы конфигурацию из Excel или таблицы базы данных, нет необходимости изменять большой объём кода, требуется только один флаг.
(2022.9–2023.9 завершено) Механизм уведомлений по электронной почте и WeChat Enterprise, когда сервер запускается или происходит сбой сервера, серверная структура отправит информацию о запуске и дамп информации о сбое на электронную почту или в WeChat.
Дружественный журнал управления, вы можете контролировать отдельный модуль журнала или даже журнал отдельного игрока.
Комплексный U3D клиент для рыбалки — проект FishClient.
Платформа кроссплатформенная (Windows, Linux). Unity3D: игра «Рыбалка»
Tutorial 1: Compile NFShmServer — компиляция демо-сервера рыбалки.
Tutorial 2: Import Mysql — импорт базы данных демо-игры «Рыбалка».
Tutorial 3: Start NFShmServer — запуск демо-сервера рыбалки.
Концептуальные главы:
— Все серверы должны быть связаны с главным сервером, который можно использовать как именованный сервер, изменив конфигурацию. — Каждый сервер имеет уникальный идентификатор, подобный IP-адресу, например, главный сервер имеет идентификатор 1.1.1.1, а сервер worldserver — 15.100.3.1. Серверы могут взаимодействовать друг с другом без знания о том, на каком физическом сервере находится другой сервер, им достаточно знать уникальный идентификатор другого сервера. — На каждом отдельном физическом сервере есть NFRouteAgentServer, маршрутизирующий агент-сервер, который используется для внутренних коммуникаций на этом физическом сервере и для связи с другими физическими серверами. Также есть NFProxyAgentServer, агент-прокси-сервер, используемый для подключения к шлюзу и обеспечения связи с внешними клиентами. — Физический сервер. — Логические серверы, такие как LoginServer, LogicServer, GameServer, WorldServer, SnsServer, StoreServer, не связаны друг с другом. Они все подключены к одному и тому же NFRouteAgentServer на одном физическом сервере, и регистрируют свои уникальные идентификаторы на этом NFRouteAgentServer для обеспечения взаимодействия между собой. Например, LoginServer отправляет сообщение WorldServer, но они не связаны напрямую, LoginServer должен отправить сообщение сначала на NFRouteAgentServer, который затем перенаправит его на WorldServer. — NFRouteAgentServer маршрутизирующий агент-серверы используют NFRouteServer сервер для обеспечения связи между логическими серверами, расположенными на разных физических серверах. NFRouteAgentServer серверы отправляют информацию о своих логических серверах на NFRouteServer сервер, чтобы обеспечить распределённую связь между физическими серверами. Для связи между логическими серверами на разных физических серверах, например, когда LoginServer отправляет сообщение на WorldServer, расположенный на другом физическом сервере, LoginServer сначала отправляет сообщение на свой NFRouteAgentServer, который перенаправляет его на NFRouteServer, который, в свою очередь, перенаправляет сообщение на NFRouteAgentServer сервера, расположенного на том же физическом сервере, что и WorldServer. Затем NFRouteAgentServer перенаправляет это сообщение на WorldServer. — Клиенты подключаются только к NFProxyServer и отправляют сообщения логическим серверам. NFProxyServer пересылает эти сообщения на логические серверы через NFProxyAgentServer прокси-агент-серверы, которые расположены на тех же физических серверах, где находятся логические серверы. Аналогично, логические серверы отправляют сообщения клиентам через NFProxyServer, который пересылает их на NFProxyAgentServer, расположенные на тех же физических серверах, что и клиенты. Затем NFProxyAgentServer пересылают сообщения клиентам.
PSS — Автор: freeeyes. — Описание: Платформонезависимый сетевой серверный фреймворк на основе плагинов.
ARK — Автор: NickYang1988. — Описание: Платформонезависимый сетевой серверный фреймворк на основе плагинов.
NoahGameFrame — Автор: ketoo. — Описание: Платформонезависимый сетевой серверный фреймворк на основе плагинов.
Вы можете оставить комментарий после Вход в систему
Неприемлемый контент может быть отображен здесь и не будет показан на странице. Вы можете проверить и изменить его с помощью соответствующей функции редактирования.
Если вы подтверждаете, что содержание не содержит непристойной лексики/перенаправления на рекламу/насилия/вульгарной порнографии/нарушений/пиратства/ложного/незначительного или незаконного контента, связанного с национальными законами и предписаниями, вы можете нажать «Отправить» для подачи апелляции, и мы обработаем ее как можно скорее.
Комментарии ( 0 )