# Автоматическое создание аккаунтов
AutoCreateAccounts = True
# Шаблон для логина и пароля
AccountTemplate = [A-Za-z0-9]{3,14}
PasswordTemplate = [A-Za-z0-9]{3,16} - с 16 заменил до 32
В каком именно файле?А сам клиент игры тоже должен реагировать на эти символы
Тут то я не знаю...В каком именно файле?
Опция второго пароля есть, так называемый ключ. За базу хорошая подсказка, вынесу сохранение ключей из бд в xml.Сделайте просто серверную опцию второго пароля, и туда запихайте свои 24-32 символа. Быстрая и простая реализация...
Еще можно пароли эти держать в шифрованном каком-нибудь xml файле, а не в бд, что уж 100% до него негодяи разные не добрались)
Отличная идея, особенно когда количество записей придет к паре миллионов, ну или когда человек захочет пароль поменять) Это будет тааак быстро и совсем не асинхронно)Опция второго пароля есть, так называемый ключ. За базу хорошая подсказка, вынесу сохранение ключей из бд в xml.
2 миллиона аккаунтов хм.... даже на астериосе или глобале таких показателей нету даже близко...Отличная идея, особенно когда количество записей придет к паре миллионов, ну или когда человек захочет пароль поменять) Это будет тааак быстро и совсем не асинхронно)
Я не буду с вами спорить, т.к мне похер.2 миллиона аккаунтов хм.... даже на астериосе или глобале таких показателей нету даже близко...
Для реальностей ла2 хорошо если там за 2-3 года лайф сервера набежит тысяч 100. Ну а для интерлюда еще поменьше...
ЗЫ Логи сборки в лайф режиме пишут в текстовики около 30-40 гигов логов в сутки, там много миллионов строк и сборке совершенно пофигу. Откровение для тебя?)
А синхронность тут вообще с какого бока? java отлично синхронит любые файлы если релизить нормально.
P/S У меня в офисе обрабатывает java приложение 11 миллионов строк из xml, и по тестам представь себе sql выполняет дольшепросто все привыкли к sql, так как многим "кодерам" проще запросы в бд делать чем писать макросы или алгоритмы для xml.
2 миллиона аккаунтов хм.... даже на астериосе или глобале таких показателей нету даже близко...
Для реальностей ла2 хорошо если там за 2-3 года лайф сервера набежит тысяч 100. Ну а для интерлюда еще поменьше...
ЗЫ Логи сборки в лайф режиме пишут в текстовики около 30-40 гигов логов в сутки, там много миллионов строк и сборке совершенно пофигу. Откровение для тебя?)
А синхронность тут вообще с какого бока? java отлично синхронит любые файлы если релизить нормально.
P/S У меня в офисе обрабатывает java приложение 11 миллионов строк из xml, и по тестам представь себе sql выполняет дольшепросто все привыкли к sql, так как многим "кодерам" проще запросы в бд делать чем писать макросы или алгоритмы для xml.
А я поспорю. Всё зависит от задачи и что хранится в xml.Я не буду с вами спорить, т.к мне похер.
Зачем спорить с некомпетентными людьми? В его сообщении достаточное количество информации, чтобы судить о его компетенциях и соответственно, сделать выводы и не тратить свое время.А я поспорю. Всё зависит от задачи и что хранится в xml.
Было бы всё так просто, разрабы наверное не изобретали СУБД работающие исключительно с ОЗУ, а сразу бы всё пихали в xml.
P.S. запись лога не есть чтение данных. и выполняется в разы быстрее, т.к. нет никакого поиска.
У меня реализован поиск внутри лога, что делает достаточно удобным ориентирование при поиске нужных данных, особенно поиск рмт и подобное. Попробуй в sql это поискать)А я поспорю. Всё зависит от задачи и что хранится в xml.
Было бы всё так просто, разрабы наверное не изобретали СУБД работающие исключительно с ОЗУ, а сразу бы всё пихали в xml.
P.S. запись лога не есть чтение данных. и выполняется в разы быстрее, т.к. нет никакого поиска.
Разговор про 11кк строк в xml и sql.У меня реализован поиск внутри лога, что делает достаточно удобным ориентирование при поиске нужных данных, особенно поиск рмт и подобное. Попробуй в sql это поискать)
Что касается xml, то вполне безопасно и быстро хранить файлики 2-5 мб, 10-20-100 тысяч строк вообще полная хрень, как более безопасный метод хранения данных игроков я бы такое вполне советовал и да представьте, многие модули защит используют для хранения данных именно xml не sql,
Не люблю этих волшебных людей фанатов забивать все в sql.
Благодаря таким мы даже сейчас находим сборки в которых даже статика хранится в sql.... (Не ну а че давайте уж запихаем в sql все итемы, скиллы, рецепты удобно же?)
Ну 11кк строк, я не относил этого к ла2. Ты где столько данных то найдешь? Тут даже если итемдату игроков вытянуть 2-3кк строк будет всего-лишь за пол года сервера... про 1кк это выполняет приложение в офисе. Там тоже моментального ответа не требуется, но изначально система была на sql и ее фризило жутко)Разговор про 11кк строк в xml и sql.
То что сейчас ты написал, это всё понятно.
Для поиска в логах админу, не нужно моментального выполнения запроса.
Я поэтому и написал зависит от задач.Ну 11кк строк, я не относил этого к ла2. Ты где столько данных то найдешь? Тут даже если итемдату игроков вытянуть 2-3кк строк будет всего-лишь за пол года сервера... про 1кк это выполняет приложение в офисе. Там тоже моментального ответа не требуется, но изначально система была на sql и ее фризило жутко)
Если тебе понятно, что я написал к чему вообще спор? Есть же золотое правило, не храни все яйца в 1 корзине...
SQL вещь очень нужная и хорошая, но не нужно на ней одной зацикливаться)
Сделайте просто серверную опцию второго пароля, и туда запихайте свои 24-32 символа. Быстрая и простая реализация...
Еще можно пароли эти держать в шифрованном каком-нибудь xml файле, а не в бд, что уж 100% до него негодяи разные не добрались)
Если злоумышленник получит доступ к вашей СУБД при условии что она портами на мир не светит (т.е. фактически имеет доступ к файловой системе) - хоть в чем храните свои ключи и шифруйте хоть чем - толку от этого как мертвому припарка.Сделайте просто серверную опцию второго пароля, и туда запихайте свои 24-32 символа. Быстрая и простая реализация...
Еще можно пароли эти держать в шифрованном каком-нибудь xml файле, а не в бд, что уж 100% до него негодяи разные не добрались)
Что касается логгирования, то внутри игры это куда быстрее и удобнее обрабатывать если скрипт написан ровно)Если злоумышленник получит доступ к вашей СУБД при условии что она портами на мир не светит (т.е. фактически имеет доступ к файловой системе) - хоть в чем храните свои ключи и шифруйте хоть чем - толку от этого как мертвому припарка.
В остальном скорость асинхронной записи/чтения без acknowledge в ту же мускуль с выключенным журналированием, с нормально настроенной очередью, размером кэша (уже не говорю об такой элеметарной вещи как ключи) сопоставима с скоростью записи в файл.
Только на выходе с SQL вы получаете возможность, как минимум, связывать поля идентификаторов (accountId/playerId/itemId и проч.) с записями в логах, централизованное хранение, поиск, фильтр - а не грузить этот лог в какой-то кастомный просмотрщик-парсер.
We use cookies and similar technologies for the following purposes:
Do you accept cookies and these technologies?
We use cookies and similar technologies for the following purposes:
Do you accept cookies and these technologies?