Спецификация буфера протокола

Question

Недавно я начал интегрировать протокол протокола Google для связи более сложных структур данных в роботизированной сети (например, матрицы, внутренние массивы состояний, информация об устройстве).

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

1) Средняя специфика: делает сообщения конкретными для каждого типа роботов. Пример:

// RobotA.proto 
optional int32 commandID 
repeated double positionData //ex: this robot has many joints 

// RobotB.proto 
optional int32 commandID 
optional int32 subCommandID //ex: this robot has subcommands 
optional double positionData //ex: this robot has only one joint 

2) Низкая специфичность: Сделать сообщения очень общими. Пример:

// GeneralRobotMessage.proto 
optional int32 commandID //switch-case which other potential data is needed 
optional int32 potentialIntData 
repeated double potentialDoubleArray 
optional string potentialStringData 
optional bool potentialBoolData 

3) Высокая специфичность: каждый тип сообщения имеет протобуф. Пример:

// NAKMessage.proto 
// ACKMessage.proto 
// RobotAGetPosition.proto 

Из прошлого опыта, я обычно использую низкую специфичность подход и использовать идентификаторы команд (аку заголовка пакета) для обозначения подхода к синтаксическому анализу сообщения. Но с protobufs, вся концепция предпроектированного .proto, похоже, действует как концепция заголовка.

Есть ли рекомендованный подход к специфичности сообщения? Стандарты кодирования? Практическое правило?

Cheers,

Answer 1

Я предполагаю, что это в основном дело вкуса (делает это Q пограничное по теме.)

я читал, и следовать, в proto3 guide и style guide.

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

Также, если возможно, сохраните все объекты optional, после чего вы сможете изменить формат позже, и он по-прежнему будет совместим с обратной совместимостью.

Nested сообщение может также быть альтернативой, вы можете сделать иерархию как:

message Robot{ 
    optional uint32 id = 1; 
    optional RobotTypeA robo_type_a = 2; 
    optional RobotTypeB robo_type_b = 3; 

    message RobotTypeA { 
    optional uint32 a = 1; 
    optional uint32 b = 2; 
    optional uint32 c = 3; 
    optional uint64 d = 4; 
    optional int32 command_id = 5; 
    optional string ip_address = 6 [default = "10.10.10.10"]; 
    } 

    message RobotTypeB { 
    optional uint32 a = 1; 
    optional uint32 b = 2; 
    optional uint32 c = 3; 
    optional uint64 d = 4; 
    optional int32 command_id = 5; 
    optional string ip_address = 6 [default = "10.10.10.10"]; 
    } 
}