Hello all,
Here is my progress regarding protocol buffer and network messages:
-- I have represented network messages in terms of GPB(Google Protocol
Buffer) messages instead of plain strings.
I have followed the same design I send earlier to the mailing list. If
you have any concerns/questions about the
design please let me know.
-- Even though we represents the n/w messages in terms of GPB but while
transferring them over the net, we transfer them as a stream.
One of the issues was, given a stream of bytes how do we separate the
n/w messages from one another. In other words,
how does the other side know how many bytes it is supposed to read
before it can actually decode that network message
into GPB. I think this could be solved three ways:
1. Make all messages have the same length. In this case reader only
need to read exact numbers of bytes.
2. Append a marker to each message that will indicate where the message
ends,
therefore signaling the reader when to stop reading.
3. Before transmitting the actual message, send a header that only has
length of the message.
In this case reader will first read this header, which will tell it
how many more bytes to read before it gets
to the end of the message.
In our case the option 1 will not work as we have variable length messages.
The current n/w transfer protocol works on Option 2.
We are using '\n' to separate messages. The GPB encoded data has lots of
'\n'. '\n' would also have caused problem with binary
data. So option 2 is not a option for us.
IMHO option 3 works best for us.
I have coded new network transfer protocol that works on option 3.
I have made lots of changes to existing code to en-corporate GPB and new
network transfer protocol still trying to keep the
network API's same as much as possible so that I don't end up breaking the
existing code.
I have coded couple of message using GPB. I coming week I plan to code all
the remaining messages.
Thanks,
Shilpa Sodani.
> From: aalva...@aliensoft.net
> Date: Tue, 7 Jun 2011 18:41:22 -0400
> To: mira-development@lists.sourceforge.net
> Subject: Re: [Mira-development] Protocol Buffer
>
> Hello Shilpa,
>
> Not really. Those changes need to be made. The main reason for
> using GPB is to get rid of the restrictions in those functions.
>
> --
> regards,
>
> Alan Alvarez
>
> ------------------------------------------------------------------------------
> EditLive Enterprise is the world's most technically advanced content
> authoring tool. Experience the power of Track Changes, Inline Image
> Editing and ensure content is compliant with Accessibility Checking.
> http://p.sf.net/sfu/ephox-dev2dev
> _______________________________________________
> Mira-development mailing list
> Mira-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mira-development
> ------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense..
http://p.sf.net/sfu/splunk-d2d-c1
_______________________________________________
Mira-development mailing list
Mira-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mira-development
