This is useful for proxies/middleware/interception of requests, a runningexample is let's encrypt and the HTTP challenge.The methodology is as follows:- the unikernel requests (via https from let's encrypt) a challenge and solves it  (using a private key, some cryptographic computations)- the let's encrypt server (wants to proof the ownership of the hostname in the  certificate signing request) requests via HTTP (port 80) a specific resource  (http://example.com/.well-known/acme-challenge/...)- the unikernel needs to properly reply to that challengeNow, one path (that we took until now) is to treat this .well-knwon/acme-challengevery special in any unikernel that we wrote.Another path is to create a let's encrypt http challenge library that takes astack, and whenever it needs it registers itself for port 80, proxyingeverything it is not interested in, to the old handler (thus, is_listening),and serving the .well-known/acme-challenge.Concurrent updates to the "listen" hashtable are dangerous of course, greatcare has to be taken (if some other parts of the application as well re-registerlisteners). But I'm confident since listen, unlisten, and is_listening are pure(not in Lwt monad), it's fine and can be dealt with. Another option would be toimplement a real protocol/locking around the shared global resource of listeningports (but I'd first see whether we run into such troubles).Another example is the let's encrypt ALPN challenge, where the process is as follows:- the unikernel requests (via https from let's encrypt) a challenge and solves it  (using a private key, some cryptographic computations)- the let's encrypt server (wants to proof the ownership of the hostname in the  signing request) connects via TLS on port 443 with a specific ALPN string- the unikernel needs to reply with a specially craftes self-signed certificateThis can, as above, be implemented by a temporary proxy while the challenge isin process -- without service interruptions for other parties (web browser, ...)