Struct steamworks::networking_sockets::NetworkingSockets

pub struct NetworkingSockets<Manager> { /* private fields */ }

Access to the steam networking sockets interface

Implementations

impl<Manager: 'static> NetworkingSockets<Manager>

pub fn create_listen_socket_ip( &self, local_address: SocketAddr, options: impl IntoIterator<Item = NetworkingConfigEntry> ) -> Result<ListenSocket<Manager>, InvalidHandle>

Creates a “server” socket that listens for clients to connect to by calling ConnectByIPAddress, over ordinary UDP (IPv4 or IPv6)

You must select a specific local port to listen on and set it as the port field of the local address.

Usually you will set the IP portion of the address to zero, (SteamNetworkingIPAddr::Clear()). This means that you will not bind to any particular local interface (i.e. the same as INADDR_ANY in plain socket code). Furthermore, if possible the socket will be bound in “dual stack” mode, which means that it can accept both IPv4 and IPv6 client connections. If you really do wish to bind a particular interface, then set the local address to the appropriate IPv4 or IPv6 IP.

If you need to set any initial config options, pass them here. See SteamNetworkingConfigValue_t for more about why this is preferable to setting the options “immediately” after creation.

When a client attempts to connect, a SteamNetConnectionStatusChangedCallback_t will be posted. The connection will be in the k_ESteamNetworkingConnectionState_Connecting state.

pub fn connect_by_ip_address( &self, address: SocketAddr, options: impl IntoIterator<Item = NetworkingConfigEntry> ) -> Result<NetConnection<Manager>, InvalidHandle>

Creates a connection and begins talking to a “server” over UDP at the given IPv4 or IPv6 address. The remote host must be listening with a matching call to CreateListenSocketIP on the specified port.

A SteamNetConnectionStatusChangedCallback_t callback will be triggered when we start connecting, and then another one on either timeout or successful connection.

If the server does not have any identity configured, then their network address will be the only identity in use. Or, the network host may provide a platform-specific identity with or without a valid certificate to authenticate that identity. (These details will be contained in the SteamNetConnectionStatusChangedCallback_t.) It’s up to your application to decide whether to allow the connection.

By default, all connections will get basic encryption sufficient to prevent casual eavesdropping. But note that without certificates (or a shared secret distributed through some other out-of-band mechanism), you don’t have any way of knowing who is actually on the other end, and thus are vulnerable to man-in-the-middle attacks.

If you need to set any initial config options, pass them here. See SteamNetworkingConfigValue_t for more about why this is preferable to setting the options “immediately” after creation.

pub fn create_listen_socket_p2p( &self, local_virtual_port: i32, options: impl IntoIterator<Item = NetworkingConfigEntry> ) -> Result<ListenSocket<Manager>, InvalidHandle>

Like CreateListenSocketIP, but clients will connect using ConnectP2P.

nLocalVirtualPort specifies how clients can connect to this socket using ConnectP2P. It’s very common for applications to only have one listening socket; in that case, use zero. If you need to open multiple listen sockets and have clients be able to connect to one or the other, then nLocalVirtualPort should be a small integer (<1000) unique to each listen socket you create.

If you use this, you probably want to call ISteamNetworkingUtils::InitRelayNetworkAccess() when your app initializes.

If you are listening on a dedicated servers in known data center, then you can listen using this function instead of CreateHostedDedicatedServerListenSocket, to allow clients to connect without a ticket. Any user that owns the app and is signed into Steam will be able to attempt to connect to your server. Also, a connection attempt may require the client to be connected to Steam, which is one more moving part that may fail. When tickets are used, then once a ticket is obtained, a client can connect to your server even if they got disconnected from Steam or Steam is offline.

If you need to set any initial config options, pass them here. See SteamNetworkingConfigValue_t for more about why this is preferable to setting the options “immediately” after creation.

pub fn connect_p2p( &self, identity_remote: NetworkingIdentity, remote_virtual_port: i32, options: impl IntoIterator<Item = NetworkingConfigEntry> ) -> Result<NetConnection<Manager>, InvalidHandle>

Begin connecting to a peer that is identified using a platform-specific identifier. This uses the default rendezvous service, which depends on the platform and library configuration. (E.g. on Steam, it goes through the steam backend.)

If you need to set any initial config options, pass them here. See SteamNetworkingConfigValue_t for more about why this is preferable to setting the options “immediately” after creation.

To use your own signaling service, see:

• ConnectP2PCustomSignaling
• k_ESteamNetworkingConfig_Callback_CreateConnectionSignaling

pub fn create_hosted_dedicated_server_listen_socket( &self, local_virtual_port: u32, options: impl IntoIterator<Item = NetworkingConfigEntry> ) -> Result<ListenSocket<Manager>, InvalidHandle>

Create a listen socket on the specified virtual port. The physical UDP port to use will be determined by the SDR_LISTEN_PORT environment variable. If a UDP port is not configured, this call will fail.

This call MUST be made through the SteamGameServerNetworkingSockets() interface.

This function should be used when you are using the ticket generator library to issue your own tickets. Clients connecting to the server on this virtual port will need a ticket, and they must connect using ConnectToHostedDedicatedServer.

If you need to set any initial config options, pass them here. See SteamNetworkingConfigValue_t for more about why this is preferable to setting the options “immediately” after creation.

pub fn init_authentication( &self ) -> Result<NetworkingAvailability, NetworkingAvailabilityError>

Indicate our desire to be ready participate in authenticated communications. If we are currently not ready, then steps will be taken to obtain the necessary certificates. (This includes a certificate for us, as well as any CA certificates needed to authenticate peers.)

You can call this at program init time if you know that you are going to be making authenticated connections, so that we will be ready immediately when those connections are attempted. (Note that essentially all connections require authentication, with the exception of ordinary UDP connections with authentication disabled using k_ESteamNetworkingConfig_IP_AllowWithoutAuth.) If you don’t call this function, we will wait until a feature is utilized that that necessitates these resources.

You can also call this function to force a retry, if failure has occurred. Once we make an attempt and fail, we will not automatically retry. In this respect, the behavior of the system after trying and failing is the same as before the first attempt: attempting authenticated communication or calling this function will call the system to attempt to acquire the necessary resources.

You can use GetAuthenticationStatus or listen for SteamNetAuthenticationStatus_t to monitor the status.

Returns the current value that would be returned from GetAuthenticationStatus.

pub fn create_poll_group(&self) -> NetPollGroup<Manager>

Create a new poll group.

You should destroy the poll group when you are done using DestroyPollGroup

pub fn get_authentication_status( &self ) -> Result<NetworkingAvailability, NetworkingAvailabilityError>

pub fn get_connection_info( &self, connection: &NetConnection<Manager> ) -> Result<NetConnectionInfo, bool>

Returns basic information about the high-level state of the connection.

Returns false if the connection handle is invalid.

pub fn get_realtime_connection_status( &self, connection: &NetConnection<Manager>, lanes: i32 ) -> Result<(NetConnectionRealTimeInfo, Vec<NetConnectionRealTimeLaneStatus>), SteamError>

Returns a small set of information about the real-time state of the connection and the queue status of each lane.

On entry, lanes specifies the length of the lanes array. This may be 0 if you do not wish to receive any lane data. It’s OK for this to be smaller than the total number of configured lanes.

pLanes points to an array that will receive lane-specific info. It can be NULL if this is not needed.

pub fn configure_connection_lanes( &self, connection: &NetConnection<Manager>, num_lanes: i32, lane_priorities: &[i32], lane_weights: &[u16] ) -> Result<(), SteamError>

Configure multiple outbound messages streams (“lanes”) on a connection, and control head-of-line blocking between them. Messages within a given lane are always sent in the order they are queued, but messages from different lanes may be sent out of order. Each lane has its own message number sequence. The first message sent on each lane will be assigned the number 1.

Each lane has a “priority”. Lower priority lanes will only be processed when all higher-priority lanes are empty. The magnitudes of the priority values are not relevant, only their sort order. Higher numeric values take priority over lower numeric values.

Each lane also is assigned a weight, which controls the approximate proportion of the bandwidth that will be consumed by the lane, relative to other lanes of the same priority. (This is assuming the lane stays busy. An idle lane does not build up “credits” to be be spent once a message is queued.) This value is only meaningful as a proportion, relative to other lanes with the same priority. For lanes with different priorities, the strict priority order will prevail, and their weights relative to each other are not relevant. Thus, if a lane has a unique priority value, the weight value for that lane is not relevant.

Example: 3 lanes, with priorities { 0, 10, 10 } and weights { (NA), 20, 5 }. Messages sent on the first will always be sent first, before messages in the other two lanes. Its weight value is irrelevant, since there are no other lanes with priority=0. The other two lanes will share bandwidth, with the second and third lanes sharing bandwidth using a ratio of approximately 4:1. (The weights { NA, 4, 1 } would be equivalent.)

Trait Implementations

impl<T> Send for NetworkingSockets<T>

impl<T> Sync for NetworkingSockets<T>