AG3 has has made it simpler for us manage our rooms at CCLRC (both RAL & Daresbury); most notably with the ability to 'lock' a system into using Unicast. I openly, the following is based on my perception of how AG3 works; and may not be entirely correct.
Last week, it became apparent that the MO for the way AG3 selects a bridge was working against us. It would appear that now anyone can create a bridge which AG3 will find and select dependent on the time it takes to ping. This may not however be the best selection method for a site. Like probably many other sites, we have strict firewall rules & guidelines to which we must adhere, and changes require time to be processed by 'other departments. We have therefore selected 5 'known' bridges around the globe that we expect to use regularly, or as fallbacks, and only these pass through unhindered. AG3 selects the 'closest' bridge it finds to route through currently. Last week on at least one occasion, the bridge list could not be seen from our sites, so there was no bridge at all available to our AG3 systems and we had to revert back to AG2.4 until later in the day. I would like to suggest an enhancement to the current system (if Unicast is selected), where the client operation would: 1. Check for bridges against a saved list, and either works from the new list (if available) or the saved one. 2. Compares the 'current' list to a list (perhaps tagged in preferences?) of preferred bridges, and tries to connect to the #1 preferred location. 3. If preference #1 fails or is not on the new list, then #2 is selected (and so on in a cascade fashion) 4. Perhaps this concept could also be adopted in the event of a heartbeat failure' from the bridge, so the client would automatically drop down to the next bridge, instead of just flagging up a failure. I know the purists will say that Unicast is a fallback to Multicast, but to some sites like ours it is our mainstay, and will continue to be for the foreseeable future. To us, the most important thing is for the meeting to take place with minimum of fuss & interruption; in some cases self operated by 'less knowledgeable people. I feel this would make the system simpler to manage & operate. Does this make sense? Would it be difficult to implement? Can anyone else see flaws? Regards, Paul Bonnett Access Grid Videoconference Support & Development Rutherford Appleton Laboratories e-Science Centre R1 Room 2.21 Chilton, Didcot, Oxfordshire, OX11 0QX Tel: 01235 778329 p.bonn...@rl.ac.uk<mailto:p.bonn...@rl.ac.uk> http://www.e-science.clrc.ac.uk/web/projects/accessgrid<http://hpcsg.esc.rl.ac.uk/>
