On 10/04/2007, at 5:38 AM, Derek Piper wrote:
I'm having a (possibly) similar problem with a participant in Tokyo, Japan. I'm not sure of the way that bridges are chosen, but it seems that from this participant's location, no bridges are available at all. I'm not sure if it's firewalling or what that might prevent even the LIST of bridges appearing, or what it is.
At present, all AG3 bridges are "advertised" via a single bridge registry (at ANL) and collected into the VenueClient's bridge list when it starts up. If the bridge registry is not contactable, for whatever reason, at startup then the VenueClient will have an empty bridge list. Often, restarting the VenueClient will result in a usable bridge list - it depends on why the registry wasn't contactable; it could be that the registry was down, or maybe a local network problem. As long as the bridge registry isn't contactable, there'll be an empty bridge list.
AG3.1 (real soon now) caches bridge lists so that the cached version can be used when the bridge registry is not reachable at start up. It also has an update facility i.e. update bridge list while VenueClient is running.
The AG2 bridge mechanism is quite different - for a particular venue, a site somehwere must be running a bridge server which explicitly targets that particular venue in its configuration file (AG3 bridges bridge all venues).
chris
Jimmy Miklavcic wrote:
I'm working with Kansas University Medical Center to get a small Access Grid node running. They most certainly don't have multicast available on their campus so we are stuck with unicast. They have a "very" stringent security policy and I'm forced to narrow down the number of bridges that they will allow through their fire wall.
So the question is, if I give them a list of ten bridges, what are the chances that one or two of them will be listed in the bridge registry? Should they increase their bridge locator function from 10 to say 20 to increase their chances of seeing any of the ten? Also, if a bridge is not listed in the registry, does it mean that it is not available?
-- Jimmy Miklavcic
Multimedia Specialist
UNIVERSITY OF UTAH
CTR FOR HIGH PERFORM COMPUTING
155 SOUTH 1452 EAST RM 405
SALT LAKE CITY, UT 84112-0190
Office: 801.585.9335
Fax: 801.585.5366
--
IRI 323, School of Informatics
Indiana University, Bloomington, Indiana
Christoph Willing +61 7 3365 8350
QCIF Access Grid Manager
University of Queensland