Thanks Max for your feedback.
From: m...@miragroupware.org
Date: Fri, 24 Jun 2011 10:46:34 +0100
To: mira-development@lists.sourceforge.net
Subject: Re: [Mira-development] GPB and n/w transfer protocol
Hi Shilpa,
Option 3 looks like a good choice to me. It replicates the structure of the
mainstream network protocols.
In IPv4, the header includes a 'total length' field which defines the total
size of both the header and the message. With regard to Mira's network
protocol, do you think it would be better for the length stated in the header
to be the total size, rather than just the size of the message? This would
allow us to extend the scope of the header (by, for example, including
checksums of the header and the message in a new 'checksum' field in the
header) without difficulty at a later date. Just a thought.
I belive IP4 header has two length fields. 4-bit header length and 16-bit
total length. IP4 has variable-length header, so it need both header and total
length
of IP datagram to calculate where actually the data protion starts. In mira we
have 16-bit fixed-length header and only information header has is the length
of the data/message. To keep it simple I am first, just sending header and then
I am sending the message.That way receiver know how may bytes to read from the
stream. It is little inefficient but can be a good start to encarporate GPB.
Also, I'd be very interested to see the messages using GPB that you've already
implemented. Are you going to set up a new branch for this on Launchpad?
I am on vacation for whole month of July. I will try to upload the code to
separate branch before I leave.
Best regards,
Max
Thanks,
Shilpa Sodani.
On 24 Jun 2011, at 07:51, Shilpa Sodani wrote:
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
------------------------------------------------------------------------------
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
------------------------------------------------------------------------------
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
_______________________________________________
Mira-development mailing list
Mira-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mira-development
