Removing the TimeoutAffix from the control connection of TCPRelayAffix. We've discussed this, and it seems that changing the interpretation of SocketWouldBlockError to signify an ultimate timeout (rather than a temporary condition which you might be able to get around by retrying) is a bad idea. I'm rather putting sockettimeout's (which work on the application layer) on the control connection and setup phases of forwarded connections respectively.
"Update" CoordinationAffix to use advertisepipe, see #52. (I'm really syncing it with Seattle's r7220).
Cleaning up the tcp_relay directory, removing dead / duplciate files.
Adding an initial take at the MakeMeHearAffix, an Affix component that makes the host emplyoing it able to receive incoming connections despite NAT gateways or firewalls.
Library to check whether the host can receive incoming connections from ``canilisten'' servers, and to run such servers.
Adding back in the NoopAffix which is the default Affix component used by MakeMeHearAffix in case the host is able to receive connections from outside without the help of a TCP relay.
Don't look at this. It's my work-in-progress unit test (or actually, wide-scale bug discovery device) for MakeMeHearAffix and the surrounding Affix framework.
Replaced remnants of TimeoutAffix and its logic with proper application-layer timeouts using the sockettimeout library.
Removed scratch code of 8955c89809f538a595f6a98414546b5cc5a9d838; completed the unit test so that advertisement is used by both server and client to announce/look up Affix stacks via a CoordinationAffix; added documentation on what is going on behind the scenes (checks, setups, relays, advertisement).
Wrapping exceptions that the canilisten library might raise. This is required as an Affix component may only raise exceptions conforming to the RepyV2 API, but the libraries it calls don't necessarily do that.
Merge branch 'develop-makemehearaffix' into beta