Changes between Version 16 and Version 17 of doc/developer/WiFiDog_V2

03/26/08 00:32:18 (14 years ago)



  • doc/developer/WiFiDog_V2

    v16 v17  
    55 * Remove !ClientTimeout. All decisions regarding a client timeout should be decided by the auth server 
    66 * wdctl restart adds a lot of dirty code for it to work. (if we download the configuration periodically from the auth server, we don't need the wdctl restart anymore) 
     7> acv: Probably ways to make it cleaner. Being able to *not* download configuration from server would be nice to folks wanting to make a more NoCatSplash like setup. Pulling config is obviously really nice to setup like ISF. 
    78 * Firewall abstraction was done quickly 
     9> acv: Agree. Makes it quite hard for people to port to different firewalls. 
    810 * No QoS support 
    911 * Doesn't verify that the FW modules work (unless you use the shell script wifidog-init provided, Linux only) 
    1012 * Protocol is too simplistic, not flexible, proprietary 
    1113 * Wifidog doesn't open internet connection when auth server is not available (needs a policy when that happens.... allow all or deny all) 
     14> acv: I had some code to do that, not sure why it never got committed. Default behavior was defined in the config file. 
    1215 * Internal linked list COULD have synchronization problems with reality, suggest removing and parsing iptables output to see current LIVE state 
     16> 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? 
    1418= Proposed V2 features = 
    1519 * 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) 
     20> acv: This ideally should be optional I think. 
    1621 * QoS support 
    1722 * Versioned and more standard protocol 
    4954=== http client thread === 
    5055 * 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. 
     56> 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. 
    5258== Options on command line == 
    5763The node ID will be (default) the mac address associated to the interface that the default route is using... (parsing netstat -rn). It should sleep and retry to parse in case the networking (pppoe for example) is not up yet. 
     65> 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. 
    5967When wifidog initiates its config it should get options like "this is the url to contact the login page"...: 
    6876=== JSON for protocol === 
    6977XML or YAML would have been great, but I tried to use Syck ( and it didn't seem trivial to use, it looks like it supports a stream parser, we need something more like a DOM to find values returned. 
     79> acv: How big of a library footprint does JSON have in KB and dependencies? What about PHP support? 
    7181JSON (with json-c-0.7 gives us that in C and is quite elegant.