On Sun, Sep 30, 2012 at 11:42 PM, David Edmondson <dme at dme.org> wrote: >> I am still concerned about memory usage, which keeps growing with each >> connection. Maybe the thread startup/teardown should work from a >> fixed "pool" like Apache does; currently it is dynamic. > > Rather than have a pair of threads for each connection we could have a single thread for "reading from local sockets" and another for "reading from lwip connections" (the pair required due to the differing API). After playing around a little more, I wound up dropping all of the netconn_* API usage in favor of the raw TCP API. This allowed me to use an event loop executing from a single thread. The memory situation is much better now; only lwIP is using dynamic allocations. Latency-wise it "feels" snappier, but I don't have any hard data to quantify it. I also added a few other goodies: - IP autoconfiguration from the environment vars - Try to exit if OpenConnect has died (e.g. remote idle disconnects) - TCP keepalives, to prevent the remote idle disconnects - "-g" option (similar to ssh) to bind to INADDR_ANY - Minimal "getting started" documentation - SOCKS error replies Unfortunately the code has diverged quite a bit, so it's your call whether it's worth rolling back into the original ocproxy project. Web: https://github.com/cernekee/ocproxy Git: git://github.com/cernekee/ocproxy.git master Kevin Cernekee (12): README: Correct pathname sys_arch: Fix compile error on gcc 4.7 ocproxy: Set IP configuration from the environment, if possible Rewrite ocproxy.c to use the raw TCP API + libevent Remove unused files Add TCP keepalive scripts: Change capitalization of command line args Fix handling of connections reset by peer Terminate ocproxy when OpenConnect quits recv_cb: Return ERR_ABRT if the connection terminated Update README file with new instructions Require MTU to configure interface
