Subject: C432 JGSI Review Resent-Date: Thu, 30 Sep 1999 23:18:54 -0400 Resent-From: Geoffrey Fox Resent-To: p_gcf@npac.syr.edu Date: Sun, 19 Sep 1999 21:02:37 +0100 (BST) From: Omer F Rana To: gcf@npac.syr.edu (Geoffrey Fox) C432: A Mobile Agent Based Push Methodology for Global Parallel Computing a) Overall Recommendation ====================== This paper is not very well written, though the idea is interesting. There is a big background section, but the details on the actual system are rather sketchy. b) Words suitable for authors ========================== 1. The `true' benefits of TRAVELLER are not clear -- if you are using a shared memory idea, why is this more interesting than other approaches such as JINI? 2. On page 2, last paragraph (section 1), you mention that Java relies on a `high performance' execution model? I thought one of the limitations of Java was its execution performance. I am not sure what you mean by this. 3. page 4, section 2.1, paragraph 4, http to HTTP 4. page 4, last paragraph, section 2.1, insert `to be' between demonstrated and simple (4th line from end of page). 5. page 4, last line, I am not sure what is meant by `... approach will activate the tasks' 6. I do not agree with second line on page 6. Voyager, Aglets etc all enable the creation of multithreaded agents. 7. Section 3.1, page 7, last line of paragraph 1, mentions that `Brokers are organised in a hierarchical way', but it does not mention how this is achieved. Agent naming is a big problem, and the paper does not clarify how this is achieved in this particular system. Details about what the broker does, how it compares server statistics, does load balancing etc are not clear. 8. I am not clear why a complete AgentTask is sent to the broker first. Does this not make the broker a bottleneck. In figure (1) on page 7, this is illustrated but not commented upon in the text. Why not just send an AgentTask reference to the broker instead? 9. Last 2 lines on page 7 identify that there is no standard way of characterising workload, however, the authors do not identify how they do it in their work. How does the broker make a decision about where to place an AgentTask? 10. page 9, section 4.1, second last line: change `the' to `this' `reasons' to reason 11. On page 10, the migration of an AgentTask is identified, but what happens to the data associated with this operation? Data migration is not mentioned or clearly identified. Does the broker keep a track of where the data is also, when new servers are identified and AgentTask needs to be migrated? Similarly, the overheads of achieving the actual migration are not commented upon. 12. Figure (2) on page 10 does not agree with text immediately following the figure. The numbers on the figure do not agree with what is described in the text. 13. page 10, last line, change: `plase be refered to' to `can be found in' 14. page 11, 3rd paragraph, last line, change: `invalidationand' to `invalidation and' 15. page 11, first bullet point: `addressing' to `address' `... threads which dynamically spawned on demands' to `... threads which are dynamically spawned on demand' 16. page 11, third bullet point: `help' to `helps' 17. page 12, section 5.1, incorrect type-writer font for second character (AgentTask) 18. page 12, in code segment the `grain' parameter is briefly described as identifying the `granularity of coherence for data replication'. I am not sure what this means. Perhaps, an example to illustrate what you mean by this would be useful? 19. page 13, first line, how does the broker identify how many threads to create? This is not clear from the code sample provided immediately below this. Perhaps, need more text to explain the code? 20. page 14, second paragraph, delete one `on' 21. page 14, figure 4, y-axis label is skewed 22. page 15, third line, what do you mean by a `submission'? Is this a single AgentTask or multiple ones? 23. page 15, section 6.2, 3rd paragraph, last line -- not clear what is meant by this. How does the DSA's caching influence performance exactly? 24. The examination of costs is divied into either RMI serialization (for complex objects) or DSA, can you think of other overheads? What about migrating an AgentTask and its associated data? Are there any management decisions that need to made for this other than RMI based ones? 25. page 17, I do not see the method proposed here as `novel'. There is no mention of the `Contract Net' or other such protocols that have been used for load balancing. There is a great deal of work in this area in network management literature, you may be interested in exploring this further. A good reference is: http://www.irisa.fr/solidor/work/astrolog.html You can find papers on the Contract Net and extensions at: http://www.cs.wustl.edu/~mas/publications.html additional papers are at: http://www.cs.umbc.edu/agents/papers/ http://www.cs.cf.ac.uk/User/O.F.Rana/agents99/ c) Words for Prof. Fox =================== There are 5.5 pages of introduction -- perhaps this should be reduced? The TRAVELLER system should be described in more detail. The application examples should perhaps be extended to describe what TRAVELLER is doing in these instances.