diff --git a/Posts/TCP-ns b/Posts/TCP-ns index d577190..ffe767e 100644 --- a/Posts/TCP-ns +++ b/Posts/TCP-ns @@ -37,7 +37,7 @@ Now, after switching over to µTCP, graphed below, there's much fewer network ut [](/static/img/a.ns.mtcp-utcp.png) -Investigating the involved parts showed that a TCP connection that was never established has been registered at the MirageOS layer, but the pure core does not expose an event from the received RST that the connection has been cancelled. This means the MirageOS layer piles up all the connection attempts, and doesn't inform the application that the connection couldn't be established. Once this was well understood, developing the [required code changes](https://github.com/robur-coop/utcp/commit/67fc49468e6b75b96a481ebe44dd11ce4bb76e6c) was straightforward. The graph shows that the fix was deployed at 15:25. The memory usage is constant afterwards, but the network utilization increased enormously. +Investigating the involved parts showed that a TCP connection that was never established has been registered at the MirageOS layer, but the pure core does not expose an event from the received RST that the connection has been cancelled. This means the MirageOS layer piles up all the connection attempts, and doesn't inform the application that the connection couldn't be established. Note that the MirageOS layer is not code derived from the formal model, but boilerplate for (a) effectful side-effects (IO) and (b) meeting the needs of the [TCP.S](https://github.com/mirage/mirage-tcpip/blob/v8.0.0/src/core/tcp.ml) module type (so that µTCP can be used as a drop-in replacement for mirage-tcpip). Once this was well understood, developing the [required code changes](https://github.com/robur-coop/utcp/commit/67fc49468e6b75b96a481ebe44dd11ce4bb76e6c) was straightforward. The graph shows that the fix was deployed at 15:25. The memory usage is constant afterwards, but the network utilization increased enormously. [](/static/img/a.ns.utcp-ev.png)