Рубрика «сериализация» - 2

Пишем сериализатор для сетевой игры на C++11 - 1Написать этот пост меня вдохновила замечательная статья в блоге Gaffer on Games «Reading and Writing Packets» и неуёмная тяга автоматизировать всё и вся (особенно написание кода на C++!).

Начнём с постановки задачи. Мы пишем сетевую игру (и сразу MMORPG, конечно же!), и независимо от архитектуры у нас возникает необходимость постоянно посылать и получать данные по сети. У нас, скорее всего, возникнет необходимость посылать несколько разных типов пакетов (действия игроков, обновления игрового мира, просто-напросто аутентификация, в конце концов!), и для каждого у нас должна быть функция чтения и функция записи. Казалось бы, не вопрос сесть и написать спокойно эти две функции и не нервничать, однако у нас сразу же возникает ряд проблем.

  • Выбор формата. Если бы мы писали простенькую игру на JavaScript, нас бы устроил JSON или любой его самописный родственник. Но мы пишем серьёзную многопользовательскую игру, требовательную к трафику; мы не можем позволить себе отправлять ~16 байт на float вместо четырёх. Значит, нам нужен «сырой» двоичный формат. Однако, двоичные данные усложняют отладку; было бы здорово, если бы мы могли менять формат в любой момент, не переписывая целиком все наши функции чтения/записи.
  • Проблемы безопасности. Первое правило сетевой игры: не доверяй данным, присланным клиентом! Функция чтения должна уметь оборваться в любой момент и вернуть false, если что-то пошло не так. При этом использовать исключения считается неважной идеей, поскольку они слишком медленные. Мамкин хакер пусть и не сломает ваш сервер, но вполне может ощутимо замедлить его беспрерывными эксепшнами. Но вручную писать код, состоящий из if'ов и return'ов, неприятно и неэстетично.
  • Повторяющийся код. Функции чтения и записи похожи, да не совсем. Необходимость изменить структуру пакета приводит к необходимости поменять две функции, что рано или поздно приведёт к тому, что вы забудете поменять одну из них или поменяете их по-разному, что приведёт к трудно отлавливаемым багам. Как справедливо замечает Gaffer on Games, it is really bloody annoying to maintain separate read and write functions.

Всех интересующихся тем, как Бендер выполнил своё обещание и при этом решил обозначенные проблемы, прошу под кат.
Читать полностью »

Вот весь код: var x = []; x[0x7fffffff]=1; JSON.stringify(x);

Для желающих попробовать: jsfiddle

Таким незамысловатым способом, можно намертво повесить firefox, довести до падения вкладку хрома и повесить основной поток nodejs.

Самое примечательное в этом то, что зависание происходит на уровне нативного кода функции JSON.stringify, что не позволяет прервать выполнение в том же firefox'е, как это обычно бывает при простом while(true);.

При выполнении внутри WebWorker'а в chrome, страница продолжает отвечать, но terminate не может завершить поток.

Так же по понятным причинам, такой код не обнаруживается jslint'ом.

Читать полностью »

Я писал про KTV, но одно дело — придумать что-то непонятное, другое — попробовать это использовать. Помимо стилевой системы S2 я планирую использовать KTV для работы с сервером вместо JSON. Планов завоевать мир у меня нет, но разобраться, удобнее получилось или нет, хочется. Для того, чтобы общаться было легко, нужно уметь парсить объекты из ktv-файлов, и сериализовывать обратно в них же.

Swift, для которого я это пишу, в настоящий момент (Swift 2.x), не предназначен для динамического парсинга совсем, никак, вообще. Поэтому пришлось придумать что-то немного странное и нестандартное. После чего это странное и нестандартное нужно было реализовать.

В процессе было наступлено на бесчисленное количество граблей, про которые я и расскажу. Возможно, кто-то посмеётся над несмышлёным мной, может, кому-то они помогут избежать аналогичных вещей — не знаю. Мне было разбираться полезно.

Если кто видит, как можно проще или лучше решить указанные задачи, пишите. С удовольствием узнаю ещё варианты, так как все, что перечислены ниже, в той или иной степени — костыли. Вдруг есть что-то более приятное.
Читать полностью »

Уже достаточно давно заинтересовался темой сериализации, а если конкретно, то сериализацией объектов, хранящихся по указателю на базовый класс. Например, если мы хотим загружать интерфейс приложения из файла, то скорее всего нам придется заполнять полиморфными объектами контейнер по типу “std::vector<iWidget*>”. Возникает вопрос, как подобное реализовать. Этим я недавно решил заняться и вот что получилось.

Для начала я предположил, что нам все-таки придется унаследовать в базовом классе интерфейс iSerializable, такого вида:

class iSerializable
{
public:
    virtual void serialize (Node node) = 0;
};

Читать полностью »

Сериализация и С++11 - 1
Уверен, что многим кто работает с С++ хотелось, чтобы в этом, дивном языке, была возможность сериализовать объекты так же просто, как скажем в С#. Вот и мне этого захотелось. И я подумал, а почему бы и нет, с помощью нового стандарта это должно быть несложно. Для начала стоит определиться с тем, как это должно выглядеть.

class Test : public Serializable
{
public:
	int SomeInt = 666;
	float SomeFloat = 42.2; 
	string SomeString = "Hello My Little Pony";
private:
	serialize(SomeInt);
	serialize(SomeFloat);
	serialize(SomeString);
};

Такое мне вполне подходило, и я уже представлял себе решение.
Читать полностью »

В процессе разработки плагина для Unity 3D понадобилось сделать хранение относительно большого количества данных. В моем случае это хранение данных нодов для визуального программирования (так же применим и к реализации сохранения игры). Способ хранения должен отвечать заданным требованиям:

  • Высокая скорость обработки;
  • Высокий уровень сжатия данных;
  • Возможность хранения своих классов и структур;
  • Чтениезапись в Unity, а так же в отдельной программе (Visual Studio Application, C#);
  • Работать со старыми версиями сохраненных данных (при изменении структуры);
  • Не должен требовать наличие дополнительно установленных пакетов и др. ПО у пользователей;
  • Работать на мобильных устройствах;
  • Язык: C#.

В результате я остановился на двоичной сериализации. Данный способ отвечает всем заданным требованиям, но лишает возможности просмотра и редактирования уже сериализованных данных в текстовом редакторе. Но это не проблема, так как для этого предназначена программа для редактирования.
Читать полностью »

Пришел день, и конфигурационные файлы для нашего приложения стали настолько большими, что менеджеры намекнули что в JSON-конфигах получается подозрительно много фигурных и не фигурных скобочек, и им хотелось бы от них избавиться. Был дан тонкий намек, что неплохо бы приглядеться к YAML, ведь ходят слухи что он очень человекочитаемый. И скобочек никаких там нет. И списки красивые. Не внять старшим мы естественно не могли, вынуждены были изучать вопрос, искать разницу, плюсы и минусы обоих форматов. Очевидно, что такие сравнения затеваются лишь для того, чтобы подтвердить мнение руководителей или даже если не подтвердить, то они найдут почему они правы и почему стоит делать изменения :)

Сравнение Json и YAML
Читать полностью »

Здесь меня будет интересовать как сериализовать объект Qt, передать его по сети и поддерживать между оригиналом и копией связь синхронизирующую состояние копии. Использовался Qt 4.8.
Читать полностью »

Управление сериализацией объектов в MultiCAD.NET

В предыдущей статье мы рассказали о подходе, который используется для сериализации пользовательских объектов в MultiCAD.NET API. Тогда мы говорили о принципах применения данного подхода для обеспечения совместимости версий объектов и рассмотрели самую простую ситуацию, когда новая версия объекта получается из предыдущей путем добавления дополнительных полей. Сегодня мы предлагаем вашему вниманию обзор процесса обеспечения совместимости в случае более серьёзных изменений, таких как удаление, переименование полей или изменение их типов.
Читать полностью »

Melange — DSL для сетевых протоколовВсем программистам рано или поздно приходится передавать данные. Ни для кого не секрет, что библиотек сериализации в Java существует примерно >9000, а в C++ они вроде и есть, а вроде их и нет. К счастью для большинства, несколько лет назад появился Google Protobuf, который принёс достаточно удобный способ определять структуры данных и быстро завоевал всенародную любовь. Это была фактически первая, доступная широким массам библиотека, позволяющая гонять по сети готовые структуры данных, не связываясь при этом с чем-то вроде XML. На дворе был 2008 год.

Вернёмся немного назад. В 2006 году простой индийский программист (как бы подозрительно это ни звучало!) Анил Мадхавапедди, один из самых известных сейчас в мире OCaml-разработчиков и автор свежевышедшей книги Real World OCaml, защищал в Кембридже кандидатскую диссертацию. Именно о ней я сегодня вам и расскажу.

Анил сразу пошёл дальше, чем Google. Он сразу подумал, для чего люди обычно пересылают по сети какие-то формализованные структуры данных? Чтобы реализовать какой-то протокол. А что такое протокол? Это какой-то конечный автомат. А где мы можем взять хороший пример сложного, хорошо спроектированного и проверенного временем протокола? Да прямо в обычном сетевом стеке! Итак, были взяты набор сетевых структур данных и протоколов: Ethernet frame, IPv4, ICMP, TCP, UDP, SSH, DNS и DHCP и постановка задачи: большая часть этих протоколов (особенно SSH и DNS) реализуются, что называется «руками», а хочется, чтобы не было типичных для C переполнений буфера, все переходы совершались автоматически, это всё можно было верифицировать, и чтобы работало быстро, а не как обычно.

Поскольку никто не будет читать диссертацию, сразу скажу: это более чем удалось. По результатам работы были написаны референсные реализации DNS и SSH-сервера и произведено сравнение с BIND и OpenSSH. OCaml-реализации давали по сравнению с традиционными прирост производительности от незначительного, до почти двухкратного. Кроме того была найдена ошибка в RFC на SSH (рабочая группа была уведомлена и RFC исправлен). О том, что было сделано, и как с этим жить, читайте под катом. Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js