On Tuesday 02 December 2003 01:23, Melanie wrote:> Hello, > > this is the first patch, it implements some basic multilevel fallback > handling logic, the time window and the no mount option. > > New options are possible within an <mount> section: > > <fallback-override>1</fallback-override> > > This will allow a source connecting to a mount point to steal the clients > from it's fallback mount. All clients of the fallback are transferred to > the pending queue of the newly connected source. > If the main source drops out, it's clients will, by means of > <fallback-mount>, be connected to the fallback source. With this turned on, > when the main source comes back online, the clients will be shifted back on > reconnect. Without it, the clients will keep listening to the fallback. > > <no-mount>1</no-mount>These two are the major ones - I think this is a great new feature. However, we're trying to stabilise for 2.0 in the very near future, so I think this is probably more suitable for 2.1 (Note: we're hoping that 2.1 won't be long after 2.0, so this shouldn't delay it TOO long). Obviously, this sort of thing changes the core server logic quite a bit. <p>>> <time-window>17:00-05:00</time-window>I'd like to see this bit split out from the rest - it's unrelated. That doesn't mean it won't be accepted, but we'd MUCH rather see patches for one feature at a time. Could you manage that? As with the other stuff, documentation is neccesary as well. <p>> Fallback and reconnect are handled in a multi-level fashion, where each> fallback may in turn have a fallback. Specifying a circle of fallbacks is > also possible, however, recovery will not go around the circle more than > once. There is really no point in doing that, but XML permits it and the > alternative to making it acceptable would have been to generate a config > parse error. I didn't really want to add such a showstopper. > > Recovery only scans downward to the first connected source, that is all > that's needed. By definition, no clients can be connected to lower level > sources, unless they connected directly, in which case it's ok not to pick > them up.This all seems sensible. We need to detect this sort of error at runtime anyway (not only when reading the config file), since the config can be modified through the admin interface at any time, so this way of handling it sounds good. 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.
On 2003.12.02 15:23 oddsock wrote:> maybe I'm missing something, but can't you implement this by just > specifying <max-listeners>0 at the <mount> level ? That would prevent > anyone from connecting directly to the stream, but would still allow > fallback transfers....If it works, fine.> Also, I'm not sure we need a config option for the "steal clients > back"..I think that should be the default behavior, as I cannot think of > a scenario where you'd want to fallback to a mount point and never bring > those clients back to the original mount point when it becomes available > again...The configuration file is complicated enough as is....IMHO, the config file ist not complicated at all. OTOH, there's an option only because a patch that would change the default behavior, that other people may depend on, whould have no chance to be accepted. Melanie --- >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 02 December 2003 20:43, Melanie wrote:> Hi, > > I've split it into three patches now and also made it fit to current CVS, > with, I believe, Karl's changes for the double free bug. > > Order for the patches is: > > icecast-multilevel-fallback.patch > icecast-timewindow.patch > icecast-yp-override.patch > > As for docs: How? What format? Any specific layout?Just follow the existing docs as a guide - they're just simple HTML. 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.
At 11:57 AM 12/2/2003 +1100, you wrote:>On Tuesday 02 December 2003 01:23, Melanie wrote: > > Hello, > > > > this is the first patch, it implements some basic multilevel fallback > > handling logic, the time window and the no mount option. > > > > New options are possible within an <mount> section: > > > > <fallback-override>1</fallback-override> > > > > This will allow a source connecting to a mount point to steal the clients > > from it's fallback mount. All clients of the fallback are transferred to > > the pending queue of the newly connected source. > > If the main source drops out, it's clients will, by means of > > <fallback-mount>, be connected to the fallback source. With this turned on, > > when the main source comes back online, the clients will be shifted back on > > reconnect. Without it, the clients will keep listening to the fallback. > > > > <no-mount>1</no-mount> > >These two are the major ones - I think this is a great new feature. However, >we're trying to stabilise for 2.0 in the very near future, so I think this is >probably more suitable for 2.1 (Note: we're hoping that 2.1 won't be long >after 2.0, so this shouldn't delay it TOO long). Obviously, this sort of >thing changes the core server logic quite a bit.maybe I'm missing something, but can't you implement this by just specifying <max-listeners>0 at the <mount> level ? That would prevent anyone from connecting directly to the stream, but would still allow fallback transfers.... Also, I'm not sure we need a config option for the "steal clients back"..I think that should be the default behavior, as I cannot think of a scenario where you'd want to fallback to a mount point and never bring those clients back to the original mount point when it becomes available again...The configuration file is complicated enough as is.... oddsock --- >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.
Hi, I've split it into three patches now and also made it fit to current CVS, with, I believe, Karl's changes for the double free bug. Order for the patches is: icecast-multilevel-fallback.patch icecast-timewindow.patch icecast-yp-override.patch As for docs: How? What format? Any specific layout? Melanie -------------- next part -------------- A non-text attachment was scrubbed... Name: icecast-yp-override.patch Type: text/x-patch Size: 11908 bytes Desc: icecast-yp-override.patch Url : http://lists.xiph.org/pipermail/icecast-dev/attachments/20031202/3c9f6945/icecast-yp-override.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: icecast-multilevel-fallback.patch Type: text/x-patch Size: 8655 bytes Desc: icecast-multilevel-fallback.patch Url : http://lists.xiph.org/pipermail/icecast-dev/attachments/20031202/3c9f6945/icecast-multilevel-fallback.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: icecast-timewindow.patch Type: text/x-patch Size: 6661 bytes Desc: icecast-timewindow.patch Url : http://lists.xiph.org/pipermail/icecast-dev/attachments/20031202/3c9f6945/icecast-timewindow.bin
On Tuesday 02 December 2003 20:43, Melanie wrote:> Hi, > > I've split it into three patches now and also made it fit to current CVS, > with, I believe, Karl's changes for the double free bug. > > Order for the patches is: > > icecast-multilevel-fallback.patch > icecast-timewindow.patch > icecast-yp-override.patch > > As for docs: How? What format? Any specific layout? > > MelanieMelanie, Since we've now (finally!) got 2.0 out the door, I'm now coming back to these patches - hoping to actually get the functionality incorporated. I've got a few questions, though: 1) Documentation: did you ever manage to write any? The options you added are fairly straightforward for the most part, so this shouldn't be too hard. 2) The 'no-mount' option: why? Does this have any effect at all that isn't handled by setting max-listeners to zero? 3) In the multilevel fallbacks patch, you've added a comment saying "Likely safe to do since there can only be one thread, ever", along with some static local variables, in the source_find_mount() function. I'm not sure why you said this, it's clearly incorrect: the source_* functions are called from many different threads, and this is clearly not safe. This is easily fixed, though, by passing the neccesary variables recursively, and splitting the function into two. I'll probably have more questions once I read the other two patches in detail. Thanks again for your contributions, Mike <p>--- >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.