From 764fe67f4009b8028232a063950f80e0abb5c1f4 Mon Sep 17 00:00:00 2001 From: jurij-jukic Date: Mon, 13 May 2024 10:51:25 +0200 Subject: [PATCH] apply requested changes --- src/networking_protocol.md | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/src/networking_protocol.md b/src/networking_protocol.md index 2d98fec1..34285eee 100644 --- a/src/networking_protocol.md +++ b/src/networking_protocol.md @@ -145,6 +145,9 @@ Successfully decrypted and deserialized messages should have their `source` fiel #### 3.4. Closing a Connection +A connection can be intentionally closed by any party, at any time. +Other causes of connection closure are discussed in this section. + All connection errors must result in closing a connection. Failure to send a message must be treated as a connection error. @@ -166,7 +169,7 @@ Messages do not have to expect a response. If no response is expected, a networking-level offline or timeout error may still be thrown. Local messages will only receive timeout errors if they expect a response. -If a peer is direct, i.e. they have networking information published onchain, determining their offline status is simple: try to create a connection and send a message; it will throw an offline error if this message fails. +If a peer is direct, i.e. they have networking information published onchain, determining their offline status is simple: try to create a connection and send a message; if the underlying transport protocol experiences any errors while doing so, throw an 'offline' error. If a message is not responded to before the timeout counter expires, it will throw a timeout. If a peer is indirect, i.e. they have routers, multiple attempts must be made before either an offline error is thrown.