[icecast-dev] icecast2 ogg vorbis client request headers

[Michael Smith]

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 
now) teminology. 

>
> 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
> it).

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 
appropriate value. 

<p><p><p>>
> 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". 

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 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.