[icecast-dev] icecast2 ogg vorbis client request headers

[Dave St John]

>but rather that I think it would be in the best interest of
>everyone if both methods (script and HTTP request) are implemented.
I completely agree on this, as it gives icecast2 much more flexibility and
options to choose from.

<p><p>Dave St John
Mediacast1 Administration

Need Support ?
http://mediacast1.com/helpdesk
----- Original Message ----- 
From: "oddsock" <oddsock at oddsock.org>
To: <icecast-dev at xiph.org>
Sent: Sunday, April 04, 2004 10:07 PM
Subject: Re: [icecast-dev] icecast2 ogg vorbis client request headers

<p>> At 10:33 PM 4/4/2004, you wrote:
>
> >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.
>
> quick and dirty I ran the following 2 programs :
>
/***************************************************************************
**/
> #include <stdio.h>
> #include <curl/curl.h>
>
> int main(void)
> {
>          CURL *curl;
>          CURLcode res;
>          int i = 0;
>          curl = curl_easy_init();
>          if(curl) {
>                  curl_easy_setopt(curl, CURLOPT_URL,
> "http://localhost:8500/test.html");
>                  for (i=0;i<1000;i++) {
>                          res = curl_easy_perform(curl);
>                          if (res != 0) {
>                                  fprintf(stderr, "Curl failed: %d\n",
res);
>                          }
>                  }
>                  /* always cleanup */
>                  curl_easy_cleanup(curl);
>          }
>          return 0;
> }
> /*************************************************************************
****/
>
>
/***************************************************************************
**/
> #include <stdio.h>
>
> int main() {
>          int i = 0;
>          for (i=0;i<1000;i++) {
>                  system("ls > /dev/null");
>          }
> }
>
/***************************************************************************
**/
>
> and got the following results :
>
> /usr/home/oddsock/tmp-> time forkit > /dev/null
>      5.13s real     1.82s user     3.27s system
> /usr/home/oddsock/tmp-> time curlit > /dev/null
>      0.76s real     0.14s user     0.18s system
>
> so as far as performance goes, the HTTP request seemed to outperform in
the
> simple/quick case.
>
> from what I know, process creation is extremely expensive, much more so
> that thread creation.  Which is why I thought properly tuned apache
> installs are not configured to fork for each request.  Now, I agree a more
> proper implementation would require a fork once, and communicate multiple
> authentications over a pre-connected pipe, but still, you have to deal
with
> possibly saturating that pipe, and also you've not make it a bit more
> complex to write a script that is pluggable into this authentication
scheme.
>
> >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.
>
> since we would use libcurl for making HTTP requests, it supports http
> keep-alive requests...and so yes, persistent HTTP connections ARE
possible.
>
> >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.
>
> hardly 'for free' and this would be a horribly inefficient method of doing
it.
>
>
>
>
> > >
> > > 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".
>
> right, wether it's a script or a C program, it's still a fact that most
(if
> not all) win32 users would not know what to do with a "script
> authentication module"...And again, I'm not saying that it shouldn't be
> implemented, but rather that I think it would be in the best interest of
> everyone if both methods (script and HTTP request) are implemented.
>
> 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 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.
>

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