Это скорее системное решение для защиты от таких проблем. Все равно что разные сервисы в разных контейнерах запускать, что бы добиться их изоляции друг от друга, а не просто все вместе на одной голой системе.
Ну то есть можно вложить много времени и вычистить годами накопленные баги в разных местах, но потом кто то сделает новую фичу и опять что то сломается.
Я это понимаю как - не удалось сделать что бы один и тот же дедик использовался в разных сессиях по очереди. То есть одну сессию сыграли, а после этого приходится убивать и запускать его заново, вместо того что бы прям в нем загрузить новую карту, очистить состояние и начать играть следующую сессию.
Первый вариант, как я понимаю предполагает что вы все механики игры дублируете, в чисто серверном варианте. Так можно делать, но это очень контрпродуктивный подход.
Во-первых, вам нужно будет каждую фичу реализовывать 2 раза, 1 на сервере, другой на клиенте, что естественно просто в 2 раза дороже.
Во-вторых, очень велика вероятность того что у вас механика на сервере будет обсчитываться немного иначе, что постоянно будет приводить к различным проблема на клиенте.
Ну и самое неприятное - если хочется что бы сервер мог обсчитывать физику игры, то есть проверять попадания по игроку и всякие такие вещи с высокой точностью, без чего шутер сделать не получится, то такой сервер должен полностью дублировать все состояние клиента и весь движок физики в том числе.
Так что подход, когда какой то кусок карты или сессию в игре обсчитывает по сути клиент без рендера - это для шутеров и многих подобных игр, просто необходимость.
Ну и да, естественно движок игры, будь то cry engine или какой то другой, обычно предоставляет необходимые механизмы для такой реализации. Что бы один и тот же код можно было и на клиенте и на сервере выполнять.
Это стандартный паттерн разработки многопользовательских игр - dedicated server. Тот же Unreal Engine и CryEngine предлагает такой подход из коробки. В коде естественно нужно это поддерживать.
Я ещё раз перечитал. У меня изначально создалось впечатление что вы под выдачей левого сертификата имеете ввиду его выдачу без подмены корневого. Если с подменой, то всё так да.
В этом и смысл, что если провайдер выдаст вам левый сертификат, то ваш браузер это увидит и будет ругаться. Либо левый сертификат не будет подписан доверенным корневым сертификатом, про которые знает браузер, либо это будет сертификат на левый сайт.
А сбер как раз и предлагает установить всем доверенный корневой сертификат, которым можно подписать любой другой сертификат и устроить такую MITM атаку.
Честно говоря что что, а 2-й пункт никогда не вызывал вопросов. Потому что в отличие от перегрузки виртуального метода, интерфейс можно реализовать явно. Да, это +1 строчка, но имхо это несущественная мелочь.
class Foo : ICloneable
{
object ICloneable.Clone() => Clone();
public Foo Clone()
{
throw new NotImplementedException();
}
}
Всё смешалось люди кони. SDK и раньше давал доступ к памяти, а причём тут девкиты вообще не ясно.
В оригинале новость про то что если разработчик обновит версию GDK используемую игрой, то под игру будет доступно на несколько сотен мегабайт оперативы больше, которые раньше занимала система.
Было бы интересно услышать ещё об альтернативах — открытое встраиваемое решение написанное на C#. RocksDB/BoltDb более популярны, но они не на C#. RavenDB — платный и не понятно насколько лучше во встраиваемом варианте.
Узнают по тому что теперь новая ссылка на list. Как узнать о конфликте? Это по завершению изменений тот list с которым начали изменения не соответствует актуальному.
Это и есть один из способов работы с многопоточным кодом. И вот этим нужно заниматься самому, вместо того что бы просто вызывать нужный метод, который всё это инкапсулирует внутри и уже кем то написан и проверен.
Взять качественное и проверенное решение и делать схемы, мапперы и транслировать запросы в SQL. Потом возиться с платфомами и архитектурами.
Либо взять nuget пакет с 100 звездами и модной in-memory DB и терять данные из за неправильной синхронизации с ФС :) Альтернативы ИМХО хуже, чем своё написать.
LiteDB как раз тут третья альтернатива. Не требует таких усилий как SQL базы, но и не in-memory и не 100 звёздочек. Хочется больше звёздочек — можно взять BoltDB или RocksDB. Там звёздочек больше чем в dotnet/runtime.
Ну и если у вас есть уже хотя бы раз написанное решение, которое по вашему не обладает таким количеством недостатков и багов, то почему него не выложить его на GitHub, что бы и другие тоже могли его использовать?
За лично мой опыт работы с LiteDB она данные не теряла ни разу и позволила потратить пол дня на то что бы полностью закрыть вопрос с хранением всех данных в проекте.
Но она конечно далека от идеала. Например нет async методов. Да и индексы объявляются достаточно громоздко. Но делать db руками, это явно не то сравнимая по времени написания/поддержки альтернатива.
Т.к. оригинал не изменяемый, то достаточно сделать новую неизменяемую List подобную коллекцию, где будут "запатчены" измененные элементы, в остальном она будет ссылаться на старую.
А как об этом новом list узнает остальной код программы? Как помёржить изменения, если 2 разных потока сделали 2 RO копии одновременно? Если там создаются новые листы то всё равно надо всё будет блокировкой оборачивать, т.к. при оптимистичном подходе вы можете какие то операции по нескольку раз делать, что далеко не всегда приемлемо.
Что за заметки на 1-2Gb? Десктопное приложение обычно оперирует пользовательскими данными, с большим натягом пользователь сгенерирует 1-2Mb данных. Это передёргивание.
Обычные заметки, как в существующих приложениях. Там же не только текст, но и картинки и видосики вполне успешно сохраняются. Ни разу не передёргивание. 1-2Gb успешно влазят в память любого PC даже 10 летней давности и вполне подходят под ваше определение.
Но даже если и 1-2Мб. Добавить nuget пакет на любую популярную db и в 2-3 строчки начать её использовать получается на порядок проще и удобнее чем сделать сериализацию в файлик, а потом по ходу развития проекта постоянно подпирать в нём всё новые проблемные случаи.
Конечно есть случае когда бд не нужна и не незачем тащить мидлвар, но далеко не все случае такие.
Если взять встроенную БД придётся аналогично чинить множество проблем, только уже чужих.
Я прекрасно понимаю желание написать функционал бд самому. Но я не понимаю желания на каждом проекте это делать по новой. Почему нельзя это оформить в nuget и переиспользовать? А если так, то вот и получается своя бд.
Решается immutable структурами данных. Хочешь менять, делай copy-on-write
Такой подход работает только в пределах небольших по объёму структур, но никак не в пределах всей бд, а тут как раз и начинаются проблемы.
Вот есть структура из статьи:
class Item
{
public string Title { get; set; }
public string Description { get; set; }
public List<Field> Fields { get; set; } = new List<Field>();
}
И сама она лежит в каком-нибудь:
class Table
{
public List<Item> Fields { get; set; } = new List<Item>();
}
И вся эта табличка весит 1-2GB. Что вы тут будете менять copy-on-wirte, когда вам нужно будет новый item добавить? Всю таблицу копировать? Если да, то непревзойдённого перфоманса у вас не будет, если нет, то синхронизацию потоков это не обеспечит.
Читать/писать целиком. Писать в новый файл, старый заменять атомарным реплейсом. Читать естественно один раз на старте, дальше работать из памяти.
Я правильно понимаю, что если у меня приложение заметок с сохранёнными данными на 1-2Gb, то при каждом открытии/закрытии оно должно целиком весь файл перечитывать/перезаписывать (а по хорошему вообще на каждый набранный символ тригерить сейв в фоне)? Тут тоже возникают небольшие сомнения относительно скорости работы.
Как выше указано, проблемы нет т.к. нет работы с файлами. Пишут и читают из памяти. На файловой системе остается только последняя копия, которая не может быть сломанной.
Тут как раз возникает та проблема, про которую я говорил в начале. Когда я нажал кнопку добавить/сохранить и приложение сказало что оно всё сделало, то я хочу что бы данные уже на диске были, а не в памяти продолжали висеть. Иначе при любом краше я всё потеряю.
В общем мой поинт по прежнему в том что если в приложении не нужно ни возможность менять данные из разных потоков, ни изменение данных частями, ни гарантированность сохранности данных при краше, то конечно достаточно в 1 строку открыть файл и сериализовать в него json/xml. Но это ни разу не сравнимо по функционалу с тем что даёт нормальная встраиваемая база данных.
Но почему обязательно не помещается в память то. БД не обязательно про огромные размеры, а про удобство использование и уже собранные проблемы при реализации функционала сохранения.
Например обычные заметки. Их можно редактировать и сохранять. А так же они могут хотеть синхронизироваться из облака.
Можно конечно всё написать самому, а потом героически чинить множество проблем и мелочей, которые возникнут в процессе. А можно же взять готовую бд и получить тот же функционал из коробки.
Что она даст? Например возможность не думать о:
Синхронизации потоков. Может прилететь апдейт из облака в другом потоке и бд это разрулит сама;
Синхронизации использования файла на диске. Кто в него пишет, кто читает, всё целиком или частями;
Мерже изменений, если можно менять стейт асинхронно или параллельно;
Роллбек изменений, когда что то пошло не так;
Поиск по значениям полей или даже полнотекстовый поиск (не знаю умеет ли в него конкретно LiteDB);
О сохранности данных на диске в конце концов. Я знаю что если транзакция закоммичена, то даже если приложение крашнёт, то я его переоткрою и данные не потеряются. В случае с файлом есть много ньюансов, типа flush забыли позвать.
А если это десктопное приложение начинает уметь обрабатывать запросы от кого либо извне, то все эти проблемы увеличиваются многократно
Вероятно автор хочет что бы приложение переживало завершение приложения без потери данных. Собственно возможность работы DB без полной загрузки в память, это лишь малая часть её функциональности.
В svn это приходится делать над терабайтным репозиторием. Да, боль, но что поделаешь.
В LFS достаточно просто удалить файл из кеша. Найти актуальные можно простым скриптиком, пробежав по всем lfs объектам в нужных коммитах. К сожалению встроенный git lfs prune не позволяет удобно указать ренж нужных коммитов/веток и делает это со всеми объектами недоступными из нужного коммита.
Svn умеет подрезать историю файлов, что бы как раз такую проблему решать.
Git в свою очередь умеет это хранить в lfs и можно просто удалять объекты, которые уже не нужны (Ну и поверх можно svn сервер запустить).
У svn есть плюсы перед git-ом и поэтому многие старички не хотят с него слезть. Да и ленятся тратить много времени на изучение не профильной (хотя тут уже можно поспорить) технологией.
Западные компании используют Perforce (де-факто стандарт в для крупных игровых студий), который ещё старше. У него так же хватает недостатков, но он к тому же платный.
Но на самом деле можно поднять svn сервер поверх GitLab/Gitea и позволить программистам работать в git, а контент-мейкерам в svn.
По этому я и написал про наиболее подходящий под задачу язык. Если задача например обработка изображений или рендер, то там всё не обойдётся только лишь длинными массивами. Там и множество других проблем всплывёт.
А вот если делать сервер, то Java/C# на порядок более подходящие языки. И даже если появится такая задача с массивами то можно её решить более простым способом, например сделав абстракцию с несколько массивами внутри, а не делать платформозависимый код.
Собственно я пока что не встречал компаний/проектов, где пишут исключительно на одном языке. Из того что я вижу, в рамках одного проекта вполне себе успешно сочетаются C#/C++/Java/Python/Powershell и местами немного Rust/Go.
Тут самое важное что речь идёт только о не игровых компаниях. То есть для фильмов/мультфильмов и тому подобном. Для игроделов ничего не поменяется.
Это скорее системное решение для защиты от таких проблем. Все равно что разные сервисы в разных контейнерах запускать, что бы добиться их изоляции друг от друга, а не просто все вместе на одной голой системе.
Ну то есть можно вложить много времени и вычистить годами накопленные баги в разных местах, но потом кто то сделает новую фичу и опять что то сломается.
Я это понимаю как - не удалось сделать что бы один и тот же дедик использовался в разных сессиях по очереди. То есть одну сессию сыграли, а после этого приходится убивать и запускать его заново, вместо того что бы прям в нем загрузить новую карту, очистить состояние и начать играть следующую сессию.
Первый вариант, как я понимаю предполагает что вы все механики игры дублируете, в чисто серверном варианте. Так можно делать, но это очень контрпродуктивный подход.
Во-первых, вам нужно будет каждую фичу реализовывать 2 раза, 1 на сервере, другой на клиенте, что естественно просто в 2 раза дороже.
Во-вторых, очень велика вероятность того что у вас механика на сервере будет обсчитываться немного иначе, что постоянно будет приводить к различным проблема на клиенте.
Ну и самое неприятное - если хочется что бы сервер мог обсчитывать физику игры, то есть проверять попадания по игроку и всякие такие вещи с высокой точностью, без чего шутер сделать не получится, то такой сервер должен полностью дублировать все состояние клиента и весь движок физики в том числе.
Так что подход, когда какой то кусок карты или сессию в игре обсчитывает по сути клиент без рендера - это для шутеров и многих подобных игр, просто необходимость.
Ну и да, естественно движок игры, будь то cry engine или какой то другой, обычно предоставляет необходимые механизмы для такой реализации. Что бы один и тот же код можно было и на клиенте и на сервере выполнять.
Это стандартный паттерн разработки многопользовательских игр - dedicated server. Тот же Unreal Engine и CryEngine предлагает такой подход из коробки. В коде естественно нужно это поддерживать.
Ну знаете ли, не всем пермадез нравится.
Я ещё раз перечитал. У меня изначально создалось впечатление что вы под выдачей левого сертификата имеете ввиду его выдачу без подмены корневого. Если с подменой, то всё так да.
В этом и смысл, что если провайдер выдаст вам левый сертификат, то ваш браузер это увидит и будет ругаться. Либо левый сертификат не будет подписан доверенным корневым сертификатом, про которые знает браузер, либо это будет сертификат на левый сайт.
А сбер как раз и предлагает установить всем доверенный корневой сертификат, которым можно подписать любой другой сертификат и устроить такую MITM атаку.
Честно говоря что что, а 2-й пункт никогда не вызывал вопросов. Потому что в отличие от перегрузки виртуального метода, интерфейс можно реализовать явно. Да, это +1 строчка, но имхо это несущественная мелочь.
Всё смешалось люди кони. SDK и раньше давал доступ к памяти, а причём тут девкиты вообще не ясно.
В оригинале новость про то что если разработчик обновит версию GDK используемую игрой, то под игру будет доступно на несколько сотен мегабайт оперативы больше, которые раньше занимала система.
Было бы интересно услышать ещё об альтернативах — открытое встраиваемое решение написанное на C#. RocksDB/BoltDb более популярны, но они не на C#. RavenDB — платный и не понятно насколько лучше во встраиваемом варианте.
Это и есть один из способов работы с многопоточным кодом. И вот этим нужно заниматься самому, вместо того что бы просто вызывать нужный метод, который всё это инкапсулирует внутри и уже кем то написан и проверен.
LiteDB как раз тут третья альтернатива. Не требует таких усилий как SQL базы, но и не in-memory и не 100 звёздочек. Хочется больше звёздочек — можно взять BoltDB или RocksDB. Там звёздочек больше чем в dotnet/runtime.
Ну и если у вас есть уже хотя бы раз написанное решение, которое по вашему не обладает таким количеством недостатков и багов, то почему него не выложить его на GitHub, что бы и другие тоже могли его использовать?
За лично мой опыт работы с LiteDB она данные не теряла ни разу и позволила потратить пол дня на то что бы полностью закрыть вопрос с хранением всех данных в проекте.
Но она конечно далека от идеала. Например нет async методов. Да и индексы объявляются достаточно громоздко. Но делать db руками, это явно не то сравнимая по времени написания/поддержки альтернатива.
А как об этом новом list узнает остальной код программы? Как помёржить изменения, если 2 разных потока сделали 2 RO копии одновременно? Если там создаются новые листы то всё равно надо всё будет блокировкой оборачивать, т.к. при оптимистичном подходе вы можете какие то операции по нескольку раз делать, что далеко не всегда приемлемо.
Обычные заметки, как в существующих приложениях. Там же не только текст, но и картинки и видосики вполне успешно сохраняются. Ни разу не передёргивание. 1-2Gb успешно влазят в память любого PC даже 10 летней давности и вполне подходят под ваше определение.
Но даже если и 1-2Мб. Добавить nuget пакет на любую популярную db и в 2-3 строчки начать её использовать получается на порядок проще и удобнее чем сделать сериализацию в файлик, а потом по ходу развития проекта постоянно подпирать в нём всё новые проблемные случаи.
Конечно есть случае когда бд не нужна и не незачем тащить мидлвар, но далеко не все случае такие.
Я прекрасно понимаю желание написать функционал бд самому. Но я не понимаю желания на каждом проекте это делать по новой. Почему нельзя это оформить в nuget и переиспользовать? А если так, то вот и получается своя бд.
Такой подход работает только в пределах небольших по объёму структур, но никак не в пределах всей бд, а тут как раз и начинаются проблемы.
Вот есть структура из статьи:
И сама она лежит в каком-нибудь:
И вся эта табличка весит 1-2GB. Что вы тут будете менять copy-on-wirte, когда вам нужно будет новый item добавить? Всю таблицу копировать? Если да, то непревзойдённого перфоманса у вас не будет, если нет, то синхронизацию потоков это не обеспечит.
Я правильно понимаю, что если у меня приложение заметок с сохранёнными данными на 1-2Gb, то при каждом открытии/закрытии оно должно целиком весь файл перечитывать/перезаписывать (а по хорошему вообще на каждый набранный символ тригерить сейв в фоне)? Тут тоже возникают небольшие сомнения относительно скорости работы.
Тут как раз возникает та проблема, про которую я говорил в начале. Когда я нажал кнопку добавить/сохранить и приложение сказало что оно всё сделало, то я хочу что бы данные уже на диске были, а не в памяти продолжали висеть. Иначе при любом краше я всё потеряю.
В общем мой поинт по прежнему в том что если в приложении не нужно ни возможность менять данные из разных потоков, ни изменение данных частями, ни гарантированность сохранности данных при краше, то конечно достаточно в 1 строку открыть файл и сериализовать в него json/xml. Но это ни разу не сравнимо по функционалу с тем что даёт нормальная встраиваемая база данных.
Но почему обязательно не помещается в память то. БД не обязательно про огромные размеры, а про удобство использование и уже собранные проблемы при реализации функционала сохранения.
Например обычные заметки. Их можно редактировать и сохранять. А так же они могут хотеть синхронизироваться из облака.
Можно конечно всё написать самому, а потом героически чинить множество проблем и мелочей, которые возникнут в процессе. А можно же взять готовую бд и получить тот же функционал из коробки.
Что она даст? Например возможность не думать о:
А если это десктопное приложение начинает уметь обрабатывать запросы от кого либо извне, то все эти проблемы увеличиваются многократно
Вероятно автор хочет что бы приложение переживало завершение приложения без потери данных. Собственно возможность работы DB без полной загрузки в память, это лишь малая часть её функциональности.
В svn это приходится делать над терабайтным репозиторием. Да, боль, но что поделаешь.
В LFS достаточно просто удалить файл из кеша. Найти актуальные можно простым скриптиком, пробежав по всем lfs объектам в нужных коммитах. К сожалению встроенный git lfs prune не позволяет удобно указать ренж нужных коммитов/веток и делает это со всеми объектами недоступными из нужного коммита.
Svn умеет подрезать историю файлов, что бы как раз такую проблему решать.
Git в свою очередь умеет это хранить в lfs и можно просто удалять объекты, которые уже не нужны (Ну и поверх можно svn сервер запустить).
Особенности национального геймдева.
У svn есть плюсы перед git-ом и поэтому многие старички не хотят с него слезть. Да и ленятся тратить много времени на изучение не профильной (хотя тут уже можно поспорить) технологией.
Западные компании используют Perforce (де-факто стандарт в для крупных игровых студий), который ещё старше. У него так же хватает недостатков, но он к тому же платный.
Но на самом деле можно поднять svn сервер поверх GitLab/Gitea и позволить программистам работать в git, а контент-мейкерам в svn.
По этому я и написал про наиболее подходящий под задачу язык. Если задача например обработка изображений или рендер, то там всё не обойдётся только лишь длинными массивами. Там и множество других проблем всплывёт.
А вот если делать сервер, то Java/C# на порядок более подходящие языки. И даже если появится такая задача с массивами то можно её решить более простым способом, например сделав абстракцию с несколько массивами внутри, а не делать платформозависимый код.
Собственно я пока что не встречал компаний/проектов, где пишут исключительно на одном языке. Из того что я вижу, в рамках одного проекта вполне себе успешно сочетаются C#/C++/Java/Python/Powershell и местами немного Rust/Go.