Class Constants

Namespace

BSGameLib.Networking

Assembly

BSGameLib.Networking.dll

Limits and timings that the transports use. They are fixed, not configurable.

public static class Constants

Inheritance

object

Constants

Inherited Members

object.Equals(object)

object.Equals(object, object)

object.GetHashCode()

object.GetType()

object.MemberwiseClone()

object.ReferenceEquals(object, object)

object.ToString()

Fields

BufferSize

The size in bytes of a network read buffer. Nothing in the library reads it at present.

public const int BufferSize = 1024

Field Value

int

IdleTimeout

How long a peer may fail to acknowledge anything before the connection is declared lost.

public static readonly TimeSpan IdleTimeout

Field Value

TimeSpan

Remarks

Four KeepAliveInterval probes, so a live connection survives a few lost PINGs and a dead one is reported after about this long. Because both peers ping, neither side's idle timer is ever restarted by its own traffic alone -- only the peer's acknowledgement restarts it, which is what makes this detect death rather than mask it.

Measured on loopback, a silent peer was reported at 20 seconds for every setting from 20 up (20, 30, 45 and 60 were tried), so a larger value does nothing; a smaller one is reported a few seconds late (10 gave 14). Changing the keep-alive did not move the 20 seconds either. The cause is not known. 20 is the value that means what it says.

KeepAliveInterval

How often each peer sends a QUIC PING to prove the other end is still there.

public static readonly TimeSpan KeepAliveInterval

Field Value

TimeSpan

Remarks

QUIC has no reset packet: a peer that loses power is indistinguishable from a peer that simply has nothing to say. The only way to tell them apart is to probe and wait, so the transport probes continuously and treats silence in reply as death.

These are deliberately not configurable. Detecting that a connection is gone is the transport's job and a consumer cannot do it -- it has no visibility of acknowledgements. Deciding that a connection which is demonstrably alive has been quiet for too long is a different question, it is application policy, and it belongs in a timer over application activity rather than in the transport.

MaxFrameSize

Largest reliable frame this peer will accept, in bytes.

public const int MaxFrameSize = 33554432

Field Value

int

Remarks

The framing layer reads a 4-byte length off the wire and then allocates a buffer of exactly that size. Without a bound, any peer -- a hostile client, or a server a player merely connected to -- can make the other end try to allocate up to 2GB by sending four bytes, with no obligation to ever send the payload. That is a trivially cheap out-of-memory attack in both directions.

32MB is set against the largest thing that legitimately crosses this path: a custom asset delivered whole in one frame (Odyssey's tile atlases are ~4MB, music can be tens of MB). If a game needs more than this, the right fix is chunked transfer, not a bigger number -- a single frame this large is already a 32MB allocation per message in flight.

PingInterval

How often each end times a round trip to the other. Often enough that a latency figure is current; seldom enough that twelve bytes each way are nothing.

public static readonly TimeSpan PingInterval

Field Value

TimeSpan