[icecast-dev] icecast2 ogg vorbis client request headers
msmith at xiph.org
Sun Apr 4 20:33:20 PDT 2004
On Monday 05 April 2004 13:04, oddsock wrote:
> At 07:41 PM 4/4/2004, you wrote:
> >That was your plan.
> >My plan is to provide what currently exists (htpasswd-like) and a 'script'
> >authenticator which just calls an external program, as Geoff described.
> >Both are, of course, possible. Your "URL call" (this is a very strange way
> > to describe it, by the way - I assume you mean "HTTP connection")
> > approach is much more complex to implement well, though, without
> > obviously being more powerful.
> invoking a URL is what I mean, I call it "URL Call" you call it HTTP
> connection, it's the same thing...as you well know.
Yes. Your meaning was clear, but it's very unconventional (and inaccurate,
technically - which matters later on when we document it, though not so much
> and considering the way many broadcasters have implemented authentication
> (and I know more than a few that have, and they ALL have done it via a "URL
> call" type method), I would say this method is more conventional than the
> "invoke a script" type method. And if you ask me, having icecast fork and
> exec a script to do listener authentication is not going to scale too well
> (I hope you don't plan to fork/exec for every listener connection). AND we
> already have the infrastructure for making URL calls (the YP code has to do
I'm not entirely sure of the performance implications on win32 - I'm told
it'll be substantially slower than on unix systems, but whether this matters
or not I'm not sure. Certainly, on a typical unix system, this approach (fork
and exec some program for each and every listener connection) will
drastically out-perform an HTTP request for simple cases (i.e. if, in both
cases, the actual authentication logic is simple/quick). The simple/naive
implementation will definately scale acceptably well on unix systems.
For this sort of thing, most implementations probably won't be simple/quick,
so the difference will likely end up in the noise (if the HTTP request is on
a local network, at least). Persistent HTTP connections (for which we don't
have the infrastructure currently) help this a lot - but similarly, given
more effort, the script approach could use a persistent "authentication
daemon". You can get sufficient performance either way if you really need it.
This approach also lets you get the http-request approach 'for free' - you
just provide a script that does an HTTP request to some URL and returns the
> But obviously I would not be against implementing a script-based
> authenticator, although this is pretty useless for most Win32 users (yes
> there are a bunch of those out there) as most Win32 users don't generally
> script things...
The only reason this would be 'useless for most win32 users' is if the
overhead of running an executable for every request is too high on that OS. I
don't know whether it is. Remember, even if we call it a "script
authentication module", there's nothing to force it to be in any sort of
actual "scripting language".
--- >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 at xiph.org'
containing only the word 'unsubscribe' in the body. No subject is needed.
Unsubscribe messages sent to the list will be ignored/filtered.
More information about the Icecast-dev