Parser error - missing required field

903 views
Skip to first unread message

crotty.ch...@gmail.com

unread,
Jan 18, 2013, 1:26:32 PM1/18/13
to prot...@googlegroups.com
I built a small c++ test server and client app using protocol buffers over sockets.

The server sends several packets made up of
  1. a 32 bit marker (0xDEADBEEF)
  2. a 32 bit size of message
  3. the message data.

The message format is

message IQEvent {
  required int32    id = 1;         // instance ID
  required int32    type = 2;       // message type
  optional string   description = 3 [default = ""];
}


The client then just reads these back out.
I'm getting a parser error on the client for each message read:
     'Can't parse message of type "..."  because it is missing required fields: id.

If I print out the hex bytes of what is sent and what is received they are identical.
Each marker and size is seen correctly.
Even after the error message, If I print out the description string it appears correct.

I'm using a CodedOutputStream wrappered around an ArrayOutputStream to write and a CodedInputStream (CIS) wrappered around an ArrayInputStream to read from the socket.
I do set the limit on the CIS during the parsing

  CodedInputStream::Limit msgLimit = cis2.PushLimit(nMsgSize);
  anEvent.ParseFromCodedStream(&cis2);
  cis2.PopLimit(msgLimit);



If I step through the parsing, I can see the IQEvent parse the type and description fields.
After that there are 2 bytes left in the buffer, but the CodedInputStream->ReadTag() returns 0.

Any thoughts as to why this error could be occuring?

Thanks,
Chris



Feng Xiao

unread,
Jan 21, 2013, 1:47:48 AM1/21/13
to crotty.ch...@gmail.com, prot...@googlegroups.com
On Sat, Jan 19, 2013 at 2:26 AM, <crotty.ch...@gmail.com> wrote:
I built a small c++ test server and client app using protocol buffers over sockets.

The server sends several packets made up of
  1. a 32 bit marker (0xDEADBEEF)
  2. a 32 bit size of message
  3. the message data.

The message format is

message IQEvent {
  required int32    id = 1;         // instance ID
  required int32    type = 2;       // message type
  optional string   description = 3 [default = ""];
}


The client then just reads these back out.
I'm getting a parser error on the client for each message read:
     'Can't parse message of type "..."  because it is missing required fields: id.

If I print out the hex bytes of what is sent and what is received they are identical.
You need to ensure that message.has_id() and message.has_type() are both true before sending the message.
 
Each marker and size is seen correctly.
Even after the error message, If I print out the description string it appears correct.

I'm using a CodedOutputStream wrappered around an ArrayOutputStream to write and a CodedInputStream (CIS) wrappered around an ArrayInputStream to read from the socket.
I do set the limit on the CIS during the parsing

  CodedInputStream::Limit msgLimit = cis2.PushLimit(nMsgSize);
  anEvent.ParseFromCodedStream(&cis2);
  cis2.PopLimit(msgLimit);



If I step through the parsing, I can see the IQEvent parse the type and description fields.
After that there are 2 bytes left in the buffer, but the CodedInputStream->ReadTag() returns 0.

Any thoughts as to why this error could be occuring?

Thanks,
Chris




--
You received this message because you are subscribed to the Google Groups "Protocol Buffers" group.
To view this discussion on the web visit https://groups.google.com/d/msg/protobuf/-/QcKbAuzaHBAJ.
To post to this group, send email to prot...@googlegroups.com.
To unsubscribe from this group, send email to protobuf+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/protobuf?hl=en.

crotty.ch...@gmail.com

unread,
Jan 21, 2013, 1:50:51 PM1/21/13
to prot...@googlegroups.com, crotty.ch...@gmail.com
Thanks for the info.
I did check those bits and they were set.


To complete this thread:

I did find my problem.  In my code I allocated enough bytes in the send buffer for two ints (marker and size), but I was sending them as Varint32's.
I changed it to send Uint32's and things are working now.
Reply all
Reply to author
Forward
0 new messages