[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [AG-TECH] Listing Venue Server addresses

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