<type category="enum" namespace="Steamworks.Data" name="ConnectionState" is="enum"> <summary>High level connection state</summary>⤶ <entries> <entry name="None" value="0"></entry>⤶ <entry name="Connecting" value="1"></entry>⤶ <entry name="FindingRoute" value="2"></entry>⤶ <entry name="Connected" value="3"></entry>⤶ <entry name="ClosedByPeer" value="4"></entry>⤶ <entry name="None" value="0">Dummy value used to indicate an error condition in the API.⤶ Specified connection doesn't exist or has already been closed.⤶ </entry>⤶ <entry name="Connecting" value="1"> We are trying to establish whether peers can talk to each other,⤶ whether they WANT to talk to each other, perform basic auth,⤶ and exchange crypt keys.⤶ ⤶ - For connections on the "client" side (initiated locally):⤶ We're in the process of trying to establish a connection.⤶ Depending on the connection type, we might not know who they are.⤶ Note that it is not possible to tell if we are waiting on the⤶ network to complete handshake packets, or for the application layer⤶ to accept the connection.⤶ ⤶ - For connections on the "server" side (accepted through listen socket):⤶ We have completed some basic handshake and the client has presented⤶ some proof of identity. The connection is ready to be accepted⤶ using AcceptConnection().⤶ ⤶ In either case, any unreliable packets sent now are almost certain⤶ to be dropped. Attempts to receive packets are guaranteed to fail.⤶ You may send messages if the send mode allows for them to be queued.⤶ but if you close the connection before the connection is actually⤶ established, any queued messages will be discarded immediately.⤶ (We will not attempt to flush the queue and confirm delivery to the⤶ remote host, which ordinarily happens when a connection is closed.)⤶ </entry>⤶ <entry name="FindingRoute" value="2">Some connection types use a back channel or trusted 3rd party⤶ for earliest communication. If the server accepts the connection,⤶ then these connections switch into the rendezvous state. During this⤶ state, we still have not yet established an end-to-end route (through⤶ the relay network), and so if you send any messages unreliable, they⤶ are going to be discarded.⤶ </entry>⤶ <entry name="Connected" value="3">We've received communications from our peer (and we know⤶ who they are) and are all good. If you close the connection now,⤶ we will make our best effort to flush out any reliable sent data that⤶ has not been acknowledged by the peer. (But note that this happens⤶ from within the application process, so unlike a TCP connection, you are⤶ not totally handing it off to the operating system to deal with it.)⤶ </entry>⤶ <entry name="ClosedByPeer" value="4"> Connection has been closed by our peer, but not closed locally.⤶ The connection still exists from an API perspective. You must close the⤶ handle to free up resources. If there are any messages in the inbound queue,⤶ you may retrieve them. Otherwise, nothing may be done with the connection⤶ except to close it.⤶ ⤶ This stats is similar to CLOSE_WAIT in the TCP state machine.⤶ </entry>⤶ <entry name="ProblemDetectedLocally" value="5"></entry> <entry name="Force32Bit" value="2147483647"></entry> <entry name="Dead" value="-3"></entry> <entry name="Linger" value="-2"></entry> <entry name="FinWait" value="-1"></entry> </entries> </type>