Changes between Version 20 and Version 21 of doc/developer/WiFiDog_V2

03/26/08 08:19:21 (14 years ago)



  • doc/developer/WiFiDog_V2

    v20 v21  
    1515 * Internal linked list COULD have synchronization problems with reality, suggest removing and parsing iptables output to see current LIVE state 
    1616> acv: Maybe just have a verification thread that runs somewhat infrequently to reduce overhead or is process spawning performance no longer a problem to get iptables output? 
     17>> philippe: if we fork once to run iptables -n -v -x --line-numbers -t filter -L every 5 minutes, it won't cost much. I know we can guarantee synchronization with the pthread mechanisms, but it's still code that "could" fail. If we can do without, I think we should. 
    1819= Proposed V2 features = 
    1920 * Configuration downloaded from auth server on startup (and periodically) including "who should be connected" (so it gets back to where it was on a restart) 
    2021> acv: This ideally should be optional I think. 
     22>> philippe: my idea is to replace the main logic of deciding who should be kicked out, allowed in, FW rules, QOS, by a call from the auth server. That way the gateway is "waiting" for commands, and just executes them, keeps the code small, clean but still flexible. Of course, if we want to support people who want to run without an auth server, we'll need to add a lot of code to do all that decision on the gateway too. It could be as simple as using the JSON "status return" packet as the configuration file, so we have one unique parser (and leave the "should be connected now" clients out.), but we'd still need to re-implement client timeout, etc. I think coding a simplistic auth server in C to run in parallel on the same box would be a better option to keep things standard and not try to accomodate all setups. 
    2123 * QoS support 
    2224 * Versioned and more standard protocol 
    5557 * this thread is launched when a new connection is initiated... if 80 people (just saying) connect to the auth server, there will be 80 threads launched at the same time. it would be GREAT to have a threads pool, but would not be useful 99% of the time, and would take a long time to code and debug. For now, this thread forwards to the right spot, or validates tokens. 
    5658> acv: WiFiDog isn't an high performance web server. The basic philosophy of Libhttpd is ultimately unsuited to handling connections asynchronously so a thread pool would merely mean that most of those 80 people get no reply whatsoever until someone else's done. Either that or libhttpd is re-architected around an async network core (select() or pool() based) and a number of page generation worker threads that do not handle any networking, just fill a memory buffer with their reply and flags it so the network core can flush it back. 
     59>> philippe: I think we agree that we can keep the way it works as-is :) 
    5861== Options on command line == 
    6568> acv: The ability to have stand alone gateway without downloading config would be nice. I think this philosophy of "download everything" makes the barrier to deployment significantly larger then it needs to be. 
     69>> philippe: with the current auth server (all the dependencies, etc.) I agree. I think I would personally rather spend some effort coding a light solution in C that could be distributed straight with wifidog (why not?) with a small web interface to configure it. 
    6771When wifidog initiates its config it should get options like "this is the url to contact the login page"...: 
    7983> acv: How big of a library footprint does JSON have in KB (Non-issue-ish it seems, 36KB on osx 10.5 no funky dependencies)? What about PHP support (Requires PHP 5.2.0 for availability in a default install)? 
     84>> philippe: Right, it's pretty small. We could do our own parser, but why reinvent the wheel for a few kb's?. Also, since there are other efforts to code an auth in other languages, I think we kind of need to go with a standard encapsulation like JSON this time. I'm a big XML fan myself, but that would be too much (size of lib, etc. again, unless we make our own parser...). 
    8186> While I find it ugly to look at compared to YAML, JSON looks viable if a dependency on either PHP 5.2.0 or optional PHP5 module is OK. Library looks like it should build OK for C (sort of loath to get the whole libhttpd problems though). 
    8388> acv: (To give YAML a chance:) Also what about spyc ( to load YAML in PHP inistead of Syck? For the size of data structure we're likely to use high-performance is a non-issue. Also LibYAML ( appears to be the recommended C implementation. 
     89>> philippe: I gotta say haven't tried libyaml because their page says "It's in an early stage of development" with current version from 1 year and a half ago. If it offers a way to parse and generate YAML as easy as I've done it with json-c, I don't see why we wouldn't use it. 
    8591JSON (with json-c-0.7 gives us that in C and is quite elegant.