Yep, as i wrote in my previous message, that was it. Thanks for the feedback :)
mcdowella wrote: > This is begining to sound like a well-known TCP gotcha. Like most > stream protocols, there is nothing in the TCP protocol that marks the > boundaries between sender write() calls; TCP sees the connection as a > contiguous stream of bytes. If the protobuf message is fragmented into > multiple tcp frames by the sender, read() calls on the receiver will > typically be satisfied by the first tcp frame received. What is more, > because the TCP implementation of write() can also stuff more than one > write() call into an outgoing frame, the boundary between TCP frames > is not easy to predict - you might get a split inside a small write() > call because there was a little bit of space left over in a TCP frame > from a previous call, but not enough for all of even a very small > write(). It is therefore perfectly legal for you to call write() on > {1,2} and for the receiver to get {1} as the response of a first call > to read() and {2} as the response to the second call to read(). > > If this causes a problem (as it typically does) it is up to you to > e.g. prefix each chunk of data sent with a length count. > > A google search on TCP Message Boundary finds the following from "C# > Network Programming" > > Because TCP does not preserve data message boundaries, you must > compensate for that in your network programs. There are two ways to > handle this: > > * Create a protocol that requires a one-for-one response to each data > message sent from the host > * Design a data message marker system to distinguish data message > boundaries within the data stream > > (I'm not sure what their first option is, unless they mean that you > denote the end of a data message by closing the TCP connection used to > transfer it). > > On Oct 14, 12:01 pm, Dominik Steenken <[EMAIL PROTECTED]> wrote: > >> Yes, we are pretty sure that we do not modify the data prior to putting >> it on the wire. We have discovered a new fact, however that will >> hopefully shed some light on this bizarre error. The error seems to >> occur the instance the protobuf message is fragmented in the transport >> layer, i.e. when it is larger than a single tcp frame. Any thoughts on >> that? Has someone encountered this error before? >> >> Kenton Varda wrote: >> >>> Are you sure that the data you are sending to the parser is exactly >>> the same data that was generated by the serializer? Remember that >>> protocol buffers are not self-delimiting, so you need to make sure >>> that you limit the input to the exact number of bytes that were >>> produced when serializing. >>> >>> If the data is exactly the same, then this is a bug. If you can >>> create a small program or pair of programs that demonstrate the >>> problem, I would be happy to debug it. >>> >>> On Mon, Oct 13, 2008 at 10:09 AM, Dominik Steenken <[EMAIL PROTECTED] >>> <mailto:[EMAIL PROTECTED]>> wrote: >>> >>> Hi everyone, >>> >>> we are currrently implementing a server/client system, the server >>> being implemented in c++, the client in java. During our last rounds >>> of tests, we encountered a problem that had to do with the sending of >>> (not so) long messages. on the (receiving) java side, we get the >>> following exception: >>> Exception in augnet.client.aim.connection.Receiver, Parse error: >>> com.google.protobuf.InvalidProtocolBufferException: Protocol message >>> contained an invalid tag (zero). >>> com.google.protobuf.InvalidProtocolBufferException: Protocol message >>> contained an invalid tag (zero). >>> at >>> >>> com.google.protobuf.InvalidProtocolBufferException.invalidTag(InvalidProtocolBufferException.java: >>> 52) >>> at >>> com.google.protobuf.CodedInputStream.readTag(CodedInputStream.java: >>> 67) >>> at com.google.protobuf.FieldSet.mergeFrom(FieldSet.java:397) >>> at com.google.protobuf.AbstractMessage >>> $Builder.mergeFrom(AbstractMessage.java:248) >>> at com.google.protobuf.GeneratedMessage >>> $Builder.mergeFrom(GeneratedMessage.java:1) >>> at >>> com.google.protobuf.CodedInputStream.readMessage(CodedInputStream.java: >>> 227) >>> at >>> com.google.protobuf.FieldSet.mergeFieldFrom(FieldSet.java:482) >>> at com.google.protobuf.FieldSet.mergeFrom(FieldSet.java:402) >>> at com.google.protobuf.AbstractMessage >>> $Builder.mergeFrom(AbstractMessage.java:248) >>> at com.google.protobuf.GeneratedMessage >>> $Builder.mergeFrom(GeneratedMessage.java:1) >>> at >>> com.google.protobuf.CodedInputStream.readMessage(CodedInputStream.java: >>> 227) >>> at >>> com.google.protobuf.FieldSet.mergeFieldFrom(FieldSet.java:482) >>> at com.google.protobuf.FieldSet.mergeFrom(FieldSet.java:402) >>> at com.google.protobuf.AbstractMessage >>> $Builder.mergeFrom(AbstractMessage.java:248) >>> at com.google.protobuf.AbstractMessage >>> $Builder.mergeFrom(AbstractMessage.java:240) >>> at com.google.protobuf.AbstractMessage >>> $Builder.mergeFrom(AbstractMessage.java:298) >>> at augnet.client.aim.messages.MessageProtos >>> $AugNetMessage.parseFrom(MessageProtos.java:6289) >>> at augnet.client.aim.connection.Receiver.run(Receiver.java:47) >>> >>> while the (sending) c++ side encounters no errors. When we scale down >>> the message, no error occurs. Is this a bug in protobuf or are we >>> doing something wrong? >>> >>> Best regards, >>> Dominik >>> > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Protocol Buffers" group. To post to this group, send email to protobuf@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/protobuf?hl=en -~----------~----~----~----~------~----~------~--~---