Как и следует из названия, автор использует Boost.Fusion для compile-time reflection чтобы парсить данные бинарного протокола в структуры. Поддерживаются примитивные типы, строки, массивы, поля переменной длины, необязательные поля, вложенные структуры, т.е. всё, что используется в типичных бинарных протоколах. В начале статьи объясняется почему не используется готовое решение типа Protobufs или Thrift
Здравствуйте, PM, Вы писали:
PM>Всем привет!
PM>Нашел на reddit/cpp о ссылку на статью Type Driven Wire Protocols with Boost Fusion, мне она показалась интересной.
PM>Как и следует из названия, автор использует Boost.Fusion для compile-time reflection чтобы парсить данные бинарного протокола в структуры. Поддерживаются примитивные типы, строки, массивы, поля переменной длины, необязательные поля, вложенные структуры, т.е. всё, что используется в типичных бинарных протоколах. В начале статьи объясняется почему не используется готовое решение типа Protobufs или Thrift
PM>Насколько я понял, здесь лежит код к статье: https://github.com/rodgert/fusion_samples
Здравствуйте, niXman, Вы писали:
X>глянь еще YARMI.
Ага, спасибо, когда-то уже смотрел. У тебя реализация RPC с описанием протокола на препроцессоре. Т.е. мы с нуля проектируем протокол и вольны в выборе средств (и тут я вероятнее буду смотреть в сторону thrift, без обид )
В статье немного другое — разбор уже кем-то спроектированного и реализованного протокола, когда нет возможности что-то поменять глобально. Как в теме про фонарь в разделе "о работе". Хотя, я бы не рискнул навернуть тестовое задание на Boost.Fusion
Re[3]: Статья "Type Driven Wire Protocols with Boost Fusion"
да, YARMI задумывался как простой способ достижения цели в пересылке POD/плюсовых типов по сети, и при этом иметь максимально быструю диспетчеризацию. обе цели достигнуты успешно.
пачка бумаги А4 стОит 2000 р, в ней 500 листов. получается, лист обычной бумаги стОит дороже имперского рубля =)
Re[3]: Статья "Type Driven Wire Protocols with Boost Fusion"
Здравствуйте, PM, Вы писали:
PM>Здравствуйте, niXman, Вы писали:
X>>глянь еще YARMI.
PM>Ага, спасибо, когда-то уже смотрел. У тебя реализация RPC с описанием протокола на препроцессоре. Т.е. мы с нуля проектируем протокол и вольны в выборе средств (и тут я вероятнее буду смотреть в сторону thrift, без обид )
Вот картинку с этого Кэпа я понять не могу http://kentonv.github.io/capnproto/images/time-travel.png
Справа, каким образом оно получает значение x с сервера, не дожидаясь его? Какой-то маркетинговый буллшит, либо у меня пятница началась раньше обычного?
Re[5]: Статья "Type Driven Wire Protocols with Boost Fusion"
Здравствуйте, Mr.Delphist, Вы писали:
MD>Здравствуйте, enji, Вы писали:
E>>вот еще недавно попалось E>>http://kentonv.github.io/capnproto/index.html
E>>от автора протобуфа
MD>Вот картинку с этого Кэпа я понять не могу http://kentonv.github.io/capnproto/images/time-travel.png MD>Справа, каким образом оно получает значение x с сервера, не дожидаясь его? Какой-то маркетинговый буллшит, либо у меня пятница началась раньше обычного?
Подозреваю, что это связано с тем, что foo() возвращает x, которое идет потом в bar(x).
Re[6]: Статья "Type Driven Wire Protocols with Boost Fusion"
Здравствуйте, Sharpeye, Вы писали:
S>Здравствуйте, Mr.Delphist, Вы писали:
MD>>Здравствуйте, enji, Вы писали:
E>>>вот еще недавно попалось E>>>http://kentonv.github.io/capnproto/index.html
E>>>от автора протобуфа
MD>>Вот картинку с этого Кэпа я понять не могу http://kentonv.github.io/capnproto/images/time-travel.png MD>>Справа, каким образом оно получает значение x с сервера, не дожидаясь его? Какой-то маркетинговый буллшит, либо у меня пятница началась раньше обычного?
S>Подозреваю, что это связано с тем, что foo() возвращает x, которое идет потом в bar(x).
Это-то понятно. Но каким образом клиент посылает bar(x), не дожидаясь этого x? Или там какой-то "future ref", который позволяет сослаться на значение, вычисляемое на серверной стороне? Типа такого:
* принимаем foo()
* вычисление x в фоне
* принимаем bar(future_ref(x))
* ждём окончания foo()
* ресолвим future_ref(x) -> x
* вычисление bar(x) в фоне
Re[5]: Статья "Type Driven Wire Protocols with Boost Fusion"
Здравствуйте, Mr.Delphist, Вы писали:
S>>Подозреваю, что это связано с тем, что foo() возвращает x, которое идет потом в bar(x).
MD>Это-то понятно. Но каким образом клиент посылает bar(x), не дожидаясь этого x? Или там какой-то "future ref", который позволяет сослаться на значение, вычисляемое на серверной стороне? Типа такого: MD>* принимаем foo() MD>* вычисление x в фоне MD>* принимаем bar(future_ref(x)) MD>* ждём окончания foo() MD>* ресолвим future_ref(x) -> x MD>* вычисление bar(x) в фоне
By now you can probably imagine how it works: if you execute bar(foo()),
the client sends two messages to the server, one saying “Please execute foo()”,
and a second saying “Please execute bar() on the result of the first call”.
These messages can be sent together – there’s no need to wait for the first
call to actually return.
Re[5]: Статья "Type Driven Wire Protocols with Boost Fusion"
MD>Вот картинку с этого Кэпа я понять не могу http://kentonv.github.io/capnproto/images/time-travel.png MD>Справа, каким образом оно получает значение x с сервера, не дожидаясь его? Какой-то маркетинговый буллшит, либо у меня пятница началась раньше обычного?
левая картинка
x = foo() // тут отправляем запрос foo(), ждем и получаем ответ - х
y = bar(x) // тут отправляем запрос bar + x, ждем и получаем ответ - у
правая картинка
y = foo().bar() // тут отправляет запрос foo(), и сразу же отправляем запрос bar() относительно его результата. Ждем, получаем y.
Re[6]: Статья "Type Driven Wire Protocols with Boost Fusion"
Здравствуйте, PM, Вы писали:
PM>Как и следует из названия, автор использует Boost.Fusion для compile-time reflection чтобы парсить данные бинарного протокола в структуры. Поддерживаются примитивные типы, строки, массивы, поля переменной длины, необязательные поля, вложенные структуры, т.е. всё, что используется в типичных бинарных протоколах.
Тут нет ничего особенного, достаточно знать возможности Boost.Fusion, а всё остальное механически вытекает из них.
Вот, например, "вся сериализация" на базе Boost.Fusion:
Сейчас всё ядро сериализации — это in/out archive (которые пришлось бы писать в любом случае) + рекурсивная сериализация Boost.Fusion Forward Sequence. На всё про всё — меньше ста строк.
Структуры определяются просто как BOOST_FUSION_DEFINE_STRUCT и уже готовы к сериализации.
Здравствуйте, Sharpeye, Вы писали:
S>Тут это описано: S>
S>By now you can probably imagine how it works: if you execute bar(foo()),
S>the client sends two messages to the server, one saying “Please execute foo()”,
S>and a second saying “Please execute bar() on the result of the first call”.
S>These messages can be sent together – there’s no need to wait for the first
S>call to actually return.
Можно ж пойти дальше — сэкономить и на вызове bar. Правда, окажется что для этого Cap'n'Proto не нужен, достаточно сделать реализовать на стороне сервера метод foobar
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.