[icecast-dev] icecast2 ogg vorbis client request headers

[oddsock]

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

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

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

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

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 

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