ESteamNetConnectionEnd

Use codes in this range for "unusual" disconnection

2xxx: Application ended the connection in some sort of exceptional or unusual manner that might indicate a bug or configuration issue.

Use codes in this range for "normal" disconnection

Application codes. These are the values you will pass to ISteamNetworkingSockets::CloseConnection. You can use these codes if you want to plumb through application-specific reason codes. If you don't need this facility, feel free to always pass k_ESteamNetConnectionEnd_App_Generic. The distinction between "normal" and "exceptional" termination is one you may use if you find useful, but it's not necessary for you to do so. The only place where we distinguish between normal and exceptional is in connection analytics. If a significant proportion of connections terminates in an exceptional manner, this can trigger an alert. 1xxx: Application ended the connection in a "usual" manner. E.g.: user intentionally disconnected from the server, gameplay ended normally, etc

Invalid/sentinel value

A hosted server is having trouble talking to the relay that the client was using, so the problem is most likely on our end

We're having trouble contacting many (perhaps all) relays. Since it's unlikely that they all went offline at once, the best explanation is that we have a problem on our end. Note that we don't bother distinguishing between "many" and "all", because in practice, it takes time to detect a connection problem, and by the time the connection has timed out, we might not have been able to actively probe all of the relay clusters, even if we were able to contact them at one time. So this code just means that: * We don't have any recent successful communication with any relay. * We have evidence of recent failures to communicate with multiple relays.

System codes. These will be returned by the system when the connection state is k_ESteamNetworkingConnectionState_ClosedByPeer or k_ESteamNetworkingConnectionState_ProblemDetectedLocally. It is illegal to pass a code in this range to ISteamNetworkingSockets::CloseConnection 3xxx: Connection failed or ended because of problem with the local host or their connection to the Internet.

We're not able to get the SDR network config. This is *almost* always a local issue, since the network config comes from the CDN, which is pretty darn reliable.

You cannot do what you want to do because you're running in offline mode.

ICE P2P rendezvous failed because we were not able to determine our "public" address (e.g. reflexive address via STUN) If relay fallback is available (it always is on Steam), then this is only used internally and will not be returned as a high level failure.

Steam rejected our request because we don't have rights to do this.

A failure that isn't necessarily the result of a software bug, but that should happen rarely enough that it isn't worth specifically writing UI or making a localized message for. The debug string should contain further details.

Generic failure that is most likely a software bug.

5xxx: Connection failed for some other reason.

A server in a dedicated hosting situation has no relay sessions active with which to talk back to a client. (It's the client's job to open and maintain those sessions.)

NAT punch failed, probably due to NAT/firewall configuration. If relay fallback is available (it always is on Steam), then this is only used internally and will not be returned as a high level failure.

While trying to initiate a connection, we never received *any* communication from the peer. P2P rendezvous failed in a way that we don't have more specific information

Our peer replied that it has no record of the connection. This should not happen ordinarily, but can happen in a few exception cases: - This is an old connection, and the peer has already cleaned up and forgotten about it. (Perhaps it timed out and they closed it and were not able to communicate this to us.) - A bug or internal protocol error has caused us to try to talk to the peer about the connection before we received confirmation that the peer has accepted the connection. - The peer thinks that we have closed the connection for some reason (perhaps a bug), and believes that is it is acknowledging our closure.

There's some trouble talking to Steam.

The connection to the remote host timed out, but we don't know if the problem is on our end, in the middle, or on their end.

You presented me with a cert that was I was able to parse and *technically* we could use encrypted communication. But there was a problem that prevents me from checking your identity or ensuring that somebody int he middle can't observe our communication. E.g.: - the CA key was missing (and I don't accept unsigned certs) - The CA key isn't one that I trust, - The cert doesn't was appropriately restricted by app, user, time, data center, etc. - The cert wasn't issued to you. - etc

Something was invalid with the cert or crypt handshake info you gave me, I don't understand or like your key types, etc.

These will never be returned Something wrong with the protocol version you are using. (Probably the code you are running is too old.)

4xxx: Connection failed or ended, and it appears that the cause does NOT have to do with the local host or their connection to the Internet. It could be caused by the remote host, or it could be somewhere in between.

NAT punch failed failed because we never received any public addresses from the remote host. (But we did receive some signals form them.) If relay fallback is available (it always is on Steam), then this is only used internally and will not be returned as a high level failure.

The connection was lost, and as far as we can tell our connection to relevant services (relays) has not been disrupted. This doesn't mean that the problem is "their fault", it just means that it doesn't appear that we are having network issues on our end.