#[repr(C)]pub struct SteamNetConnectionRealTimeStatus_t {Show 14 fields
pub m_eState: ESteamNetworkingConnectionState,
pub m_nPing: c_int,
pub m_flConnectionQualityLocal: f32,
pub m_flConnectionQualityRemote: f32,
pub m_flOutPacketsPerSec: f32,
pub m_flOutBytesPerSec: f32,
pub m_flInPacketsPerSec: f32,
pub m_flInBytesPerSec: f32,
pub m_nSendRateBytesPerSecond: c_int,
pub m_cbPendingUnreliable: c_int,
pub m_cbPendingReliable: c_int,
pub m_cbSentUnackedReliable: c_int,
pub m_usecQueueTime: SteamNetworkingMicroseconds,
pub reserved: [uint32; 16],
}
Expand description
Quick connection state, pared down to something you could call more frequently without it being too big of a perf hit.
Fields§
§m_eState: ESteamNetworkingConnectionState
High level state of the connection
m_nPing: c_int
Current ping (ms)
m_flConnectionQualityLocal: f32
Connection quality measured locally, 0…1. (Percentage of packets delivered end-to-end in order).
m_flConnectionQualityRemote: f32
Packet delivery success rate as observed from remote host
m_flOutPacketsPerSec: f32
Current data rates from recent history.
m_flOutBytesPerSec: f32
§m_flInPacketsPerSec: f32
§m_flInBytesPerSec: f32
§m_nSendRateBytesPerSecond: c_int
Estimate rate that we believe that we can send data to our peer. Note that this could be significantly higher than m_flOutBytesPerSec, meaning the capacity of the channel is higher than you are sending data. (That’s OK!)
m_cbPendingUnreliable: c_int
Number of bytes pending to be sent. This is data that you have recently requested to be sent but has not yet actually been put on the wire. The reliable number ALSO includes data that was previously placed on the wire, but has now been scheduled for re-transmission. Thus, it’s possible to observe m_cbPendingReliable increasing between two checks, even if no calls were made to send reliable data between the checks. Data that is awaiting the Nagle delay will appear in these numbers.
m_cbPendingReliable: c_int
§m_cbSentUnackedReliable: c_int
Number of bytes of reliable data that has been placed the wire, but for which we have not yet received an acknowledgment, and thus we may have to re-transmit.
m_usecQueueTime: SteamNetworkingMicroseconds
If you queued a message right now, approximately how long would that message wait in the queue before we actually started putting its data on the wire in a packet?
In general, data that is sent by the application is limited by the bandwidth of the channel. If you send data faster than this, it must be queued and put on the wire at a metered rate. Even sending a small amount of data (e.g. a few MTU, say ~3k) will require some of the data to be delayed a bit.
Ignoring multiple lanes, the estimated delay will be approximately equal to
( m_cbPendingUnreliable+m_cbPendingReliable ) / m_nSendRateBytesPerSecond
plus or minus one MTU. It depends on how much time has elapsed since the last packet was put on the wire. For example, the queue might have just been emptied, and the last packet placed on the wire, and we are exactly up against the send rate limit. In that case we might need to wait for one packet’s worth of time to elapse before we can send again. On the other extreme, the queue might have data in it waiting for Nagle. (This will always be less than one packet, because as soon as we have a complete packet we would send it.) In that case, we might be ready to send data now, and this value will be 0.
This value is only valid if multiple lanes are not used. If multiple lanes are in use, then the queue time will be different for each lane, and you must use the value in SteamNetConnectionRealTimeLaneStatus_t.
Nagle delay is ignored for the purposes of this calculation.
reserved: [uint32; 16]
Trait Implementations§
source§impl Clone for SteamNetConnectionRealTimeStatus_t
impl Clone for SteamNetConnectionRealTimeStatus_t
source§fn clone(&self) -> SteamNetConnectionRealTimeStatus_t
fn clone(&self) -> SteamNetConnectionRealTimeStatus_t
1.0.0 · source§fn clone_from(&mut self, source: &Self)
fn clone_from(&mut self, source: &Self)
source
. Read more