BEP and sending close msg before cluster config

The BEP mandates

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.

No it should indeed realize the close immediately when the TLS/TCP connection goes down. The BEP close message is just about a more explicit reason.

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).

I’m on the phone at the moment and can’t be arsed to look, but I hope that the read error will cause the reader loop to propagate a close upwards.

Sure, it does. Thanks for clarifying this and preventing me from spending time on a non-issue.

1 Like