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 - dcpi...@indiana.edu - (812) 856 0111
IRI 323, School of Informatics
Indiana University, Bloomington, Indiana
