[AG-TECH] 'Bridge' for venue services, etc.?
Randy Groves
randy.groves at boeing.com
Wed May 5 09:20:14 CDT 2004
The message may not have been as clear as I would have liked (an aside -
what is the contraction for 'I would have'? I'd've? I'dve?) - written in
pieces amidst many other things going on. And yes, I think that the
appropriate interpretation is not bridge but proxy. There are really two
separate concerns. The multicast issue will be with us as long as the
commodity Internet doesn't supply this as a matter of course. So making
sure, as much as possible, that the aspects of the AG that are truly
multicast (and I'm showing my ignorance here, but I'm assuming that this is
mainly the audio and video, right?) can be used over some sort of
unicast/multicast bridge.
The other issue is the addition of services. With our security conscious
world, and especially behind corporate firewalls, there is a definite
problem with additional ports. And there is even a growing concern with
the overloading of port 80, and the possiblility of problems with web
services. In one document, I think the AGEP about firewalls, there is a
statement that the venue client need not accept incoming packets on the
8000/2/4/6 ports, but there will be a loss of some of the collaborative
richness. I guess my concern is that there not be a proliferation of ports
that fit into this category. I haven't even started the process of
discussing breaching our official corporate firewall to allow AG sessions
between external and internal sites. I will have a significant problem
convincing the powers that be that the 8000/2/4/6 regime is acceptable, let
alone the fact that we will also have to bridge. (If this becomes an
acceptable tool, then it is feasible that Boeing might create its own
external bridge).
That is why the idea of a proxy for the potentially many ports.
Hope that clears up my previous note.
-randy
At 06:31 AM 5/5/2004, Ivan R. Judson wrote:
>There are multiple facets needed to answer your question; let me try to
>catch as many as I can. First let me try to break apart what you're asking
>about to see if I can capture it correctly. You're mentioning multicast and
>firewalls, and concerned about users who need to work around issues related
>to them. Additionally the use of 'Bridge' in your subject line is not a like
>we've ever used the word before, it's really a proxy, right?
>
>If these assumptions are correct, I can answer your questions pretty easily.
>
>--Ivan
>
> > -----Original Message-----
> > From: owner-ag-tech at mcs.anl.gov
> > [mailto:owner-ag-tech at mcs.anl.gov] On Behalf Of Randy Groves
> > Sent: Wednesday, May 05, 2004 8:25 AM
> > To: ag-tech at mcs.anl.gov
> > Subject: [AG-TECH] 'Bridge' for venue services, etc.?
> >
> > I'm looking into the future here, and wondering how many of
> > the new services that might be coming down the pike are going
> > to fit into the
> > 8000,2,4,6 port scheme of the Venue Server/Client as it is
> > presently designed. I know that on the top end of all this,
> > the fact that some of the participants are
> > multicast-challenged will mean that they just lose out on
> > some of the newest features. If the participants are
> > multicast-challenged and firewall-challenged (behind a
> > restrictive firewall, with a long process to go through
> > before changes can be made, long security justifications for
> > just opening up any port in the first place, etc.), I see
> > them potentially falling further and further behind.
> >
> > What is the priority, when design decisions are made, as to
> > what emphasis is placed on making sure that these situations
> > are dealt with?
> >
> > Is there a possibility of a venue service proxy in the future?
> >
> > -randy
> >
> >
> >
More information about the ag-tech
mailing list