Value | Meaning |
---|---|
Invalid0 | |
TimeoutInitial24 | [connection int32] Timeout value (in ms) to use when first connecting |
TimeoutConnected25 | [connection int32] Timeout value (in ms) to use after connection is established |
SendBufferSize9 | [connection int32] Upper limit of buffered pending bytes to be sent, if this is reached SendMessage will return k_EResultLimitExceeded Default is 512k (524288 bytes) |
ConnectionUserData40 | [connection int64] Get/set userdata as a configuration option. The default value is -1. You may want to set the user data as a config value, instead of using ISteamNetworkingSockets::SetConnectionUserData in two specific instances: - You wish to set the userdata atomically when creating an outbound connection, so that the userdata is filled in properly for any callbacks that happen. However, note that this trick only works for connections initiated locally! For incoming connections, multiple state transitions may happen and callbacks be queued, before you are able to service the first callback! Be careful! - You can set the default userdata for all newly created connections by setting this value at a higher level (e.g. on the listen socket or at the global level.) Then this default value will be inherited when the connection is created. This is useful in case -1 is a valid userdata value, and you wish to use something else as the default value so you can tell if it has been set or not. HOWEVER: once a connection is created, the effective value is then bound to the connection. Unlike other connection options, if you change it again at a higher level, the new value will not be inherited by connections. Using the userdata field in callback structs is not advised because of tricky race conditions. Instead, you might try one of these methods: - Use a separate map with the HSteamNetConnection as the key. - Fetch the userdata from the connection in your callback using ISteamNetworkingSockets::GetConnectionUserData, to |
SendRateMin10 | [connection int32] Minimum/maximum send rate clamp, 0 is no limit. This value will control the min/max allowed sending rate that bandwidth estimation is allowed to reach. Default is 0 (no-limit) |
SendRateMax11 | |
NagleTime12 | [connection int32] Nagle time, in microseconds. When SendMessage is called, if the outgoing message is less than the size of the MTU, it will be queued for a delay equal to the Nagle timer value. This is to ensure that if the application sends several small messages rapidly, they are coalesced into a single packet. See historical RFC 896. Value is in microseconds. Default is 5000us (5ms). |
IP_AllowWithoutAuth23 | [connection int32] Don't automatically fail IP connections that don't have strong auth. On clients, this means we will attempt the connection even if we don't know our identity or can't get a cert. On the server, it means that we won't automatically reject a connection due to a failure to authenticate. (You can examine the incoming connection and decide whether to accept it.) This is a dev configuration value, and you should not let users modify it in production. |
MTU_PacketSize32 | [connection int32] Do not send UDP packets with a payload of larger than N bytes. If you set this, k_ESteamNetworkingConfig_MTU_DataSize is automatically adjusted |
MTU_DataSize33 | [connection int32] (read only) Maximum message size you can send that will not fragment, based on k_ESteamNetworkingConfig_MTU_PacketSize |
Unencrypted34 | [connection int32] Allow unencrypted (and unauthenticated) communication. 0: Not allowed (the default) 1: Allowed, but prefer encrypted 2: Allowed, and preferred 3: Required. (Fail the connection if the peer requires encryption.) This is a dev configuration value, since its purpose is to disable encryption. You should not let users modify it in production. (But note that it requires the peer to also modify their value in order for encryption to be disabled.) |
SymmetricConnect37 | [connection int32] Set this to 1 on outbound connections and listen sockets, to enable "symmetric connect mode", which is useful in the following common peer-to-peer use case: - The two peers are "equal" to each other. (Neither is clearly the "client" or "server".) - Either peer may initiate the connection, and indeed they may do this at the same time - The peers only desire a single connection to each other, and if both peers initiate connections simultaneously, a protocol is needed for them to resolve the conflict, so that we end up with a single connection. This use case is both common, and involves subtle race conditions and tricky pitfalls, which is why the API has support for dealing with it. If an incoming connection arrives on a listen socket or via custom signaling, and the application has not attempted to make a matching outbound connection in symmetric mode, then the incoming connection can be accepted as usual. A "matching" connection means that the relevant endpoint information matches. (At the time this comment is being written, this is only supported for P2P connections, which means that the peer identities must match, and the virtual port must match. At a later time, symmetric mode may be supported for other connection types.) If connections are initiated by both peers simultaneously, race conditions can arise, but fortunately, most of them are handled internally and do not require any special awareness from the application. However, there is one important case that application code must be aware of: If application code attempts an outbound connection using a ConnectXxx function in symmetric mode, and a matching incoming connection is already waiting on a listen socket, then instead of forming a new connection, the ConnectXxx call will accept the existing incoming connection, and return a connection handle to this accepted connection. IMPORTANT: in this case, a SteamNetConnectionStatusChangedCallback_t has probably *already* been posted to the queue for the incoming connection! (Once callbacks are posted to the queue, they are not modified.) It doesn't matter if the callback has not been consumed by the app. Thus, application code that makes use of symmetric connections must be aware that, when processing a SteamNetConnectionStatusChangedCallback_t for an incoming connection, the m_hConn may refer to a new connection that the app has has not seen before (the usual case), but it may also refer to a connection that has already been accepted implicitly through a call to Connect()! In this case, AcceptConnection() will return k_EResultDuplicateRequest. Only one symmetric connection to a given peer (on a given virtual port) may exist at any given time. If client code attempts to create a connection, and a (live) connection already exists on the local host, then either the existing connection will be accepted as described above, or the attempt to create a new connection will fail. Furthermore, linger mode functionality is not supported on symmetric connections. A more complicated race condition can arise if both peers initiate a connection at roughly the same time. In this situation, each peer will receive an incoming connection from the other peer, when the application code has already initiated an outgoing connection to that peer. The peers must resolve this conflict and decide who is going to act as the "server" and who will act as the "client". Typically the application does not need to be aware of this case as it is handled internally. On both sides, the will observe their outbound connection being "accepted", although one of them one have been converted internally to act as the "server". In general, symmetric mode should be all-or-nothing: do not mix symmetric connections with a non-symmetric connection that it might possible "match" with. If you use symmetric mode on any connections, then both peers should use it on all connections, and the corresponding listen socket, if any. The behaviour when symmetric and ordinary connections are mixed is not defined by this API, and you should not rely on it. (This advice only applies when connections might possibly "match". For example, it's OK to use all symmetric mode connections on one virtual port, and all ordinary, non-symmetric connections on a different virtual port, as there is no potential for ambiguity.) When using the feature, you should set it in the following situations on applicable objects: - When creating an outbound connection using ConnectXxx function - When creating a listen socket. (Note that this will automatically cause any accepted connections to inherit the flag.) - When using custom signaling, before accepting an incoming connection. Setting the flag on listen socket and accepted connections will enable the API to automatically deal with duplicate incoming connections, even if the local host has not made any outbound requests. (In general, such duplicate requests from a peer are ignored internally and will not be visible to the application code. The previous connection must be closed or resolved first.) |
LocalVirtualPort38 | [connection int32] For connection types that use "virtual ports", this can be used to assign a local virtual port. For incoming connections, this will always be the virtual port of the listen socket (or the port requested by the remote host if custom signaling is used and the connection is accepted), and cannot be changed. For connections initiated locally, the local virtual port will default to the same as the requested remote virtual port, if you do not specify a different option when creating the connection. The local port is only relevant for symmetric connections, when determining if two connections "match." In this case, if you need the local and remote port to differ, you can set this value. You can also read back this value on listen sockets. This value should not be read or written in any other context. |
EnableDiagnosticsUI46 | [connection int32] True to enable diagnostics reporting through generic platform UI. (Only available on Steam.) |
FakePacketLoss_Send2 | [global float, 0--100] Randomly discard N pct of packets instead of sending/recv This is a global option only, since it is applied at a low level where we don't have much context |
FakePacketLoss_Recv3 | |
FakePacketLag_Send4 | [global int32]. Delay all outbound/inbound packets by N ms |
FakePacketLag_Recv5 | |
FakePacketReorder_Send6 | [global float] 0-100 Percentage of packets we will add additional delay to (causing them to be reordered) |
FakePacketReorder_Recv7 | |
FakePacketReorder_Time8 | [global int32] Extra delay, in ms, to apply to reordered packets. |
FakePacketDup_Send26 | [global float 0--100] Globally duplicate some percentage of packets we send |
FakePacketDup_Recv27 | |
FakePacketDup_TimeMax28 | [global int32] Amount of delay, in ms, to delay duplicated packets. (We chose a random delay between 0 and this value) |
PacketTraceMaxBytes41 | [global int32] Trace every UDP packet, similar to Wireshark or tcpdump. Value is max number of bytes to dump. -1 disables tracing. |
FakeRateLimit_Send_Rate42 | |
FakeRateLimit_Send_Burst43 | |
FakeRateLimit_Recv_Rate44 | |
FakeRateLimit_Recv_Burst45 | |
Callback_ConnectionStatusChanged201 | [connection FnSteamNetConnectionStatusChanged] Callback that will be invoked when the state of a connection changes. IMPORTANT: callbacks are dispatched to the handler that is in effect at the time the event occurs, which might be in another thread. For example, immediately after creating a listen socket, you may receive an incoming connection. And then immediately after this, the remote host may close the connection. All of this could happen before the function to create the listen socket has returned. For this reason, callbacks usually must be in effect at the time of object creation. This means you should set them when you are creating the listen socket or connection, or have them in effect so they will be inherited at the time of object creation. For example: exterm void MyStatusChangedFunc( SteamNetConnectionStatusChangedCallback_t *info ); SteamNetworkingConfigValue_t opt; opt.SetPtr( k_ESteamNetworkingConfig_Callback_ConnectionStatusChanged, MyStatusChangedFunc ); SteamNetworkingIPAddr localAddress; localAddress.Clear(); HSteamListenSocket hListenSock = SteamNetworkingSockets()->CreateListenSocketIP( localAddress, 1, &opt ); When accepting an incoming connection, there is no atomic way to switch the callback. However, if the connection is DOA, AcceptConnection() will fail, and you can fetch the state of the connection at that time. If all connections and listen sockets can use the same callback, the simplest method is to set it globally before you create any listen sockets or connections. |
Callback_AuthStatusChanged202 | [global FnSteamNetAuthenticationStatusChanged] Callback that will be invoked when our auth state changes. If you use this, install the callback before creating any connections or listen sockets, and don't change it. See: ISteamNetworkingUtils::SetGlobalCallback_SteamNetAuthenticationStatusChanged |
Callback_RelayNetworkStatusChanged203 | [global FnSteamRelayNetworkStatusChanged] Callback that will be invoked when our auth state changes. If you use this, install the callback before creating any connections or listen sockets, and don't change it. See: ISteamNetworkingUtils::SetGlobalCallback_SteamRelayNetworkStatusChanged |
Callback_MessagesSessionRequest204 | [global FnSteamNetworkingMessagesSessionRequest] Callback that will be invoked when a peer wants to initiate a SteamNetworkingMessagesSessionRequest. See: ISteamNetworkingUtils::SetGlobalCallback_MessagesSessionRequest |
Callback_MessagesSessionFailed205 | [global FnSteamNetworkingMessagesSessionFailed] Callback that will be invoked when a session you have initiated, or accepted either fails to connect, or loses connection in some unexpected way. See: ISteamNetworkingUtils::SetGlobalCallback_MessagesSessionFailed |
Callback_CreateConnectionSignaling206 | [global FnSteamNetworkingSocketsCreateConnectionSignaling] Callback that will be invoked when we need to create a signaling object for a connection initiated locally. See: ISteamNetworkingSockets::ConnectP2P, ISteamNetworkingMessages. |
Callback_FakeIPResult207 | [global FnSteamNetworkingFakeIPResult] Callback that's invoked when a FakeIP allocation finishes. See: ISteamNetworkingSockets::BeginAsyncRequestFakeIP, ISteamNetworkingUtils::SetGlobalCallback_FakeIPResult |
P2P_STUN_ServerList103 | [connection string] Comma-separated list of STUN servers that can be used for NAT piercing. If you set this to an empty string, NAT piercing will not be attempted. Also if "public" candidates are not allowed for P2P_Transport_ICE_Enable, then this is ignored. |
P2P_Transport_ICE_Enable104 | [connection int32] What types of ICE candidates to share with the peer. See k_nSteamNetworkingConfig_P2P_Transport_ICE_Enable_xxx values |
P2P_Transport_ICE_Penalty105 | [connection int32] When selecting P2P transport, add various penalties to the scores for selected transports. (Route selection scores are on a scale of milliseconds. The score begins with the route ping time and is then adjusted.) |
P2P_Transport_SDR_Penalty106 | |
P2P_TURN_ServerList107 | |
P2P_TURN_UserList108 | |
P2P_TURN_PassList109 | |
SDRClient_ConsecutitivePingTimeoutsFailInitial19 | [int32 global] If the first N pings to a port all fail, mark that port as unavailable for a while, and try a different one. Some ISPs and routers may drop the first packet, so setting this to 1 may greatly disrupt communications. |
SDRClient_ConsecutitivePingTimeoutsFail20 | [int32 global] If N consecutive pings to a port fail, after having received successful communication, mark that port as unavailable for a while, and try a different one. |
SDRClient_MinPingsBeforePingAccurate21 | [int32 global] Minimum number of lifetime pings we need to send, before we think our estimate is solid. The first ping to each cluster is very often delayed because of NAT, routers not having the best route, etc. Until we've sent a sufficient number of pings, our estimate is often inaccurate. Keep pinging until we get this many pings. |
SDRClient_SingleSocket22 | [int32 global] Set all steam datagram traffic to originate from the same local port. By default, we open up a new UDP socket (on a different local port) for each relay. This is slightly less optimal, but it works around some routers that don't implement NAT properly. If you have intermittent problems talking to relays that might be NAT related, try toggling this flag |
SDRClient_ForceRelayCluster29 | [global string] Code of relay cluster to force use. If not empty, we will only use relays in that cluster. E.g. 'iad' |
SDRClient_DebugTicketAddress30 | [connection string] For debugging, generate our own (unsigned) ticket, using the specified gameserver address. Router must be configured to accept unsigned tickets. |
SDRClient_ForceProxyAddr31 | [global string] For debugging. Override list of relays from the config with this set (maybe just one). Comma-separated list. |
SDRClient_FakeClusterPing36 | [global string] For debugging. Force ping times to clusters to be the specified values. A comma separated list of <cluster>=<ms> values. E.g. "sto=32,iad=100" This is a dev configuration value, you probably should not let users modify it in production. |
LogLevel_AckRTT13 | |
LogLevel_PacketDecode14 | |
LogLevel_Message15 | |
LogLevel_PacketGaps16 | |
LogLevel_P2PRendezvous17 | |
LogLevel_SDRRelayPings18 | |
DELETED_EnumerateDevVars35 | |
_Force32Bit0x7fffffff |
Configuration options