[AG-DEV] AG3 Bridging - More Info

[Thomas D. Uram]

Yep, you figured it out.  Precisely, even, rather than roughly.

Clearly, the choice of which bridge registry to use needs to appear in
the venue client preferences.  We'll also have to work out how to allow
use of multiple registries, simultaneously or alternately.

Tom


On 3/17/06 1:32 PM, Todd Zimmerman wrote:
> So it appears I have a private bridge network running on my test VenueServer.  Here's how I did it -
> comments on whether this is valid or not would be great.
> 
> I created a webpage that had a single entry for my RegistryPeer list on it
> (http://www.westgrid.ca/collabvis/peers.txt)
> 
> I ran RegistryPeer.py from the venueserver box (although I assume it could run anywhere) with a -u
> http://www.westgrid.ca/collabvis/peers.txt
> 
> Then I ran a bridge: Bridge -p 8040 -n WestGrid -l Vancouver -u
> http://www.westgrid.ca/collabvis/peers.txt
> 
> Then I started edited by .AccessGrid3/Config/Preferences and edited the following line to:
> bridgeRegistry = http://www.westgrid.ca/collabvis/peers.txt
> 
> Started my venueclient - and voila... bridged venueserver.
> 
> Is this roughly the proceedure?
> 
> Thanks!
> 
> Todd
> 
> Todd Zimmerman wrote:
>> Agreed - this is very important in the WestGrid world.  This is an interesting implementation -
>> solves many of the current issues with lack of bridges on some venues etc.  This would nicely
>> guarantee a bridge on every venue.
>>
>> A couple of questions.  First, with all the current discussion about static unicast ports etc for
>> firewalls, how do you see the new implementation fitting with this model?  First glance it seems to
>> exacerbate the issue by introducing bridges outside of the control/domain of the venueserver
>> administrator.  I suppose support for client request of a certain destination port could be
>> introduced; however I'm not sure this would work ultimately or not.
>>
>> Second, how does one get their venueserver listed with the registry?? Or better how does one set up
>> their your own registry?? (I know, I know... Sorry for all the questions - your busy!! ;-) )
>>
>> Just trying to get a sense of what I'm gonna need to do to to replicate the existing AG2.x setup
>> here at WestGrid.
>>
>> Anyway - thanks for the insight!
>>
>> Todd
>>
>>
>>
>> Thomas D. Uram wrote:
>>> Ok, I'll be sure to include details about how to do this in my write-up.
>>>
>>> On 3/17/06 9:45 AM, Andrew Patrick wrote:
>>>> Supporting private bridges will be crucial for adoption of AG 3 around
>>>> here, since AG 2 is currently used mostly within private venue servers
>>>> and bridges.
>>>>
>>>>
>>>> Thomas D. Uram wrote:
>>>>> Okay.  I only wanted to write up the document to provide additional
>>>>> detail about
>>>>> what it's doing and how it works overall.  Here's how you start it:
>>>>>
>>>>> Bridge3.py -p <port> -n <name> -l <location> -u
>>>>> http://www.accessgrid.org/registry/peers.txt
>>>>>
>>>>> There are other options too, which you can see with Bridge3.py -h .
>>>>>
>>>>> The port is an incoming tcp port for outside communication with the
>>>>> bridge. The name and
>>>>> location are as they have been previously.
>>>>>
>>>>> The way bridging works with AG3 is this:
>>>>>
>>>>> - There's a registry for bridges.  Bridges register with the
>>>>> registry, and clients ask the registry
>>>>> for bridges; the registry cleans up its bridge list occasionally, so
>>>>> it should only give working
>>>>> bridges to clients when they ask.
>>>>>
>>>>> - Clients make some network calls against the bridges they retrieve
>>>>> from the registry to
>>>>> determine which is closest.  Then the client tells the bridge which
>>>>> multicast addresses
>>>>> it needs bridged, and the bridge returns unicast addresses.
>>>>>
>>>>> - There is currently only a single registry.  We want to add others
>>>>> and have them share
>>>>> p2p-style the bridge information, creating a widely-distributed
>>>>> registry network for
>>>>> bridges, but we're not there yet.
>>>>>
>>>>> - This implies a _single_ network of bridges/registries.  It will be
>>>>> possible in 3.0, though not
>>>>> obvious, to create a separate, private network of bridges, since some
>>>>> communities might
>>>>> want to provide bridges to only their users.
>>>>>
>>>>> - We will later add some metadata for smartening up bridge choices,
>>>>> such as cpu usage,
>>>>> network bandwidth, etc. to improve bridge selection, and some means
>>>>> of identification
>>>>> to provide bridge access control.
>>>>>
>>>>> If you've read this far and have any comments on the design and
>>>>> plans, I'd be happy to hear
>>>>> them.  I'm always willing to listen to the thoughts of smart people.
>>>>>
>>>>> Tom
>>>>>
>>>>>
>>>>> On 3/16/06 6:37 PM, Todd Zimmerman wrote:
>>>>>> Any hints would be appreciated... ;-) Don't need much - just a push
>>>>>> in the right direction.
>>>>>>
>>>>>> Thanks!
>>>>>>
>>>>>> Todd
>>>>>>
>>>>>> Thomas D. Uram wrote:
>>>>>>> Not yet, but it's on my short list to write one.
>>>>>>>
>>>>>>> On 3/16/06 4:24 PM, Todd Zimmerman wrote:
>>>>>>>> Hey all,
>>>>>>>>
>>>>>>>> Saw a questions posted a while ago concerning bridging on AG3 and
>>>>>>>> didn't see a response.  Is there a
>>>>>>>> brief howto around for how to run a bridge to an AG3 server?
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>>
>>>>>>>> Todd
>>>>>>>>
>>>>>>>>
> 
>