A server sends responces in protobuf format. I was trying to recreate definitions (proto file) using protoc "decode_raw" mode and faced some strange structure:
2 {
1: 215647270
2 {
215647270 {
1 {
2: "30093005"
}
}
}
5: 360883463
}
As you can see, the value of the field #1 (215647270) is some kind of reference to another field. The value (and the branch, respectively) is random. I couldn't find any information in the official Protobuf documentation regarding this "dynamic" generation of the fields.
Does anyone know how to describe this structure with Protocol buffers messages?
I found out that it is the protobuf’s extension feature and the “random” numbers were just hardcoded by the authors.
Related
I'm creating client side streaming method which proto file definition should be looking similar to this:
service DataService {
rpc Send(stream SendRequest) returns (SendResponse) {}
}
message SendRequest {
string id = 1;
bytes data = 2;
}
message SendResponse {
}
The problem here is that ID is sent with each streaming message even it is needed only once. What's your recommendation and most optimal way for such a use cases?
One hacky approach would be to set ID only once within first message and after that left if blank. But this API is supposed to be used by third party and method definition like above doesn't explaining that well.
I don't think something like this is supported either:
service DataService {
rpc Send(InitialSendRequest, stream DataOnlyRequest) returns (SendResponse) {}
}
I'm currently considering SendRequest message to be something like this, but will have to check how optimal is this compared to the first case considering proto marshaling:
message SendRequest {
oneof request{
string id = 1;
bytes data = 2;
}
}
Your approach of using a oneof with the fields clearly documented saying id is expected only in the first message on the stream and that server implementations will terminate the stream if id is set on subsequent messages on the stream sounds good to me.
The following is a usage of the above described pattern in grpc-lb-v1. Even though the grpc team is moving away from grpc-lb-v1, the above mentioned pattern is a commonly used one.
I'm not very sure about its implications with respect to proto marshaling. That might be a question for the protobuf team.
Hope this helps.
When yang model has a list with multiple keys, ODL is not maintaining the order of the attributes while sending the request down to the netconf device. It appears from RFC 6020 that order needs to be strictly followed.
"The list's key nodes are encoded as subelements to the list's
identifier element, in the same order as they are defined within the
"key" statement."
Mainly my vendor device does not complain while creating the list with out of order but during deletion complains with error.
Yang model example:
container acl-config {
list acl-config-list {
key "tenant-id access-control-list-id";
leaf tenant-id {
type leafref {
path "/tenant:tenant-config/tenant:tenant-list/tenant:tenant-id";
}
description
"Unique identifier of the Tenant";
}
leaf access-control-list-id {
type custom-id;
mandatory true;
description
"Unique ACL identifier";
}
}
ODL while encoding during delete operation sends the request as below:
<edit-config>
<target>
<running/>
</target>
<default-operation>none</default-operation>
<error-option>rollback-on-error</error-option>
<config>
<acl-config xmlns="http://example.com/acl">
<acl-config-list>
<access-control-list-id>acl7</access-control-list-id>
<tenant-id>f81d4fae-7dec-11d0-a765-00a0c91e6bf6</tenant-id>
<acl-dst-config xmlns:a="urn:ietf:params:xml:ns:netconf:base:1.0"
a:operation="delete"/>
</acl-config-list>
</acl-config>
</config>
</edit-config>
</rpc>
I expected tenant-id to be encoded first rather than access-control-list-id as per key order defined in yang. Device throwing below error during delete operation
<rpc-error>
<error-type>protocol</error-type>
<error-tag>missing-element</error-tag>
<error-severity>error</error-severity>
<error-message xml:lang="en">Invalid position of the key "tenant-id" in a
list "acl-config-list".</error-message>
<error-info>
<bad-element>/access_control_list:acl-config/acl-config-list[access-
control-list-id='acl7']/tenant-id</bad-element>
</error-info>
</rpc-error>
I expected ODL to follow strict order of key nodes during XML encoding and as per RFC 6020 statement. This is not happening and device is rejecting the request purely based on out of order issue. Is this a bug in ODL yangtools XML encoding issue or really the device should handle the request in any order ?
It looks like this question is being answered here
To be precise, jira ticket is raised to track this issue.
https://jira.opendaylight.org/browse/YANGTOOLS-1037
I just started to understand how flatbuffers work. The document is good. In the section for usage in c++ i see following example
// Autogenerated class from table Monster.
MonsterT monsterobj;
// Deserialize from buffer into object.
UnPackTo(&monsterobj, flatbuffer);
// Update object directly like a C++ class instance.
cout << monsterobj->name; // This is now a std::string!
monsterobj->name = "Bob"; // Change the name.
// Serialize into new flatbuffer.
FlatBufferBuilder fbb;
Pack(fbb, &monsterobj);
My question is what is the type of flatbuffer? no where in the document it mentioned. Is it the binary buffer either read from file or received over network?
This is the link from where i copied the above sample code.
https://google.github.io/flatbuffers/flatbuffers_guide_use_cpp.html
That documentation looks out of date, it should probably be GetMonster(flatbuffer)->UnPackTo(&monsterobj) where flatbuffer is a pointer to the bytes containing the binary FlatBuffer representation.
The above however is part of the "object API", which you should only be using is convenience is more important than performance. Read about the base API here: https://google.github.io/flatbuffers/flatbuffers_guide_tutorial.html
I am using this git
I am getting error data/config.json does not exist or could not be read.
How do I create json file or load one?
The configuration json file is missing from the source code, however, checking out how the json is parsed in ConfigManager should allow you to create one from scratch.
Just looking at what the property names and types are in that class you can work out something like this:
{
"clips":[
{
"silhouette":"add your silhouette filename here",
"background":"add your background filename here",
"duration":0
}
],
"useKinect":true,
"useGpu":false,
"name":"Your Application Name here",
"resizeSilhouette":false,
"mirrorSilhouette":false,
"resizeSilouhette":false,
"overlayVideo":true,
"useActionClips":false,
"silhouettePadding":{
"top":5,
"right":5,
"bottom":5,
"left":5
},
"centerOfMass":true,
"showTime":true,
"smoothSilhouette":0,
"crossfade":0,
"silhouetteCache":{
"enabled":false,
"minFrames":3,
"maxFrames":10
},
"scale":{
"width":640,
"height":480
},
"osc":{
"enabled":false,
"serverPort":12000,
"clientAddress":"127.0.0.1",
"clientPort":12001,
"channels":0
},
"actions":{
"frequency":1,
"clips":[
"clipName1","clipName2"
]
}
}
If you save this as config.json in your sketch's data folder it should load.
However, bare in mind this may also crash as I've just placed some dummy placeholder data to give you an idea. Fill in the data you think you know what it should be for your project and figure out the rest as you go along.
Unfortunately the github project you decided to use isn't documented, so this means you will have to go through all the source code and understand it before you get to use it.
Using Apache Thrift and generating code in Java, I'm trying to figure if there is a way to have one of the enumerations be returned as default.
For e.g using the following definition:
enum STATE {
UNKNOWN,
AVAILABLE,
UNAVAILABLE
}
I want UNKNOWN to be returned as the default and not a NULL value so that additions to the enum do not affect existing clients.
Is it possible to do that? What are the other options available in this case?
I'm not sure about the part "returned as default" since there is no such thing as a default return value. What may solve your issue could be sth. like:
struct ReturnedValues
{
1: STATE state = UNKNOWN
}
Otherwise you should explain your case.