[Wifidog] libhttpd

[Mina Naguib]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


I've been thinking about this too, and especially since we all seemed to 
lean toward option #3 (non-blocking sockets).

I'm afraid we'll be digging our own grave going that route.  The project 
will become extremely unmaintainable and complex.

I'd like to stick to a more simple approach:

1. Keep things as they are right now - handle 1 client at a time

This is not problematic - for example a client requests "yahoo.com" and 
we serve him "Location: centralserver.ilesansfil.org/login" - that whole 
requests takes a few milliseconds to process - any concurrent clients 
can will pause until that first request is served - but we're talking 
milliseconds, so it's not significant.

The only problem is when a request needs a long time to process.  And 
the only time I could think of when that happens, is when the gateway 
needs to talk to the central server.

So I propose we just fork() when we need to talk to the central server, 
otherwise we keep it single-threaded as is.

Some pseudocode for main loop:

1. Wait for httpd connection to come in, timeout 30 seconds
2     If connection came it, call appropriate URL handler
3.    If it's time to update central server with general stats:
4        fork(), child:
5.            Connect to central server via http
6.            Send heartbeat, send traffic stats of all clients
7.            Disconnects, exits

Some pseudocode for URL handlers:

1. If URL handler does a quick job such as send a "Location" header, 
just do it and return
2. If URL handler takes a long time:
3.    fork()
4.    Parent adds PID of child to a linked list along with client IP/mac 
address/etc - then returns to main loop
5.    Child parses input from client, connects to central server via 
http, talks to it, sends appropriate output to client, then exit()s with 
appropriate code - for example profile # obtained from central server

In main program, signal handler:

1. Gets called when child dies - retrieves the child's PID and exit code
2. Loops through the linked list of fork()ed children, matches the one 
that just died by PID - deletes item from linked list
3. We now know which client this child handled, and the profile ID the 
central server wants us to give - implement firewall rules appropriately

We'll have to implement some sanity so as not to fork() to death if 
attacked, but I think the above takes care of our concurrency problem, 
as well as stays on the simple side.

What are your thoughts on that ?

Alexandre Carmel-Veilleux wrote:
> hello,
> 
> 	I've been puzzling about this one for a while (as can be noticed
> from my hard to decipher previous post) and I'm coming to the conclusion
> that there are no "nice" ways of making libhttpd be anything more then
> an iterative web server short of rewriting major parts of it.
> 
> 	So I got thinking on a different angle. How about including
> wifidog INTO an existing httpd? There are some lightweight httpd's out
> there like BOA (70k stripped on 32-bit PPC, 58k stripped on x86) and
> some even lighter weight ones.
> 
> 	Including wifidog as a form of module to an httpd (or merging
> an httpd with wifidog) might prove to be a viable solution?
> 
> 	Comments????
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFAbYM8eS99pGMif6wRAgQHAJoC+rZ8BtVUz6uWyKlOmq/S4RNleACgyvgK
vwcIXJNvLyCSklSUlaclnxU=
=WC9s
-----END PGP SIGNATURE-----

-------------- next part --------------
_______________________________________________
Wifidog mailing list
Wifidog at isf.waglo.com
http://isf.waglo.com/mailman/listinfo/wifidog_isf.waglo.com