<type category="enum" namespace="Steamworks.Data" name="ConnectionState" is="enum"> <summary>High level connection state</summary> <entries> <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,⤶ 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>⤶ 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>⤶ 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.⤶ 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>⤶ 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>