Netty + ProtoBuffer: несколько коммуникационных сообщений для одного соединения

Я нашел ветку автора netty в группах Google и понял, что Я должен изменить свою архитектуру или написать свой собственный декодер, как я писал выше, Итак, начните думать, как будет проще и лучше.

Если вы все равно собираетесь писать свои собственные кодеки, возможно, вы захотите рассмотреть реализацию интерфейса Externalizable для пользовательских объектов данных.

• Serializable не требует больших усилий, но худшая производительность (сериализует все).
• Protobuf — это хороший компромисс между усилиями и производительностью (требуется поддержка .proto).
• Externalizable требует больших усилий, но обеспечивает лучшую производительность (нестандартные минимальные кодеки)

Если вы уже знаете, что вашему проекту придется масштабироваться, как горному козлу, возможно, вам придется пройти трудный путь. Protobuf — это не серебряная пуля.

Теоретически это можно сделать, изменив конвейер для каждого входящего сообщения в соответствии с входящим сообщением. Взгляните на объединение портов. пример в Netty.

Последовательность будет следующей:
1) В декодере кадров или другом "DecoderMappingDecoder" вы проверяете тип входящего сообщения
2) Динамически изменяете конвейер, как показано в примере

Но почему бы не использовать разные подключения и следовать такой последовательности:
1) Добавить другие декодеры в конвейер на основе входящего сообщения только один раз.
2) Добавить тот же экземпляр восходящего канала обработчик в качестве последнего обработчика в конвейере, таким образом, все сообщения направляются в один и тот же экземпляр, что почти похоже на одно соединение.

проблема в том, что нет способа отличить два разных сообщения protobuf друг от друга в двоичном формате. Но есть способ решить это в файле protobuf:

message AnyMessage {
    message DataMessage { [...] }
    optional DataMessage dataMessage = 1;
    message TestMessage { [...] }
    optional TestMessage testMessage = 2;
    message SrcMessage { [...] }
    optional SrcMessage srcMessage = 3;
}

необязательные поля, которые не заданы, не создают накладных расходов. Кроме того, вы можете добавить Enum, но это просто бонус.

Проблема заключается не совсем в ограничении Netty или ограничении кодировщика/декодера. Проблема в том, что буферы протокола Google предлагают только способ сериализации/десериализации объектов, но не предоставляют протокол. У них есть какая-то реализация RPC как часть стандартного дистрибутива, но если вы попытаетесь реализовать их протокол RPC, вы получите 3 уровня косвенности. Что я сделал в одном из проектов, так это определил сообщение, которое в основном представляет собой объединение сообщений. Это сообщение содержит одно поле «Тип» и другое поле, являющееся фактическим сообщением. Вы все равно получите 2 уровня косвенности, а не 3. Таким образом, пример от Netty будет работать для вас, но, как упоминалось в предыдущем посте, вам нужно добавить больше логики в обработчик бизнес-логики.

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

После долгих поисков и страданий... мне пришла в голову идея использовать композицию сообщений в одно сообщение-обертку. Внутри этого сообщения я использую ключ oneof, чтобы ограничить количество разрешенных объектов до единственного. Оформить заказ:

message OneMessage {
    MessageType messageType = 1;

    oneof messageBody {
        Event event = 2;
        Request request  = 3;
        Response response = 4;
    }

    string messageCode = 5; //unique message code
    int64 timestamp = 6; //server time
}