A Cluster Config message MUST be the first post authentication message sent on a BEP connection.
However there are quite a few scenarios where we close a connection before sending a cluster config, e.g. if we have a connection of higher prio. In these cases it would be good to notify the peer that we are closing the connection, but strictly speaking that would violate the BEP (if the other device considers the connection as valid, it will take 5min for it to time out, stalling further connection attempts until then). Is that intended or should the close message be exempt from that?
I think it was always intended to be exempt. Although I guess today we just straight up close the connection instead. I don’t see why this would cause a timeout on the other side? There should be an EOF return on the read() pretty much immediately.
Uh, that would somewhat invalidate a lot of my thinking (or at least make it much less important): Does calling tls.Conn.Close notify the other end about the connection being closed? So the BEP close message is just there to transmit a human readable message as to why it will be closed. I was under the impression that unless a BEP close message was received, a connection is only closed after the ping timeout interval.
How does that propagate to the model though? The protocol side of things doesn’t know about the TLS/TCP connection, but it is responsible for calling model.Closed - and as long as that doesn’t happen, new connections will be terminated (unless they have higher prio).