[protobuf] Re: Re-Parsing Received CodedMessages Over Network (Proto3)
I'm continuing to fiddle with this problem. For some reason it seems that
I'm missing a byte count when sending from my client.
m_client.GetServerConnection.GetClient().Send(m_packet,
message.CalculateSize() + 1) // I needed to add + 1
I thought it was strange that my message was only being received as:
#\u0012!\n\u001Ftype.googleapis.com/server.Pin
I'm not sure why I have to add + 1 tho and CalculateSize isn't giving the
correct size naturally.
On Saturday, July 23, 2016 at 2:56:08 PM UTC-7, Chazix wrote:
>
> I'm utilizing Protobuf3 with c# for my client & c++ for my server, where
> the .proto's are generated from the corresponding protoc3 compiler. I'm new
> to utilizing Google Protocol Buffers, where I'm currently trying to figure
> out how to re-parse the received bytes on my server that were sent from my
> client to turn it back into it's originating google::protobuf::Message
> object on my c++ server.
>
> My client is sending a CodedOutputStream in c# :
>
> public PacketHandler()
>> {
>> m_client = GetComponent();
>> m_packet = new
>> byte[m_client.GetServerConnection().GetMaxPacketSize()];
>> m_ostream = new BinaryWriter(new MemoryStream(m_packet));
>> }
>>
>> public void DataToSend(IMessage message)
>> {
>> // message looks like :
>> // Base.BaseMessage msg = new Base.BaseMessage();
>> // msg.Msg = Google.Protobuf.WellKnownTypes.Any.Pack(new
>> Server.Ping());
>> CodedOutputStream output = new
>> CodedOutputStream(m_ostream.BaseStream, true);
>> output.WriteMessage(message);
>> output.Flush();
>> m_client.GetServerConnection().GetClient().Send(m_packet,
>> message.CalculateSize());
>> }
>>
>
> This seems to be working, the message that is sent right now is a simple
> Ping message that looks like this:
>
> // Ping.proto
>> syntax = "proto3";
>> package server;
>>
>> import "BaseMessage.proto";
>>
>> message Ping {
>>
>> }
>>
>> message Pong {
>>
>> }
>>
>
> My BaseMessage looks like this :
>
> // BaseMessage.proto
>> syntax = "proto3";
>>
>> package base;
>>
>> message BaseMessage {
>> uint32 size = 1;
>> google.protobuf.Any msg = 2;
>> }
>>
>
> The received message that I am getting on my c++ server side looks like
> this : #\u0012!\n\u001Ftype.googleapis.com/server.Pin
>
> When receiving the message I am attempting to re-parse using the
> CodedInputStream object by attempting to parse the received bytes.
>
> PacketHandler::PacketHandler(QByteArray& packet, const
>> Manager::ClientPtr client) :
>> m_packet(packet),
>> m_client(client)
>> {
>> unsigned char buffer[512] = { 0 };
>> unsigned char data[packet.size()] = { 0 };
>> memcpy(data, packet.data(), packet.size());
>>
>> google::protobuf::uint32 msgSize;
>> google::protobuf::io::CodedInputStream inputStream(data,
>> packet.size());
>> inputStream.ReadVarint32(); // read the prefixed message
>> length
>>
>> base::BaseMessage msg;
>> msg.ParseFromCodedStream();
>>
>> if (msg.msg().Is())
>> {
>> // This never occurs
>> server::Ping pingMsg;
>> msg.msg().UnpackTo();
>> qDebug() << "Is a Ping";
>> }
>> qDebug() << msg.size(); // this isn't the correct value either
>> }
>>
>
> This is where I am a bit unsure of the process that is needing to be done
> to re-parse the message into the particular message. I'm reading the
> initial prefixed length of message to remove that from the parse, where the
> inputStream has the remaining bytes for the message identification.
>
--
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.
[protobuf] Re: Hang on compiler stage => /bin/sh ../libtool --tag=CXX --mode=link
Sorry about the late repost, but this was solved by making sure to compile through the cygwin / msys console instead of your default command prompt. On Friday, July 8, 2016 at 11:50:30 AM UTC-7, Chazix wrote: > > I am encountering a very strange problem. I recently compiled just fine, > however, I decided to clean & recompile and now my linking stage seems to > be hanging and not progressing. > > I'm using cygwin64 with msys for generating the configuration. I haven't > changed anything since my last compile. > > This is the current stage that is stuck: > >> /bin/sh ../libtool --tag=CXX --mode=link g++ -DHAVE_PTHREAD=1 >> -DHAVE_ZLIB=1 -Wall -Wwrite-strings -Woverloaded-virtual -Wno-sign-compare >> -O2 -g -DNDEBUG -version-info 10:0:0 -export-dynamic -no-undefined -o >> libprotobuf.la -rpath /usr/local/lib >> google/protobuf/stubs/atomicops_internals_x86_gcc.lo >> google/protobuf/stubs/atomicops_internals_x86_msvc.lo >> google/protobuf/stubs/bytestream.lo google/protobuf/stubs/common.lo >> google/protobuf/stubs/int128.lo google/protobuf/stubs/once.lo >> google/protobuf/stubs/status.lo google/protobuf/stubs/statusor.lo >> google/protobuf/stubs/stringpiece.lo google/protobuf/stubs/stringprintf.lo >> google/protobuf/stubs/structurally_valid.lo >> google/protobuf/stubs/strutil.lo google/protobuf/stubs/time.lo >> google/protobuf/arena.lo google/protobuf/arenastring.lo >> google/protobuf/extension_set.lo google/protobuf/generated_message_util.lo >> google/protobuf/message_lite.lo google/protobuf/repeated_field.lo >> google/protobuf/wire_format_lite.lo google/protobuf/io/coded_stream.lo >> google/protobuf/io/zero_copy_stream.lo >> google/protobuf/io/zero_copy_stream_impl_lite.lo google/protobuf/any.pb.lo >> google/protobuf/api.pb.lo google/protobuf/stubs/mathlimits.lo >> google/protobuf/any.lo google/protobuf/descriptor.lo >> google/protobuf/descriptor_database.lo google/protobuf/descriptor.pb.lo >> google/protobuf/duration.pb.lo google/protobuf/dynamic_message.lo >> google/protobuf/empty.pb.lo google/protobuf/extension_set_heavy.lo >> google/protobuf/field_mask.pb.lo >> google/protobuf/generated_message_reflection.lo >> google/protobuf/map_field.lo google/protobuf/message.lo >> google/protobuf/reflection_ops.lo google/protobuf/service.lo >> google/protobuf/source_context.pb.lo google/protobuf/struct.pb.lo >> google/protobuf/stubs/substitute.lo google/protobuf/text_format.lo >> google/protobuf/timestamp.pb.lo google/protobuf/type.pb.lo >> google/protobuf/unknown_field_set.lo google/protobuf/wire_format.lo >> google/protobuf/wrappers.pb.lo google/protobuf/io/gzip_stream.lo >> google/protobuf/io/printer.lo google/protobuf/io/strtod.lo >> google/protobuf/io/tokenizer.lo google/protobuf/io/zero_copy_stream_impl.lo >> google/protobuf/compiler/importer.lo google/protobuf/compiler/parser.lo >> google/protobuf/util/field_comparator.lo >> google/protobuf/util/field_mask_util.lo >> google/protobuf/util/internal/datapiece.lo >> google/protobuf/util/internal/default_value_objectwriter.lo >> google/protobuf/util/internal/error_listener.lo >> google/protobuf/util/internal/field_mask_utility.lo >> google/protobuf/util/internal/json_escaping.lo >> google/protobuf/util/internal/json_objectwriter.lo >> google/protobuf/util/internal/json_stream_parser.lo >> google/protobuf/util/internal/object_writer.lo >> google/protobuf/util/internal/protostream_objectsource.lo >> google/protobuf/util/internal/protostream_objectwriter.lo >> google/protobuf/util/internal/proto_writer.lo >> google/protobuf/util/internal/type_info.lo >> google/protobuf/util/internal/type_info_test_helper.lo >> google/protobuf/util/internal/utility.lo google/protobuf/util/json_util.lo >> google/protobuf/util/message_differencer.lo >> google/protobuf/util/time_util.lo >> google/protobuf/util/type_resolver_util.lo -lz >> > > I am not sure why it worked before and now I am not able to progress. It > looks like it is working in sed.exe. I've left it here for a good 20 > minutes without any progression. > > Thanks for any information. > -- 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.
Re: [protobuf] Re: Re-Parsing Received CodedMessages Over Network (Proto3)
Thanks for the insight, that definitely does work for collecting my
message, and it seems to be more so a standard compared to what I was
doing, at least for my server side.
On my C# client side, I still have to add + 1 to the
IMessage.CalculateSize() function when sending over my UdpClient object
unfortunately.
public void DataToSend(IMessage message)
> {
> CodedOutputStream output = new CodedOutputStream(m_ostream.BaseStream,
> true);
> output.WriteMessage(message);
> output.Flush();
> (m_ostream.BaseStream as MemoryStream).SetLength(0); // reset stream for
> next packet(s)
> m_client.GetServerConnection().GetClient().Send(m_packet,
> message.CalculateSize() + 1);
> }
>
On Friday, July 29, 2016 at 4:18:29 PM UTC-7, Adam Cozzette wrote:
>
> I believe the problem you're running into is on the server side; it looks
> like you're parsing the size correctly but just skipping over it. Since
> protocol buffers are not self-delimiting, you must actually rely on the
> size to know how many bytes to read. I think what's probably happening is
> that the CodedInputStream is reading past the end of your message and
> trying to interpret whatever the bytes are that happen to come after it.
> The way to solve this is to use CodedInputStream's PushLimit and PopLimit
> methods. In your example something like this should work:
>
> google::protobuf::io::CodedInputStream::Limit limit =
> inputStream.PushLimit(msgSize);
> if (!msg.ParseFromCodedStream() ||
> !inputStream.ConsumedEntireMessage()) {
> // handle error ...
> }
> inputStream.PopLimit(limit);
>
> Let me know if this fixes it.
>
> On Sat, Jul 23, 2016 at 3:51 PM, Chazix <m11...@gmail.com >
> wrote:
>
>> I'm continuing to fiddle with this problem. For some reason it seems that
>> I'm missing a byte count when sending from my client.
>>
>> m_client.GetServerConnection.GetClient().Send(m_packet,
>> message.CalculateSize() + 1) // I needed to add + 1
>>
>> I thought it was strange that my message was only being received as:
>> #\u0012!\n\u001Ftype.googleapis.com/server.Pin
>>
>> I'm not sure why I have to add + 1 tho and CalculateSize isn't giving the
>> correct size naturally.
>>
>>
>> On Saturday, July 23, 2016 at 2:56:08 PM UTC-7, Chazix wrote:
>>>
>>> I'm utilizing Protobuf3 with c# for my client & c++ for my server, where
>>> the .proto's are generated from the corresponding protoc3 compiler. I'm new
>>> to utilizing Google Protocol Buffers, where I'm currently trying to figure
>>> out how to re-parse the received bytes on my server that were sent from my
>>> client to turn it back into it's originating google::protobuf::Message
>>> object on my c++ server.
>>>
>>> My client is sending a CodedOutputStream in c# :
>>>
>>> public PacketHandler()
>>>> {
>>>> m_client = GetComponent();
>>>> m_packet = new
>>>> byte[m_client.GetServerConnection().GetMaxPacketSize()];
>>>> m_ostream = new BinaryWriter(new MemoryStream(m_packet));
>>>> }
>>>>
>>>> public void DataToSend(IMessage message)
>>>> {
>>>> // message looks like :
>>>> // Base.BaseMessage msg = new Base.BaseMessage();
>>>> // msg.Msg = Google.Protobuf.WellKnownTypes.Any.Pack(new
>>>> Server.Ping());
>>>> CodedOutputStream output = new
>>>> CodedOutputStream(m_ostream.BaseStream, true);
>>>> output.WriteMessage(message);
>>>> output.Flush();
>>>> m_client.GetServerConnection().GetClient().Send(m_packet,
>>>> message.CalculateSize());
>>>> }
>>>>
>>>
>>> This seems to be working, the message that is sent right now is a simple
>>> Ping message that looks like this:
>>>
>>> // Ping.proto
>>>> syntax = "proto3";
>>>> package server;
>>>>
>>>> import "BaseMessage.proto";
>>>>
>>>> message Ping {
>>>>
>>>> }
>>>>
>>>> message Pong {
>>>>
>>>> }
>>>>
>>>
>>> My BaseMessage looks like this :
>>>
>>> // BaseMessage.proto
>>>> syntax = "proto3";
>>>>
>>>> package base;
>>>>
>>>> message BaseMessage {
>>>> uint32 size = 1;
>>
[protobuf] libprotobuf WARNING text_format.cc:1537 Proto type not found
When receiving & parsing my message from a CodedInputStream & then do a msg.ShortDebugString() I'm always getting debug output of : [libprotobuf WARNING google/protobuf/text_format.cc:1537] Proto type type.googleapis.com/server.Ping not found Are there other external locations where I need to define my message for recognition for resolving this warning? The message is valid when I utilize it, but for some reason I'm just receiving this warning after each message. -- 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.
[protobuf] Message with multiple strings problem
Hello,
I have a message that looks like:
message Connected {
> sint32 xloc = 1; // x spawn world position
> sint32 yloc = 2; // y spawn world position
> sint32 zrot = 3; // z spawn rotation
> string sector = 4; // sector name (unsure about this)
> string name = 5; // player name
> string pid= 6; // player id
> string scolor = 7; // ship color
> string sname = 8; // ship name
> }
I am attempting to initialize it within my c++ code like this:
>
> GameClientStats& stats = gameClient.GetGameClientStats();
> server::player::Connected connectMessage; // send this to this joining
> client
> connectMessage.set_name(stats.m_clientName);
> connectMessage.set_pid(stats.m_clientId);
> connectMessage.set_scolor(stats.m_shipColor);
> connectMessage.set_sname(stats.m_shipName);
> connectMessage.set_xloc(stats.m_xPos);
> connectMessage.set_yloc(stats.m_yPos);
> connectMessage.set_zrot(stats.m_zRot);
For some reason as I set my string parameters, the prior strings before it
gets set to that string value. So, if I do the set_pid the name field will
also change to the pid. set_scolor the name & pid will be set to the
s_color. set_sname the name, pid & scolor will change to be the sname. It
seems like they are all sharing the same string pointer field location.
Am I not initializing my message correctly? Or do I need to do something
differently here? When I Serialize my messages from a coded stream I get my
expected message, but manual creation doesn't seem to be working with what
I'm currently trying to do.
Thank you very much for the information.
--
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.
[protobuf] Re: Message with multiple strings problem
Changing to use a repeated field for my strings seems to have fixed the
problem.
message Connected {
> sint32 xloc = 1; // x spawn world position
> sint32 yloc = 2; // y spawn world position
> sint32 zrot = 3; // z spawn rotation
> // [0] => username
> // [1] => userid
> // [2] => shipcolor
> // [3] => shipname
> repeated string userinfo = 4;
> }
>
With this I am able to manually add the new strings to the repeated string
list.
server::player::Connected connectMessage;
> connectMessage.set_xloc(stats.m_xPos);
> connectMessage.set_yloc(stats.m_yPos);
> connectMessage.set_zrot(stats.m_zRot);
> // [0] => username
> connectMessage.add_userinfo();
> connectMessage.set_userinfo(0, stats.m_clientName);
> // [1] => userid
> connectMessage.add_userinfo();
> connectMessage.set_userinfo(1, stats.m_clientId);
> // [2] => shipcolor
> connectMessage.add_userinfo();
> connectMessage.set_userinfo(2, stats.m_shipColor);
> // [3] => shipname
> connectMessage.add_userinfo();
> connectMessage.set_userinfo(3, stats.m_shipName);
>
It definitely allows for a cleaner .proto file, but it's strange that just
using individual strings was causing a problem.
On Friday, October 7, 2016 at 2:56:14 PM UTC-7, Chazix wrote:
>
> Hello,
>
> I have a message that looks like:
>
> message Connected {
>> sint32 xloc = 1; // x spawn world position
>> sint32 yloc = 2; // y spawn world position
>> sint32 zrot = 3; // z spawn rotation
>> string sector = 4; // sector name (unsure about this)
>> string name = 5; // player name
>> string pid= 6; // player id
>> string scolor = 7; // ship color
>> string sname = 8; // ship name
>> }
>
>
> I am attempting to initialize it within my c++ code like this:
>
>>
>> GameClientStats& stats = gameClient.GetGameClientStats();
>> server::player::Connected connectMessage; // send this to this joining
>> client
>> connectMessage.set_name(stats.m_clientName);
>> connectMessage.set_pid(stats.m_clientId);
>> connectMessage.set_scolor(stats.m_shipColor);
>> connectMessage.set_sname(stats.m_shipName);
>> connectMessage.set_xloc(stats.m_xPos);
>> connectMessage.set_yloc(stats.m_yPos);
>> connectMessage.set_zrot(stats.m_zRot);
>
>
> For some reason as I set my string parameters, the prior strings before it
> gets set to that string value. So, if I do the set_pid the name field will
> also change to the pid. set_scolor the name & pid will be set to the
> s_color. set_sname the name, pid & scolor will change to be the sname. It
> seems like they are all sharing the same string pointer field location.
>
> Am I not initializing my message correctly? Or do I need to do something
> differently here? When I Serialize my messages from a coded stream I get my
> expected message, but manual creation doesn't seem to be working with what
> I'm currently trying to do.
>
> Thank you very much for the information.
>
--
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.
Re: [protobuf] Re: Message with multiple strings problem
It seems to be reproducible for me, I'm not sure if any else has or is
encountering this problem however. I just got done creating a new message
and I encountered this same problem again. It only seems to be a problem
over on the c++ side.
message CreateNetObject {
> string pid = 1;
> string spid = 2;
> enum Type {
> UNKNOWN = 0;
> PLAYER_PROJECTILE = 1;
> }
> Type type = 3;
> float xloc = 4;
> float yloc = 5;
> sint32 zrot = 6;
> }
The strings overwrite each other when placing data into their associated
set_pid or set_spid fields.
On Monday, October 10, 2016 at 12:06:35 PM UTC-7, Adam Cozzette wrote:
>
> Is it possible that you renumbered some field numbers in your .proto file
> and so the code that serialized the message and the code that subsequently
> parsed it disagree on the field numbers? Or can you reproduce it within a
> single process without serialization and deserialization?
>
> On Sat, Oct 8, 2016 at 12:37 AM, Chazix <m11...@gmail.com >
> wrote:
>
>> Changing to use a repeated field for my strings seems to have fixed the
>> problem.
>>
>> message Connected {
>>> sint32 xloc = 1; // x spawn world position
>>> sint32 yloc = 2; // y spawn world position
>>> sint32 zrot = 3; // z spawn rotation
>>> // [0] => username
>>> // [1] => userid
>>> // [2] => shipcolor
>>> // [3] => shipname
>>> repeated string userinfo = 4;
>>> }
>>>
>>
>> With this I am able to manually add the new strings to the repeated
>> string list.
>>
>> server::player::Connected connectMessage;
>>> connectMessage.set_xloc(stats.m_xPos);
>>> connectMessage.set_yloc(stats.m_yPos);
>>> connectMessage.set_zrot(stats.m_zRot);
>>> // [0] => username
>>> connectMessage.add_userinfo();
>>> connectMessage.set_userinfo(0, stats.m_clientName);
>>> // [1] => userid
>>> connectMessage.add_userinfo();
>>> connectMessage.set_userinfo(1, stats.m_clientId);
>>> // [2] => shipcolor
>>> connectMessage.add_userinfo();
>>> connectMessage.set_userinfo(2, stats.m_shipColor);
>>> // [3] => shipname
>>> connectMessage.add_userinfo();
>>> connectMessage.set_userinfo(3, stats.m_shipName);
>>>
>>
>> It definitely allows for a cleaner .proto file, but it's strange that
>> just using individual strings was causing a problem.
>>
>>
>> On Friday, October 7, 2016 at 2:56:14 PM UTC-7, Chazix wrote:
>>>
>>> Hello,
>>>
>>> I have a message that looks like:
>>>
>>> message Connected {
>>>> sint32 xloc = 1; // x spawn world position
>>>> sint32 yloc = 2; // y spawn world position
>>>> sint32 zrot = 3; // z spawn rotation
>>>> string sector = 4; // sector name (unsure about this)
>>>> string name = 5; // player name
>>>> string pid= 6; // player id
>>>> string scolor = 7; // ship color
>>>> string sname = 8; // ship name
>>>> }
>>>
>>>
>>> I am attempting to initialize it within my c++ code like this:
>>>
>>>>
>>>> GameClientStats& stats = gameClient.GetGameClientStats();
>>>> server::player::Connected connectMessage; // send this to this joining
>>>> client
>>>> connectMessage.set_name(stats.m_clientName);
>>>> connectMessage.set_pid(stats.m_clientId);
>>>> connectMessage.set_scolor(stats.m_shipColor);
>>>> connectMessage.set_sname(stats.m_shipName);
>>>> connectMessage.set_xloc(stats.m_xPos);
>>>> connectMessage.set_yloc(stats.m_yPos);
>>>> connectMessage.set_zrot(stats.m_zRot);
>>>
>>>
>>> For some reason as I set my string parameters, the prior strings before
>>> it gets set to that string value. So, if I do the set_pid the name field
>>> will also change to the pid. set_scolor the name & pid will be set to the
>>> s_color. set_sname the name, pid & scolor will change to be the sname. It
>>> seems like they are all sharing the same string pointer field location.
>>>
>>> Am I not initializing my message correctly? Or do I need to do something
>>> differently here? When I Serialize my messages from a coded stream I get my
>>> expected message, but manual creation doesn't seem to be working with what
>>> I'm currently
Re: [protobuf] Re: Re-Parsing Received CodedMessages Over Network (Proto3)
Thank you for the suggestion to nix the +1 Adam, I should have heeded this
advice sooner - I just encountered the problem with a larger than 127 bytes
message not being re-parsed correctly once the server received the message
from my client.
On Monday, August 1, 2016 at 7:20:49 AM UTC-7, Adam Cozzette wrote:
>
> Great, I'm glad that worked. In your C# client I think what's going on is
> that you're calculating the size of the message but excluding the length
> prefix that comes before it, so the +1 is correcting for that. In general
> adding 1 will not work reliably, though, since the length prefix is
> varint-encoded and therefore has a variable-length encoding that will use
> more than one byte for messages 128 bytes and longer. I'm not familiar with
> C# at all but is there perhaps a way to just query the MemoryStream to ask
> how many bytes it has written? I see that there's a Position
> <https://msdn.microsoft.com/en-us/library/system.io.memorystream.position(v=vs.110).aspx>
>
> property that might do the trick.
>
> On Sat, Jul 30, 2016 at 5:33 PM, Chazix <m11...@gmail.com >
> wrote:
>
>> Thanks for the insight, that definitely does work for collecting my
>> message, and it seems to be more so a standard compared to what I was
>> doing, at least for my server side.
>>
>> On my C# client side, I still have to add + 1 to the
>> IMessage.CalculateSize() function when sending over my UdpClient object
>> unfortunately.
>>
>> public void DataToSend(IMessage message)
>>> {
>>> CodedOutputStream output = new CodedOutputStream(m_ostream.BaseStream,
>>> true);
>>> output.WriteMessage(message);
>>> output.Flush();
>>> (m_ostream.BaseStream as MemoryStream).SetLength(0); // reset stream
>>> for next packet(s)
>>> m_client.GetServerConnection().GetClient().Send(m_packet,
>>> message.CalculateSize() + 1);
>>> }
>>>
>>
>> On Friday, July 29, 2016 at 4:18:29 PM UTC-7, Adam Cozzette wrote:
>>>
>>> I believe the problem you're running into is on the server side; it
>>> looks like you're parsing the size correctly but just skipping over it.
>>> Since protocol buffers are not self-delimiting, you must actually rely on
>>> the size to know how many bytes to read. I think what's probably happening
>>> is that the CodedInputStream is reading past the end of your message and
>>> trying to interpret whatever the bytes are that happen to come after it.
>>> The way to solve this is to use CodedInputStream's PushLimit and
>>> PopLimit methods. In your example something like this should work:
>>>
>>> google::protobuf::io::CodedInputStream::Limit limit =
>>> inputStream.PushLimit(msgSize);
>>> if (!msg.ParseFromCodedStream() ||
>>> !inputStream.ConsumedEntireMessage()) {
>>> // handle error ...
>>> }
>>> inputStream.PopLimit(limit);
>>>
>>> Let me know if this fixes it.
>>>
>>> On Sat, Jul 23, 2016 at 3:51 PM, Chazix <m11...@gmail.com> wrote:
>>>
>>>> I'm continuing to fiddle with this problem. For some reason it seems
>>>> that I'm missing a byte count when sending from my client.
>>>>
>>>> m_client.GetServerConnection.GetClient().Send(m_packet,
>>>> message.CalculateSize() + 1) // I needed to add + 1
>>>>
>>>> I thought it was strange that my message was only being received as:
>>>> #\u0012!\n\u001Ftype.googleapis.com/server.Pin
>>>>
>>>> I'm not sure why I have to add + 1 tho and CalculateSize isn't giving
>>>> the correct size naturally.
>>>>
>>>>
>>>> On Saturday, July 23, 2016 at 2:56:08 PM UTC-7, Chazix wrote:
>>>>>
>>>>> I'm utilizing Protobuf3 with c# for my client & c++ for my server,
>>>>> where the .proto's are generated from the corresponding protoc3 compiler.
>>>>> I'm new to utilizing Google Protocol Buffers, where I'm currently trying
>>>>> to
>>>>> figure out how to re-parse the received bytes on my server that were sent
>>>>> from my client to turn it back into it's originating
>>>>> google::protobuf::Message object on my c++ server.
>>>>>
>>>>> My client is sending a CodedOutputStream in c# :
>>>>>
>>>>> public PacketHandler()
>>>>>> {
>>>>>> m_client = GetComponent();
>>>>>> m_packet =
