[AG-DEV] AG3 Bridging

[Todd Zimmerman]

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
>>>>>>
>>>>>>
>>>>
>>>>
>>>
>>
>