Re: [protobuf] Protobuf 2.6 serialization weird behavior

['Adam Cozzette' via Protocol Buffers]

What does pak.ByteSize() return for those two messages? It would also be
good to verify that SerializeToArray() is returning true, because if not
then there could be an error being missed.

Something seems to be going wrong with the message sizes, because the first
data example seems to have extra data on the end while the second one seems
to be too short (truncated).

By the way, Marc, I tried out your protogen tool just now and it's pretty
cool! That's more convenient than having to fiddle around with creating the
binary data file and running protoc --decode_raw on it.

On Wed, Apr 11, 2018 at 3:25 PM Tony Tony  wrote:

> Well I just copied whatever text was printed after i logged what was being
> serialized. So I probably copied extra bytes not sent from first one (since
> first one deserializes fine). It seems like I'm using correct api call to
> do serialization (and it works with other data combos/types)
>
> The second one, I agree is not right. Just gotta figure out why :|
>
>
>
> On Tuesday, April 10, 2018 at 11:36:29 PM UTC-4, Marc Gravell wrote:
>>
>> Oddly neither of those is correct! The actual hex should be:
>>
>> 08-03-1A-06-08-01-10-63-18-01
>>
>> which is the first version minus some trailing data. The second version
>> is not valid at all - it isn't just missing data: it is an incomplete and
>> invalid payload. Unfortunately I'm not familiar enough with the C++ API to
>> advise on whether you're using the wrong method vs this being a bug.
>>
>>
>> On Wed, 11 Apr 2018, 01:12 Tony Tony,  wrote:
>>
>>> So I upgraded to 3.5.0, same issue.
>>>
>>> I guess I should give some more information: I'm basically using
>>> protobuf to serialize/deserialize string data I'm sending through a games
>>> socket implementation via hooks/code caves in the games network engine. I
>>> currently can validate that the bytes after serialization are sent over
>>> completely to the client. After looking at the decoded output that you guys
>>> recommended, I do see some differences.
>>>
>>> - When I send type=1, count=99, index=1, the server shows the below
>>> bytes after serialization and the client shows these bytes after receiving
>>> the data. The decoding tool shows the correct content.
>>>
>>> 08 03 1A 06 08 01 10 63 18 01 FD FD FD FD
>>>
>>> - When I send type=1, count=0, index=1, the server shows the below bytes
>>> after serialization and the client shows these bytes after receiving the
>>> data. The decoding tool basically shows no content, which is obvious from
>>> the missing data.
>>>
>>> 08 03 1A 06 08
>>>
>>> The biggest difference is that it seems the during serialization on the
>>> server, this combo of data seems to break everything. I guess I'm not sure
>>> why this combo of data would break during serialization. I posted some
>>> pseudo code of where the problem occurs for that combo of data below. It's
>>> just strange that only that combo of data above results in this behavior. I
>>> am able to send large strings just fine, plenty of other data types with no
>>> issues (well none that I've found yet..)
>>>
>>> Packet pak;
>>> pak.set_type(Packet_Type_set_info);
>>>
>>> set_info *setter = pak.mutable_set_info();
>>> setter->set_count(99);
>>> setter->set_type(0);
>>> setter->set_index(1);
>>>
>>> char* SendBuf = new char[pak.ByteSize()];
>>> pak.SerializeToArray(SendBuf, pak.ByteSize());
>>> //TODO: the bytes seem to be wrong right after this point for the second
>>> combo of data
>>> //we send before we delete the sendBuf
>>>
>>> delete[] SendBuf;
>>>
>>>
>>> On Tuesday, April 10, 2018 at 12:41:30 PM UTC-4, Adam Cozzette wrote:

 I think Marc is right that it would be best to isolate the problem by
 manually checking that the bytes are valid.

 Tony, how are you framing the messages? Protocol buffers do not
 describe their own size and so you have to know what size to expect before
 you parse a proto. The typical approach is to frame the serialized messages
 by prefixing them with their size. It's easy to get this wrong, though, so
 that could potentially be the reason that the messages aren't showing up as
 you expect.

 On Tue, Apr 10, 2018 at 7:28 AM Marc Gravell 
 wrote:

> Well, if it was me: the first thing I'd do is isolate whether it is
> serialize or deserialize that is failing - by taking your currently
> serialized data as a flat file or byte dump, and checking whether the
> values are right or wrong.
>
> Depending on the volume and layout of the data, you might be able to
> use protoc's inbuilt decode mechanisms, or (as long as it isn't huge)
> you're welcome to try using https://protogen.marcgravell.com/decode
>
> That would allow you to focus your checks.
>
> Marc
>
> On 10 April 2018 at 14:20, Tony Tony  wrote:
>
>> c++/windows
>>
>> I'll upgrade protobuf and see if 

[protobuf] Re: protobuf and Eclipse EMF & RCP

[Weidong Lian]

On Wednesday, June 12, 2013 at 4:32:03 PM UTC+2, Desmond FitzGerald wrote:
>
> Hi,
> We have been having good success with embedding protobuf messages as a 
> means of specifying all the standard
> processes, with options, for our Geophysics and Geology processing and 
> modelling software base.
>
> Protobuf technology was so close to elements of an internally grown system 
> we had evolved over many years, that it has proven very easy to
> transition, and then get the benfit of being able to easily publish our 
> "data model", and to get the benefit of the much improved
> parsers and automatic java and C_++ code base.  Not withstanding all of 
> that, it has still taken 2 years, as our code base is very large.
>
> The protobuf plugin for Eclipse is also a great tool, and helps a lot.
> This leads me to the question -
> We have also been trying to improve the use of our GUI's by using Eclipse 
> Model Framework. This has an XML style way of capturing the
> the schemas.  Going to the next stage of abstraction and design, Rich 
> Client Platform would appear to be an interesting way of
> joining some of the protbuf ideas, and extending them to also include 
> options for data elements and parameters, to include
> ranges, units, and ways of automating GUI components to prompt and/or edit 
> messages.
>
> So, the question is, has anyone thought of this and given it  a go?  How 
> active is the protobuf community with using Eclipse?
> djf
>

-- 
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 protobuf+unsubscr...@googlegroups.com.
To post to this group, send email to protobuf@googlegroups.com.
Visit this group at https://groups.google.com/group/protobuf.
For more options, visit https://groups.google.com/d/optout.