QuickBridge for AG 2.0

[Thomas Uram]

  Hi Stephen:

Sorry it took me longer than expected to respond.  We've been entrenched 
in AG2 development, and this topic needed some thought before I could 
respond.  See the responses to your questions below.

As for developing the QuickBridge service, you could start by looking at 
the services that exist in the repository, e.g. AudioService and 
VideoProducerService.  These examples do most of their work by 
overriding the Start method to actually start rat/vic.  In the case of 
the QuickBridge service, the Start method would probably just set the 
"started" flag.  The bulk of the work would be done in a method 
"Bridge", which would accept a list of multicast addresses/ports, 
allocate a port and start a bridge for each one, and return a list of 
(unicast) addresses/ports.  The pids of the quickbridge processes need 
to be stored, so the Stop method can kill them.

This should give you a basic impression of how the quickbridge service 
will look.  There are other issues that will have to be dealt with, like 
what to do with bridged users when the user running the bridge leaves 
the venue, but we can talk about that later.  Meanwhile, let me know if 
you have questions.

Tom


S.Booth wrote:

>OK I think I'm prepared to take on ownership of this. 
>I have had a quick look at the CVS repository. There does not seem to be a
>bridging service there just yet but I get the basic idea from looking at
>the others. 
>
>There are a number of things I want to do with the QB code and I'm
>keen that we end up with something that does what AG2.0 wants.
>I guess the rest of this email is really qestions for Tom.
>
>Who is authorised to request that an AG node starts a bridge and who
>is authorised to use that bridge once it is started?
>How integrated will the bridge service be with the web interface.
>
Nodes will maintain a list of administrators and an access policy. 
 Administrators can control who has access to the bridge service through 
the access policy.  Node operators can grant access to users in the venue.

The authorization model for AG2 is still in development.  The alpha will 
support very limited access control and, therefore, might be disabled by 
default.  This means that users in the venue would have access to the 
bridge service.

>At the moment QB detects unicast clients by detecting the RTCP control
>packets from vic/rat and sends a unicast data-stream to each IP
>address it has seen packets from. Would it be better to have the AG
>service manage the list of clients.
>
If access to the bridge is controlled by the AG software, we may not 
need to manage a list of clients of the quickbridge service.  

>Do we want to have Send-only(cameras) Recv-only(Display) and
>Send-recv(audio) forwarding. This would save bandwidth and is fairly
>easy to do especially if the AG service is managing the client-list or
>I could have seperate unicast ports for the different modes of operation.
>
For now, integrating the current QuickBridge functionality into the 
AccessGrid will be a big win.  

There are probably improvements that could be made in bridging.  Ivan 
has been looking at UMTP (e.g., live.com), thinking this might be a good 
direction to head in the future.  We should look at these for beyond 
AG2.0.  

>Do we want the option to use a single bridge to forward both the video
>and audio streams (I think this would perform better than trying to
>run 2 QB processes on a single CPU).
>
Might be better in the long run, but we could start by just wrapping the 
existing QuickBridge functionality as an AG node service.

>Do you want to support decryption/re-encryption in the bridge. 
>
I don't see that this functionality would be required, so we probably 
don't need to deal with it now.  In what circumstances do you think this 
would be useful?

>Do we want bandwidth limitation in the bridge.
>
Eventually, I think we would.



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/ag-dev/attachments/20030130/253e12e2/attachment.htm>