Вообще для сервера кажется не обязательно делать cleartext mode. Для tls порта можно переключаться между http1/h2 через alpn. А для обычного можно проверить h2 preface. А, или параметр просто в принципе отключает tls?
Опасности ddos через ping это когда на сервер идут прямые клиентские соединения и их много. Для внутрисерверных соединений ping вполне нормальный механизм. Таймаут можно делать маленький, всё равно под нагрузкой никаких пингов не будет, время считается от момента последней входящей активности.
Если у вас JSON, вам скорее всего не нужен schema registry. Это вообще штука заточенная чисто под avro. Дело в том что это формат сериализации, в котором отсутствуют метаданные. Там нет названий полей как в json или тегов как в protobuf. Это просто бинарно закодированные подряд все поля структуры. И не зная с какой схемой было закодировано сообщение, декодировать его невозможно. Поэтому avro без schema registry существовать практически не может. Выбирая avro надо всегда иметь в виду что все producers и consumers становятся зависимыми от schema registry. И сам он становится критичной частью всей инфраструктуры.
Я немножко не из мира java, но, насколько я представляю, дело обстоит примерно так: клиент имеет свою схему, через registry (регистрируя) он может получить её id. Если id схемы в получаемом сообщении совпадает с клиентской, всё просто. Если нет, клиент запрашивает схему сообщения из registry и если она совместима должен построить конвертер, который декодирует сообщение по старой (или может быть новой) схеме и по правилам эволюции схемы преобразует его в объект текущей схемы.
Абсолютно никак не влияет. Брокеру без разницы что в него кладут, он ничего не проверяет. Schema registry это то, с чем работают клиенты через отдельный api. Оно может быть вообще в другой кафке если что, кафка для этого сервиса просто хранилище. Режимы совместимости в avro просто накладывают ограничения на возможности модификации схем, так чтобы клиент имея локально схему версии X мог декодировать сообщение закодированное со схемой версии Y. Соответственно schema registry при обновлении схемы может такие ограничения проверять и не даст изменить схему если совместимость нарушается.
Ну с variant надо накладные считать, экономит указатель и косвенную адресацию но всегда ест max(sizeof). Ну и таблицы в нем обычно если не boost. А switch я имел в виду именно по Stmt, не по variant, простой перебор всех kind: template<Vis> visit(Stmt&, Vis) ... case If: vis(static_cast<If&>)... Чтобы не писать цепочки if dyn_cast, а использовать перегрузки. Например деструктор без virtual: visit(stmt, (auto& s) { delete &s; });
Есть ещё пара вариантов. Первый это std::variant с автоматическим kind. Второй - написать один шаблонный visit(Stmt&, Visitor) со switch/function table и повыкидывать все цепочки if...else if.
> Легко понять, что умножение 12 на 1 бессмысленно, а скобки вокруг 2 * order не нужны.
Легко заметить что x << n = x * (2^(n+1)). И (x * 1) << n эквивалентно x * (1 << n). А вот вторые скобки обязательны. Чтобы не вспоминать про приоритеты.
Это на основании того что анализируемое значение enum? Частенько использую что то вроде enum class SomeId { null = 0 }. Ну и проверки вроде if(id == SomeId::null) return; Всё за такой проверкой будет считаться unreachable?
А чем не вариант для константных строк использовать string_view? Если она инициализируется литералом, время жизни обеспечено. Можно даже отнаследовать какой нибудь literal_view с constexpr конструктором из массива char.
Ой, простите, только сейчас заметил что это перевод....
И ещё можете поразвлекаться с h2spec, поищите на github, там базовые проверки соответствия спецификации.
Кстати, мелочь может, но зачем для body конверсия string -> vector? Даже если данные бинарные чем плох просто string?
Вообще для сервера кажется не обязательно делать cleartext mode. Для tls порта можно переключаться между http1/h2 через alpn. А для обычного можно проверить h2 preface. А, или параметр просто в принципе отключает tls?
RVO начиная с C++17 обязателен.
Опасности ddos через ping это когда на сервер идут прямые клиентские соединения и их много. Для внутрисерверных соединений ping вполне нормальный механизм. Таймаут можно делать маленький, всё равно под нагрузкой никаких пингов не будет, время считается от момента последней входящей активности.
Что за message header и magic byte?
Если у вас JSON, вам скорее всего не нужен schema registry. Это вообще штука заточенная чисто под avro. Дело в том что это формат сериализации, в котором отсутствуют метаданные. Там нет названий полей как в json или тегов как в protobuf. Это просто бинарно закодированные подряд все поля структуры. И не зная с какой схемой было закодировано сообщение, декодировать его невозможно. Поэтому avro без schema registry существовать практически не может. Выбирая avro надо всегда иметь в виду что все producers и consumers становятся зависимыми от schema registry. И сам он становится критичной частью всей инфраструктуры.
Я немножко не из мира java, но, насколько я представляю, дело обстоит примерно так: клиент имеет свою схему, через registry (регистрируя) он может получить её id. Если id схемы в получаемом сообщении совпадает с клиентской, всё просто. Если нет, клиент запрашивает схему сообщения из registry и если она совместима должен построить конвертер, который декодирует сообщение по старой (или может быть новой) схеме и по правилам эволюции схемы преобразует его в объект текущей схемы.
Абсолютно никак не влияет. Брокеру без разницы что в него кладут, он ничего не проверяет. Schema registry это то, с чем работают клиенты через отдельный api. Оно может быть вообще в другой кафке если что, кафка для этого сервиса просто хранилище. Режимы совместимости в avro просто накладывают ограничения на возможности модификации схем, так чтобы клиент имея локально схему версии X мог декодировать сообщение закодированное со схемой версии Y. Соответственно schema registry при обновлении схемы может такие ограничения проверять и не даст изменить схему если совместимость нарушается.
Упс, пардон, это перевод...
4 миллиарда по 100 байт это примерно 400 гигабайт в минуту. Умножаем на 8, делим на 60. Это канал в 53 гигабита. Что за железо?
Ну с variant надо накладные считать, экономит указатель и косвенную адресацию но всегда ест max(sizeof). Ну и таблицы в нем обычно если не boost. А switch я имел в виду именно по Stmt, не по variant, простой перебор всех kind: template<Vis> visit(Stmt&, Vis) ... case If: vis(static_cast<If&>)... Чтобы не писать цепочки if dyn_cast, а использовать перегрузки. Например деструктор без virtual: visit(stmt, (auto& s) { delete &s; });
Есть ещё пара вариантов. Первый это std::variant с автоматическим kind. Второй - написать один шаблонный visit(Stmt&, Visitor) со switch/function table и повыкидывать все цепочки if...else if.
Легко заметить что x << n = x * (2^(n+1)). И (x * 1) << n эквивалентно x * (1 << n). А вот вторые скобки обязательны. Чтобы не вспоминать про приоритеты.
В примере с рефакторингом через switch последние две строки просто переходят в default ветку. И перестают считаться unreachable.
Но там же if/elsif/elsif. Ветки else нет. Судить о недостижимом можно только по тому что в этих ветках проверены все значения enum.
Это на основании того что анализируемое значение enum? Частенько использую что то вроде enum class SomeId { null = 0 }. Ну и проверки вроде if(id == SomeId::null) return; Всё за такой проверкой будет считаться unreachable?