[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