kNet Transport over TCP

kNet Transport over TCP

It is possible to run kNet connections on top of TCP. This has the following advantages over using UDP:

• A restricting firewall may block UDP connections, which makes kNet over UDP impossible.
• A poor ISP may consider UDP communication as P2P traffic and serve it with lower priority than TCP, throttle the maximum bandwidth, or even scramble it.
• Traditional TCP congestion control is applied, which is the method most routers are optimized for.

However, using kNet in TCP mode has the following limitations:

• No support for out-of-order messaging. This results in increased latency in the presence of packet loss.
• No support for unreliable datagrams, which makes TCP a poor fit for streaming lossy real-time content.
• Message prioritization is more difficult since the outbound TCP send queue cannot be modified after data is submitted to it.
• Because of the same reason as above, no support for late data choice.
• No support for multiple virtual communication channels, or other message dependency modelling methods.
• The server cannot operate in stealth mode.

kNet over TCP implements RTT estimation and fragmented transfers in a similar way to when using kNet over UDP. However, these two transport methods are not equivalent in features. For example, kNet over TCP does not support UDP features such as InOrder Messages, Flow Control or Session Management.

TCP Stream Byte Format

The byte format used for serializing messages in the TCP stream differs somewhat from the UDP counterpart and is very straightforward. The data if formed by simply concatenating the following Message Block fields one after another until the connection is closed. There are no headers or data bytes at the start of the stream or in between the Message blocks.

Message Block Format.

VLE-1.7/1.7/16     ContentLength. Specifies the length in bytes of the MessageID and Payload fields.
VLE-1.7/1.7/16     MessageID.
.Payload.          The actual data of the message.

To understand VLE-encoding, refer to Zero Truncation using Variable-Length Encoding.

Connection Control Messages

When using kNet over TCP, the messages PingRequest and PingReply are used in the same manner as specified by Round-Trip-Time Estimation. The messages FlowControlRequest, PacketAck, Disconnect, DisconnectAck, ConnectSyn, ConnectSynAck and ConnectAck are not used, but the MessageID values associated with them are still reserved for other use.