But then we'll have to keep extra information to translate what every
messageType means. That's just extra information.
Rather than sending an int32 and then figuring out what it translates to,
wouldn't it be better that we keep it string to increase readability?
On Fri, May 27, 2011 at 9:22 PM, Zhongjie Wang <[email protected]> wrote:
> nonono, your proposal in the previous email is quite right.
> It's better to use a int32 fields prior to the message. then we can know
> the message type after reading that tag field.
>
>
> On Sat, May 28, 2011 at 12:04 AM, Zubair Nabi <[email protected]>wrote:
>
>> Sounds good. Let's keep it a string. The type would be the name.
>>
>> Let's keep it optional. It will be used in p2p communication but not in
>> aggregator communication.
>> So this is the extra field that I propose:
>>
>> optional string messageType = x;
>>
>> Does everyone agree?
>>
>> Adriano - Do we have write access to the common ICM repository?
>>
>>
>> On Fri, May 27, 2011 at 8:59 PM, Zhongjie Wang <[email protected]> wrote:
>>
>>> Hi Zubair,
>>> That's a good way. I agree. :)
>>>
>>>
>>> On Fri, May 27, 2011 at 11:49 PM, Zubair Nabi
>>> <[email protected]>wrote:
>>>
>>>> That's a very good point. In case of p2p agents we will only be sending
>>>> messages using a standard send function. So, there is no way to tell the
>>>> message type. We should add an int32 for message type considering that we
>>>> have a standard number of messages.
>>>> If int32 messageType == 1 then that could an authentication message and
>>>> so on. What do you say?
>>>>
>>>>
>>>> On Fri, May 27, 2011 at 8:44 PM, Zhongjie Wang <[email protected]>wrote:
>>>>
>>>>> Hi Adriano,
>>>>>
>>>>> Sorry, I didn't see the email of that doc. Then it's perfect. :)
>>>>> There's one more question, how to detect the message type when I
>>>>> receive a message?
>>>>> Is there any field to indicate the type?
>>>>>
>>>>>
>>>>> On Fri, May 27, 2011 at 11:34 PM, Adriano Monteiro Marques <
>>>>> [email protected]> wrote:
>>>>>
>>>>>> Hi Alan,
>>>>>>
>>>>>> On May 27, 2011, at 12:30 PM, Zhongjie Wang wrote:
>>>>>>
>>>>>> > Hi Zubair, Diogo:
>>>>>> > I hope you guys could join and figure out the detailed message
>>>>>> format for the communication interfaces. :)
>>>>>> > In the spec, we have decided to use RESTful webservice and RPC call
>>>>>> for the communications. Now the
>>>>>> > form of RPC call is somewhat obscure, we need to make a clearly
>>>>>> defined message format. Do you think we
>>>>>> > should still use protobuf, or json/xml, or customized binary/text
>>>>>> format? This is important.
>>>>>>
>>>>>> We've already decided on using protobuf, right? Event the ones we
>>>>>> defined today and shared with you in that google doc.
>>>>>>
>>>>>> > At first, there should be an authentication process after
>>>>>> connected. Then we use the negotiated
>>>>>> > symmetric key to encrypt the following messages. The messages will
>>>>>> be in pair, like Request/Response.
>>>>>> > For a request, there should be a RPC function name and then the
>>>>>> parameters, finally maybe end with a checksum.
>>>>>> > And for a response, it will indicate which request it response to,
>>>>>> and then the result.
>>>>>> > If we use protobuf, then we need to put the function name out of
>>>>>> the message. So after the agent read the name,
>>>>>> > it will generate a proper class for the message.
>>>>>> >
>>>>>> > How do you think which one we should choose?
>>>>>> >
>>>>>> > Regards
>>>>>> >
>>>>>> > --
>>>>>> > Zhongjie Wang
>>>>>> > Master Candidate
>>>>>> > Computer System Architecture
>>>>>> > Peking University, China
>>>>>> >
>>>>>> ------------------------------------------------------------------------------
>>>>>> > vRanger cuts backup time in half-while increasing security.
>>>>>> > With the market-leading solution for virtual backup and recovery,
>>>>>> > you get blazing-fast, flexible, and affordable data protection.
>>>>>> > Download your free trial now.
>>>>>> >
>>>>>> http://p.sf.net/sfu/quest-d2dcopy1_______________________________________________
>>>>>> > Umit-devel mailing list
>>>>>> > [email protected]
>>>>>> > https://lists.sourceforge.net/lists/listinfo/umit-devel
>>>>>>
>>>>>> ---
>>>>>> Adriano Monteiro Marques
>>>>>>
>>>>>> http://www.thoughtspad.com
>>>>>> http://www.umitproject.org
>>>>>> http://blog.umitproject.org
>>>>>> http://www.pythonbenelux.org
>>>>>>
>>>>>> "Don't stay in bed, unless you can make money in bed." - George Burns
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Zhongjie Wang
>>>>> Master Candidate
>>>>> Computer System Architecture
>>>>> Peking University, China
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> vRanger cuts backup time in half-while increasing security.
>>>>> With the market-leading solution for virtual backup and recovery,
>>>>> you get blazing-fast, flexible, and affordable data protection.
>>>>> Download your free trial now.
>>>>> http://p.sf.net/sfu/quest-d2dcopy1
>>>>> _______________________________________________
>>>>> Umit-devel mailing list
>>>>> [email protected]
>>>>> https://lists.sourceforge.net/lists/listinfo/umit-devel
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Best,
>>>> __
>>>> Zubair
>>>>
>>>
>>>
>>>
>>> --
>>> Zhongjie Wang
>>> Master Candidate
>>> Computer System Architecture
>>> Peking University, China
>>>
>>
>>
>>
>> --
>> Best,
>> __
>> Zubair
>>
>
>
>
> --
> Zhongjie Wang
> Master Candidate
> Computer System Architecture
> Peking University, China
>
--
Best,
__
Zubair
------------------------------------------------------------------------------
vRanger cuts backup time in half-while increasing security.
With the market-leading solution for virtual backup and recovery,
you get blazing-fast, flexible, and affordable data protection.
Download your free trial now.
http://p.sf.net/sfu/quest-d2dcopy1
_______________________________________________
Umit-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/umit-devel
