[AG-TECH] Listing Venue Server addresses
John I Quebedeaux Jr
johnq at lsu.edu
Fri Feb 16 14:38:30 CST 2007
I thought the other reason for keeping everything to just a few ports
(keep the range narrow) were for firewall reasons as well...
-John Q.
On Feb 16, 2007, at 1:51 PM, Derek Piper wrote:
>
> This is good stuff to talk about.
> If you only have 2 addresses though, wouldn't it be better to
> divide the 2 IPs between venues and keep the same IP within a venue
> since, like you said, all traffic goes to clients regardless of port?
>
> i.e.
> Scenario 1:
>
> Venue 1
> Audio: 233.100.100.1 / 20000
> Video: 233.100.100.1 / 20002
>
> Venue 2
> Audio: 233.100.100.2 / 30000
> Video: 233.100.100.2 / 30002
>
> Venue 3
> Audio: 233.100.100.1 / 40000
> Video: 233.100.100.1 / 40002
>
> Venue 4
> Audio: 233.100.100.2 / 50000
> Video: 233.100.100.2 / 50002
>
> is better than
> (Scenario 2)
>
> Venue 1
> Audio: 233.100.100.1 / 20000
> Video: 233.100.100.2 / 20002
>
> Venue 2
> Audio: 233.100.100.1 / 30000
> Video: 233.100.100.2 / 30002
>
> Venue 3
> Audio: 233.100.100.1 / 40000
> Video: 233.100.100.2 / 40002
>
> Venue 4
> Audio: 233.100.100.1 / 50000
> Video: 233.100.100.2 / 50002
>
> since clients connected to Venue 1 would ALSO receive data from all
> the other venues, even if it was filtered by port?
>
> So, if you have limited addresses then dividing them wholely
> between venues (i.e. NOT doing what you mentioned, Chris) would be
> the smarter configuration because if you have 2 meetings running
> simultaneously then you can support 2 separations, i.e. Venue 1 &
> 3, and Venue 2 & 4 with Scenario 1. With Scenario 2 because we
> spread our addresses over ALL the venues trying to have a different
> IP for audio and video if we have 2 meetings at once we're always
> going to be sending data to ALL participants over both meetings and
> using more bandwidth.
> Of course, if you have the addresses then it's smarter not to have
> any overlap, I agree. But, for static addressing when there may not
> be many addresses available then it is probably wiser to organize
> things so that simultaneous meetings are separated, not necessarily
> audio/video sources.
>
> Derek
>
> Thomas D. Uram wrote:
>> Chris makes a good point, one that I applied when assigning addresses
>> to the vv3/ivs servers. The simplifications I applied were to
>> have the
>> audio and video addresses be sequential, and have the ports always
>> the
>> same (20000 for audio, 20002 for video).
>> On 2/16/07 12:16 AM, Christoph Willing wrote:
>>>
>>> On 16/02/2007, at 3:16 AM, Derek Piper wrote:
>>>
>>> [snip]
>>>> While talking about the venue management tool it would be
>>>> nice to be able to restrict it to a single IP address for
>>>> multicast (and just let it dynamically assign ports). As it is,
>>>> the mask only allows for 0-31, where I need '32' in order to
>>>> lock it down as such. I was given two addresses but they do not
>>>> fit within one /31 CIDR range (of course :>).
>>>
>>>
>>> Derek,
>>>
>>> There may be problems for clients when using that strategy (using
>>> a single IP, but different ports for different venues) for
>>> bandwidth challenged clients. Even when they're only connected to
>>> a single venue, the traffic from all the other venues sharing the
>>> same IP address would flow to the client as well. A client can
>>> filter based on port number, but all other (unwanted) traffic on
>>> the same IP address has also arrived regardless of using a
>>> different port (only to be filtered out anyway). Using different
>>> multicast IP addresses means that only the requested streams flow
>>> to the client. In fact, we now configure our server to use
>>> different IP addresses for audio & video in the same venue.
>>>
>>>
>>> chris
>>>
>>>
>>>
>>> Christoph Willing +61 7 3365 8350
>>> QCIF Access Grid Manager
>>> University of Queensland
>>>
>>>
>>>
>>>
>
> --
> Derek Piper - dcpiper at indiana.edu - (812) 856 0111
> IRI 323, School of Informatics
> Indiana University, Bloomington, Indiana
>
More information about the ag-tech
mailing list