Hello,

we have two applications, one written in Java and one in Python. They are 
exchanging network packets via UDP using protobuf.
We ran into the following error:
We build a packet in python, then serialize it by calling 
SerializeToString():

def serialize(self):

        # create outer packet message
        packetMessage = protoPackets_pb2.PacketMessage()
        packetMessage.type = protoPackets_pb2.PacketMessage.ADVERT
        packetMessage.transactionID = self.transactionID
        
        # add advert-specific content
        packetMessage.advertMessage.finalDestinationIP = 
self.finalDestinationIP
        packetMessage.advertMessage.ceil = self.ceil
        packetMessage.advertMessage.deadline = self.deadline
        packetMessage.advertMessage.fine = self.fine
        packetMessage.advertMessage.initialBudget = self.initialBudget

        return packetMessage.SerializeToString()

This returns us a serialized version of our object as a string. We can 
successfully deserialize it in the python client (we did that to test if 
the serializiation might be the problem).
We now send this string via Ad-hoc UDP to another device, where the Java 
software runs. Out of the received DatagramPacket we take the byte array 
and use PacketMessage.parseFrom(byte[]) to deserialize it.
The problem is the following:
Calling parseFrom causes a InvalidProtocolBufferException, specifically 
because the parser does not seem to recognize when the meaningful input in 
the byte array is "done" and just keeps reading the rest of it (which is 
garbage, filled with 0's). We found a temporary workaround by altering this 
method in CodeInputStream.java:
public boolean isAtEnd() throws IOException {
      
      
    // EVIL HACK: ToDo: Change BACK!
      return bufferPos == bufferSize && !refillBuffer(false) || 
buffer[bufferPos] == 0;
//    return bufferPos == bufferSize && !refillBuffer(false);
  }

Obviously this is not a good solution and while it solves the problem with 
one of our package types, the same problem occurs with another type with 
the difference that the buffer is not filled with 0's but numbers, so our 
hack doesn't work and the parser doesn't stop reading and eventually causes 
the same exception.

Its late so I hope this was not too unclear,
any help would be very much appreciated.

Cheers





-- 
You received this message because you are subscribed to the Google Groups 
"Protocol Buffers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/protobuf.
For more options, visit https://groups.google.com/groups/opt_out.


Reply via email to