[Wifidog] libcurl

Mina Naguib webmaster at topfx.com
Fri Mar 19 10:44:11 EST 2004

Hash: SHA1

Tony Bussieres wrote:
> On Thu, 2004-03-18 at 23:08, Alexandre Carmel-Veilleux wrote:
>>On Thu, Mar 18, 2004 at 11:06:25PM -0500, Alexandre Carmel-Veilleux wrote:
>>>	How is the gateway going to handle new requests while it's doing
>>>an auth request? I bet that lib "blocks" until the whole request is
>>>completed. Should we fork()?
>>	The fork rationale would be to fork() and then include the STDIN
>>and STDOUT of the subprocess in the main select() loop... It could also
>>be handled through another mechanism that would better emulate the feature
>>of a socket, but that doesn't matter.
> It's possible to write a non-blocking connect and also non-blocking
> read/write.
> So are we finally using libcurl or a custom protocol?

I think libcurl is out of the question because of it's size, however 
libhttp seems to be a winner.

Design-wise we have one of 3 choices:

1. httpDaemon does not accept requests while httpClient is talking to 
the central server. In that case new clients will just pause for 1-2 
seconds before being re-directed to the auth page.  Depending on the 
load and concurrent users logging in this might not be as bad as it sounds.

2. Before httpClient talks to central server a fork() occurs - this will 
keep the httpDaemon responsive 100% of the time.  This is a fairly 
simple solution but could be costly memory-wise and be used as a DDOS.

3. Do non-blocking communications with central server.  This is slightly 
more complicated than #2 however it will keep the process lightweight 
and keep the httpDaemon responsive 100% of the time.  Only issue I see 
is we'll have to make sure libhttp supports that (or hack it so it does)

Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org


-------------- next part --------------
Wifidog mailing list
Wifidog at isf.waglo.com

More information about the Wifidog mailing list