Lineage2TS - HF сервер написанный на Typescript

Давайте определим о чем мы ведем беседу. Я не против того что нужно будет поддерживать другие БД. Сейчас поддерживается SQLite как главная база данных. Поддержка SQLite без особых библиотек вот-вот уже почти готовa в Nodejs.

Если вы про то что вы хотите сопоставить соединение БД и RPC на игровом сервере, это нужно детально смотреть сколько и какие запросы будут. Это совершеннo другая проблема чем просто имитировать соединение к БД. На Яве это использовалось лишь потому чтo никто, нигдe не захотел по другому сделать. Вот и все. Это застой. Но людям как вы и напомнили это все комфортно.


Вы просто хотите каким-то образом быть правы или у вас ест другие факты которые могут подтвердить такое будущее?
Дружище элементарный пример
Платежная система отправила на сайт сервера вебхук/коллбэк

Сайт принял коллбэк теперь Нада отправить итемы персу, в итоге что?)) нихера нет подключения к SQLite

Либо элементарно вывести top pvp на сайте или регистрацию сделать 😂😂😂
 
  • Facepalm
Реакции: kick

SQLite отличная, удобная, крайне быстрая база данных, проверенная временем.
И к ней вполне можно организовать доступ извне через простейшую прослойку в самом сервере.
 
SQLite отличная, удобная, крайне быстрая база данных, проверенная временем.
И к ней вполне можно организовать доступ извне через простейшую прослойку в самом сервере.
Какую интересно ?))))
 
Дружище элементарный пример
Платежная система отправила на сайт сервера вебхук/коллбэк

Сайт принял коллбэк теперь Нада отправить итемы персу, в итоге что?)) нихера нет подключения к SQLite

Либо элементарно вывести top pvp на сайте или регистрацию сделать 😂😂😂
Прекрасно. Замените подключение БД на RPC (что и в принципе так и работает по бинарному протоколу) с использованием JSON-а. Какое различие будет?
А будет все в том что иговой сервер сам будет обрабатывать запрос. Если все в БД, то игровой сервер нужно построить так что-бы все эти данные нужно будет прочитать, добавить все предметы или модификации персонажа в другие части сервера. Конечно, если ваш персонаж каким-то образон не находиться еще в игре, то возможно при загрузке сервер как раз и сделает то что вы описали. Нo проблема не в доставке информации либо в БД или же персонажа, сам игровой сервер должен в любом случае обрабатывать такой запрос. Так почему же нам нужно куда-то все сохранять, переодически заставлять сервер ждать новых данных о платежах или там предметаx? Дал запрос серверу напрямую ну и всe.

Дружище элементарный пример
Платежная система отправила на сайт сервера вебхук/коллбэк

Сайт принял коллбэк теперь Нада отправить итемы персу, в итоге что?)) нихера нет подключения к SQLite
Вы частично правы о том как все работает. Я говорю не o том что-бы изменить ваше мнение. Скорее я могу найти ситуацию когда нужно сделать то что вы хотите: отделенную БД от серверов.

Если есть много серверов и не понятно где и какие акаунты у нас содержат персонажей с определенным именем. Тогда да, намного проще дать внешний доступ к БД и сказать что сервис (оплаты а не сам игровой сервер) может каким-то образом понять где и как нужно править данные. Это решение, но одно из множества возможных. По другому можно сделать так что если мы знаем как подсоединиться к всем игровым серверам, можно просто запросить где и как персонаж для акаунта находиться ну и потом просто послать запрос в формате MessagePack текстовый JSON (это реализация RPC на Lineage2TS сервере сейчас).

Я кстати использую RPC соединение для пересылки административных команд на сервер для определенных персонажей (много уровней настройки как и блокировки по уровню админа, так что это не просто открытый доступ по типу L2J telnet) при тестировании. Тo есть когда тестируется функциональность обычных игроков, при этом будут тестироваться административные комманды. Это при том что есть различные виды запросов RPC, так что написание новых видов достаточно просто интегрировать в уже готовые системы. Но самое главное что это все работает, и очень быстро. Я тестировал например 96 паралельных соединений от клиентов, все работает. Все тесты проходят. Но самое главное что я не видел что-бы сервер нагружался более 1-2%. Так что нужно просто определить что решается и как можно это все реализовать.
 
Вы частично правы о том как все работает. Я говорю не o том что-бы изменить ваше мнение. Скорее я могу найти ситуацию когда нужно сделать то что вы хотите: отделенную БД от серверов.

Если есть много серверов и не понятно где и какие акаунты у нас содержат персонажей с определенным именем. Тогда да, намного проще дать внешний доступ к БД и сказать что сервис (оплаты а не сам игровой сервер) может каким-то образом понять где и как нужно править данные. Это решение, но одно из множества возможных. По другому можно сделать так что если мы знаем как подсоединиться к всем игровым серверам, можно просто запросить где и как персонаж для акаунта находиться ну и потом просто послать запрос в формате MessagePack текстовый JSON (это реализация RPC на Lineage2TS сервере сейчас).

Я кстати использую RPC соединение для пересылки административных команд на сервер для определенных персонажей (много уровней настройки как и блокировки по уровню админа, так что это не просто открытый доступ по типу L2J telnet) при тестировании. Тo есть когда тестируется функциональность обычных игроков, при этом будут тестироваться административные комманды. Это при том что есть различные виды запросов RPC, так что написание новых видов достаточно просто интегрировать в уже готовые системы. Но самое главное что это все работает, и очень быстро. Я тестировал например 96 паралельных соединений от клиентов, все работает. Все тесты проходят. Но самое главное что я не видел что-бы сервер нагружался более 1-2%. Так что нужно просто определить что решается и как можно это все реализовать.
как будешь бороться с параллельными запросами? Либо с высокой нагрузкой?
Как будешь связывать 2 и более сервера?

Меня смущает только выбор СУБД кто тебе посоветовал масштабный л2 проект пилить на локальном SQLite ?
В целом желаю удачи и развития проекту

Можешь мне отписать в телеграм обсудим эту тему и глобально стадию разработки
 
как будешь бороться с параллельными запросами? Либо с высокой нагрузкой?
Как будешь связывать 2 и более сервера?
Отвечу по порядку на вопросы.

1. Все запросы будут обработанны по порядку их прихода на сервер. Я не пойму почему есть даже идея паралельных запросов? Сервер ведь это один процесс, поэтому нет возможности в deadlock-е . Могли бы вы описать проблему конкретнее? В чем суть проблемы?

2. Нагрузка будет. Всегда. Это же будет проблемой и сервера соединенного с удаленной БД. Отличие лишь в том что данныe где-то как-то записались. Но это ведь можно и обратно сказать. Как насчет нагрузки на БД? Вдруг там много-чего делаеться и наш игровой сервер потихоньку тормозит из-за соединения? Я о том что это не является проблемой, и не симптом проблемы. Это просто побочный эффект с которым нужно как-то обходиться. Так вот, поконкретнее что мы решаем?

3. Логин сервер поддерживает множество серверов. В чем проблема? Если знаешь как подсоединиться к каждому из ниx, то проблема будет в коммуникации, а не в количестве. Пусть даже у вас десять серверов. Вот десять соединений. Как я и описал все что можно делать с БД соединениями, можно также настроить на игровых серверах.

Можно также построить отдельный сервис, который делает все что нужно. То есть он кеширует все запросы, соединяется с серверами и занимается чисто интеграцией вашей системы. Так вот, прямые соединения с БД на Ява уже так и делают, только являются частью системы соединения. Разницы почти нет.
 
Дружище элементарный пример
Платежная система отправила на сайт сервера вебхук/коллбэк

Сайт принял коллбэк теперь Нада отправить итемы персу, в итоге что?)) нихера нет подключения к SQLite

Либо элементарно вывести top pvp на сайте или регистрацию сделать 😂😂😂
На самом деле всё проще, не нужно чтоб что-то посторонне лезло в бд игровую .
Сервер пусть сам чекает апи сайта и проверяет есть ли предметы для выдачи.


Кстати автор, я так сложилось исторически, что каждое обновление языковых моделей, я проверяю насколько они хороши на твоём проекте 😂😂😂 уже как стандарт стало для меня
 
Спасибо за ваши труды.
Не затруднит ли вас выкатить мануал по запуску с использованием portainer, а также настройкой сервера для подключения с другого пк в локальной сети?
 
Спасибо за ваши труды.
Не затруднит ли вас выкатить мануал по запуску с использованием portainer, а также настройкой сервера для подключения с другого пк в локальной сети?
Буду делать. У меня уже есть наработки что-бы автоматизировать запуск контейнера сервера на Portainer, нужно просто раширить некоторые функциональные параметры. Сейчас я уже использую мои наработки как раз в тестировании сервера. То есть сначала контейнер замещается на отдельном компьютере на локальной сети на котором уже стоит Portainer, a потом начинается тестирование.

Пока могу только посоветовать почитать где самое главное установить переменную "GS.server.ExternalServerIP=<IP>" на адрес вашего компьютера где установлен Portainer.

А насчет клиента, нужно редактировать фай L2.ini что-бы прописать IP адрес сервера.
 
Не принуждаю, но уверенно скажу что вы поменяете СУБД ))
Будь уверен не сменит. Ничто в жизни не способно изменить его решение. Он будет черпать говно цистернами и костылить в три слоя, но останется верен SQLite. Главное же, что сервер запускается за 5 сек.
 
  • Ха-ха-ха
Реакции: raz
Будь уверен не сменит. Ничто в жизни не способно изменить его решение. Он будет черпать говно цистернами и костылить в три слоя, но останется верен SQLite. Главное же, что сервер запускается за 5 сек.
ваще эти ваши sql-лайты - путь лоха! всё над держать в текстовичках, как тарищи и завещали.
 
Так а за что вы его хейтите? Ну удобно челу прототипировать движок на SQLite. 3.14здец проблема базу поменять? Код опенсорсный, никто не запрещает вам допилить туда любой SQL движок, через слои совместимости. Хейтить за выбор движка бд, максимально тупая хуета, какую можно придумать.
 
Так а за что вы его хейтите? Ну удобно челу прототипировать движок на SQLite. 3.14здец проблема базу поменять? Код опенсорсный, никто не запрещает вам допилить туда любой SQL движок, через слои совместимости. Хейтить за выбор движка бд, максимально тупая хуета, какую можно придумать.
да никто его не хейтит, в свободной стране живем, че хочет то и выбирает, захочет - вообще в текстовики сохранять будет, никого не должно касаться как человек фан получает от этой жизни, если это законно
 
На птсе используется подход через CacheD сервер. Почти любые изменеия бд никак не отражаются на рабочем сервере. Хочешь добавить что - то в бд? Используй запросы к кешеду
 
На птсе используется подход через CacheD сервер. Почти любые изменеия бд никак не отражаются на рабочем сервере. Хочешь добавить что - то в бд? Используй запросы к кешеду
Ну почему, если внести изменение в БД и ребутнуть сервак вместе с CacheD, то изменения применятся )
 
Так а за что вы его хейтите? Ну удобно челу прототипировать движок на SQLite. 3.14здец проблема базу поменять? Код опенсорсный, никто не запрещает вам допилить туда любой SQL движок, через слои совместимости. Хейтить за выбор движка бд, максимально тупая хуета, какую можно придумать.
Не в этом дело немного. Ему говорят что SQLite не подойдет для лайв проекта. А он говорит, что щас десяток костылей сделает и все будет работать окей. Не будет. Как не крути, но очередь на запись при большом онлайне будет заметна в игре.
 
Не в этом дело немного. Ему говорят что SQLite не подойдет для лайв проекта. А он говорит, что щас десяток костылей сделает и все будет работать окей. Не будет. Как не крути, но очередь на запись при большом онлайне будет заметна в игре.
Почему не будет? Давайте поговорим о фактах.
 
Почему не будет? Давайте поговорим о фактах.
Ты все про теорию говоришь. В каком количестве будут сыпать в базу insert при фармящих 500 человек. Возможно со всеми хитростями крихтя пердя и задыхаясь выдержит, но что делать с онлайном 1к+? А на старте? Когда из этой 1000 не на трейде половина, а постоянно фармит и получает/расходует предметы.
Если она такая удобная и звездатая то почему никто в мире не использует её для нагруженных проектов? Задумайся. Есть случаи использования SQLite, но только в связке с полноценной БД.
 
Ты все про теорию говоришь. В каком количестве будут сыпать в базу insert при фармящих 500 человек. Возможно со всеми хитростями крихтя пердя и задыхаясь выдержит, но что делать с онлайном 1к+? А на старте? Когда из этой 1000 не на трейде половина, а постоянно фармит и получает/расходует предметы.
Если она такая удобная и звездатая то почему никто в мире не использует её для нагруженных проектов? Задумайся. Есть случаи использования SQLite, но только в связке с полноценной БД.
Хорошие вопросы. Фактов нет, одни теории (не я про это начал).

Я предпочитаю оптимизировать то что проблематично. Если дейсвительно вы видели такие проблемы, это конечно и есть факт. Но посмотрим что будет в разработке моего проекта. Если будут такие вещи, то нужно будет делать все по-другому. Можно это назвать костылем, а можно назвать улучшением по сравнению с тем что сейчас можно увидеть на Яве. Я уже упоминал про такие проблемы, особенно при фарме где у L2J сечас есть проблемы с 200 лучниками. И это уже используя MariaDB/Mysql отделенную базу данных. Это пример который нужно оптимизировать, а не просто кидать больше ресурсов на маскировку проблемы.

Насчет использования. Достаточно много проектов на западе используют такую базу данных. Она ведь самая популярная на планете. Она интегрированна везде. Тот-же Windows или там Mozilla браузер использует их в множестве. Я не буду глубоко описывать как и почему, но просто скажу что это факт. Возможно несколько сомнительный и смелый. Но есть и дополнительные технологии которые и делают бэкапы для SQLite, как и различные функциональные новшества которые равны тем же БД что вы так хотите видеть ( например ).

Ну и в конце концов почему не другую базу данных? Я уже описывал ситуации когда нужно испльзовать что-то другое чем локальную БД Sqlite. Я только за. Но почему я все-таки ее использую? Все очень просто, я хочу сделать сервер простым в использовании, как и достаточно производительным. Если будут проблемы сo скоростью записи, то нужно будет их решать. Сейчас в сервере есть множественные кеши (cache) которые уменьшают запросы на запись в БД. Например о том что вы написали, о предметах и фарме. Если есть предметы которые попадают либо в инвентарь или же просто лежат в мире (немного другая логика сохранения для них), то во первых все будет сохраняться локально и только через например 10 секунд все изменения инвентарев (именно изменения а не все предметы) всех игроков будут сохранены одним массивным запросом. Почему это нельзя сделать на Яве? Во первых только Acis имеет что-то подобное (у них это построенно на постоянном интервале, на Lineage2TS используется другой debounce интервал). Во вторых, идет блокировка потока, поэтому нужно все делать в другом, не игровом потоке (что не есть проблемой, но будет проблемой если у вас соединение каким-то образом уж очень тормозит). Так вот, это все решения проблемы. Будут другие. Вот и будем решать. А когда прийдет время использования другиx БД, все оптимизированное как раз и будет также помогать БД.

Хочу добавить, что да, вопрос для не-посвященных в оптимизацию всегда стоит o том что они видели, и они видели именно рабочим. Это меня интересует только что-бы я смог решить и оптимизировать решение проблемы. Вот и все. Я не против того что до сих пор вы видели достаточно старые подходы для решений проблем. Но всетаки можно попробовать что-то более интересное.
 
Ему говорят что SQLite не подойдет для лайв проекта.
В дефолтной ява-сборке 80% кодовой базы не подходит для лайв проекта. При этом, никому это не мешает открываться и пилить фиксы по факту, не занимаясь излишней оптимизацией там, где этого не требуется.
На самом деле, даже SQLite на хорошем железе спокойно закроет потребность проекта до 50(пятидесяти) человек на пару дней после старта, а большего сейчас и не требуется. Большинство фич той же MariaDB не используется ни в одной сборке, а для большинства админов, держащих легендарные сервера, использование SQLite фактически не отличается от использования MariaDB, т.к они даже репликацию не настраивают, а часто еще на одной тачке GS и DB держат, да еще и под рутом сидят.
Может быть у него в базу ничего и не должно записываться. Сейчас атомарные не изменяемые образы в тренде. Если оперативки много, то от базы данных можно вообще отказаться. Сервер работает тупо до OOM, потом рестарт-вайп и по новой. Сколько там щяс однодневки ХФ живут? Дня три? Я думаю на тачке с 128гб оперативки спокойно сборка три дня протянет, не удаляя объекты. Просто, элегантно, ебануто.
 
Последнее редактирование:
Назад
Сверху