Hi: I think there would have to be a way for a slave relay admin to be able to stipulate that their server was not to be used for balancing. A server being used to make a public stream available on a private network, for example, would be of no use to the balancing effort. Geoff. --- >8 ---- List archives: http://www.xiph.org/archives/ icecast project homepage: http://www.icecast.org/ To unsubscribe from this list, send a message to 'icecast-dev-request@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
> > What do you think? > This sounds like it could be useful for some users. Do you want to send usa> patch?yeah, I will work that out, I'll keep you posted. May take some time since I got some exams right now ;-) Is there a development documentation of icecast2? I am thinking of the internal structure, objects, files and conventions. Anything that might make it easier to get an overview and to find the locations to make the changes. But I think you (Mike) already answered that question too, right ;-) I'll figure that out, Enrico --- >8 ---- List archives: http://www.xiph.org/archives/ icecast project homepage: http://www.icecast.org/ To unsubscribe from this list, send a message to 'icecast-dev-request@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
> > One more detail about Icecast2 that I'd like to know is whether there isany> > load-balancing feature implemented or about to be implement? ... > I haven't heard or seen of this, nor do I think load balencing as you > describe it could be done seamlessly without modifying the media player.I made some tests and it turned out that Winamp, mpg123 and even MS Media Player are capable of handling HTTP-Location responses properly. Therefore it might be possible to implement an load balancing feature without having changes on client side. This is what I thought of: client requirements: - handling HTTP 302 response status together with HTTP-Location attribute properly erver requirements: - Slave - telling the Master how many clients are connected - Master - using Slave information to fulfill load balancing algortihm And this is how it works: Every Slave sends its load data (how many clients connected and the defined maximum of clients) to the Master (propably included in the master-update-interval procedure). Therefore, the Master knows which Slaves are connected and working, and which has the lowest load. The next client will be forwarded to this Slave using the HTTP 302 status together with a HTTP-Location attribute: --- HTTP/1.0 302 Found Location: http://SLAVEIP:SLAVEPORT/MOUNTPOINT --- Thus, the client is forwarded to a Slave and we got a centrally controlled load balancing. Advantages: - Slaves can be added dynamically without posting them in mirror-lists - Slaves will be used for load balancing instantly <p>What do you think? Enrico M. --- >8 ---- List archives: http://www.xiph.org/archives/ icecast project homepage: http://www.icecast.org/ To unsubscribe from this list, send a message to 'icecast-dev-request@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
On Tuesday 10 February 2004 23:47, Enrico Minack wrote:> I made some tests and it turned out that Winamp, mpg123 and even MS Media > Player are capable of handling HTTP-Location responses properly. Therefore > it might be possible to implement an load balancing feature without having > changes on client side. > > This is what I thought of: > > client requirements: > - handling HTTP 302 response status together with HTTP-Location attribute > properly > > server requirements: > - Slave - telling the Master how many clients are connected > - Master - using Slave information to fulfill load balancing algortihm > > > > What do you think? >This sounds like it could be useful for some users. Do you want to send us a patch? Mike --- >8 ---- List archives: http://www.xiph.org/archives/ icecast project homepage: http://www.icecast.org/ To unsubscribe from this list, send a message to 'icecast-dev-request@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
> > What do you think? > This sounds like it could be useful for some users. Do you want to send usa> patch?I created this patch that adds load balancing to the Master-Slave-Feature: http://www.maniac-site.de/download.php?user=maniacme2&file=icecast-2.0.0-loa dbalanced-0.9.2.diff.gz I'd be pleased if someone would test the patch and could tell me whether the pached version works on your machines. When <master-public-slave> in the configuration file is != 0, then the load balancing feature is active. Then all slaves provides their bandwidth to the clients via request to the one master. Therefore, users needn't to use yp services to find public mirrors. A newly connected slave will be available to the clients after one master-update-interval. <p>And this is what it does: - the master is aware of all slaves mirroring its sources - when a client requests a source the master randomly selects a slave (or itself) to serve the client - a 'weak' slave is less likely to be selected for serving the client than a 'strong' one - if a slave is selected, the master sends a 'HTTP/1.0 302 Temporarily Moved' and a 'Location: ...' value - an unlimited number of slaves for each source is possible <p>And this is how it works - the slave has a list of master sources in the global variable - each element of this list contains the name of a source mirrored from the master (since the slave can have its own additional sources) - when a new source from the master is added to the source tree the mount point is added to this list - when a source is removed from the source tree the mount point is removed from this list - this list is used by slave.c to create the sourcelist.txt which is posted to the master right before the streamlist.txt is requested from the master - the master parses the sourcelist.txt file and adds the slave data to each listed source - for this I extended the source_t structure with a list of slaves - each slave list element (slave_t) contains information about a slave mirroring this source (ip, port, current listeners, new listeners, timeout) - in connection.c this list is used to randomly select a slave and the client is forwarded to it - whether a slave timed-out is check when a client requests a source, right before the random selection starts - when an icecast server requests a source (as relay or slave) the master won't forward to a slave - the master uses the 'user-agent' attribute in the request of the client to determine whether the client is an icecast server <p>A load balanced slave is compatible with icecast server without the load balancing patch, and vice versa, but there will be no load balancing behaviour. <p>Enrico M. --- >8 ---- List archives: http://www.xiph.org/archives/ icecast project homepage: http://www.icecast.org/ To unsubscribe from this list, send a message to 'icecast-dev-request@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.