Hi Adriano,
No. I was having issues adding the common repository to the mobile
repository as submodule but Luis and Rodolfo helped me solve that problem.
A couple of messages were missing from the .proto. I added them.
Now I'll add the optional messageType field for p2p messages.
On Fri, May 27, 2011 at 10:55 PM, Adriano Monteiro Marques <
[email protected]> wrote:
> Hi Zubair,
>
> You have write perms there already... are you having any issues with that
> repo?
>
> On May 27, 2011, at 1:04 PM, Zubair Nabi 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
>
>
> ---
> 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
>
>
--
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
