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