Hi Alan,
On Jun 9, 2011, at 3:01 AM, Zhongjie Wang wrote:
> Hi all,
>
> About the message format, I have some comments.
> 1. Seems there're duplicate fields in SendWebsiteReport and
> SendServiceReport:
> 162
> // send_report
> 163
> message SendWebsiteReport {
> 164
> required RequestHeader header = 1;
> 165
> required WebsiteReport report = 2;
> 166
> }
> In the RequestHeader structure to the aggregator, there're are token
> and agentID. And in WebsiteReport.ICMReport, there're also agentID. Though I
> didn't know the difference between token and agentID. I suggest we eliminate
> the agentID field in ICMReport.
Token is our to confirm to the aggregator that we are legitimate. On the
duplicated agentID, it is fine: If a node is passing a website report from
another node, then the ICMReport will show the agentID for the origin node, and
the RequestHeader will provide the passing agent's id.
> 2. Besides that, the optional fields: redirectLink, htmlResponse,
> htmlMedia, seems to be better in the WebsiteReportDetail structure, because
> it's more test specific. I suppose the Report messages should have only two
> parts, the header and the detail.
Check the Event message... when we send back a WebsiteReportDetail or
ServiceReportDetail we don't send out those details as they're not really
necessary.
> 3. Since we don't have a field in the message to identify the message
> type, I don't know how we can create a message instance after receiving a
> bunch of raw bytes. Currently I send the message type string before send the
> message itself. But I think the better solution is tag it in the message
> structure.
Even if we had a field in the message, how would we retrieve it to know the
type prior to instantiating it? What we're doing on the Aggregator side is to
presume the sort of message a given API is supposed to send/receive. Perhaps we
could do the same with the desktop agent, what do you think?
> 4. Another slightly modification, I suggest that we use float type for
> responseTime, the unit is seconds, for accuracy.
We're using miliseconds there as mentioned in a previous email, that's the
reason why we use integer. It saves on message size and keeps accuracy.
Well noticed Alan! Keep pushing! Let me know if there still is anything you
feel like it is wrong or that is stopping you from progressing.
Cheers!
>
> Best Regards.
> Alan
>
> On Sat, Jun 4, 2011 at 5:34 PM, Adriano Monteiro Marques
> <[email protected]> wrote:
> Right, mainly for nodes who stays connected for long periods of time. Also,
> if we want a test to be run ASAP, we need to send this info everytime so the
> node knows of a brand new test version, updates their test set and run them
> ASAP. On the software version, if we figure any security issue, the nodes
> will also update ASAP.
>
>
> On Jun 4, 2011, at 6:22 AM, Zubair Nabi wrote:
>
>> Hi,
>>
>> I think the idea was to keep the binary and test versions as fresh as
>> possible. This ResponseHeader would make sure of that.
>>
>> On Sat, Jun 4, 2011 at 4:04 AM, Diogo Pinheiro <[email protected]>
>> wrote:
>> Hi
>>
>> I have another question. Why the ResponseHeader has the currentVersionNo and
>> currentTestsVersion ? I think we shouldn't send that information all the
>> time. Just when the agent connect, and in a rpc call.
>>
>> What do you think ?
>>
>>
>>
>> --
>> 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
>
>
> ------------------------------------------------------------------------------
> Simplify data backup and recovery for your virtual environment with vRanger.
> Installation's a snap, and flexible recovery options mean your data is safe,
> secure and there when you need it. Discover what all the cheering's about.
> Get your free trial download today.
> http://p.sf.net/sfu/quest-dev2dev2
> _______________________________________________
> Umit-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/umit-devel
>
>
>
>
> --
> Zhongjie Wang
> Master Candidate
> Computer System Architecture
> Peking University, China
---
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
------------------------------------------------------------------------------
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
_______________________________________________
Umit-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/umit-devel
