kNet is a connection-oriented network protocol for transmitting arbitrary application-specific messages between network hosts. It is designed primarily for applications that require a method for rapid space-efficient real-time communication.

kNet consists of two major specifications. At a lower level, the Transport-level specification defines methods like:

Building on top of that, the Application-level specification, along with a reference C++ implementation, offers most notably the following features:

These two specifications and the reference implementation form a complete base on which to build a networking server+client application. Alternatively, only the Transport-level specification can be used, while replacing the application-level features with a different model. The implementation exposes the library that it uses internally for data serialization, but it is possible to use any other solution as well. There are plenty of choices available: boost serialization, CodeSynthesis XSD, Eet, gSOAP, MFC, Google protobuf, Qt QDataStream, s11n, Poco Serializer, Sweet Persist, tpl, xserial, yaml-cpp, or integrate your own.

Downloadable prebuilt packages of the library or the samples are not yet available. The official source repository of kNet is hosted at https://bitbucket.org/clb/knet/

kNet Transport over UDP

This specification defines the details of kNet Transport layer over UDP.

kNet over UDP offers the following enhancements over raw UDP datagrams:

The major advantages of using kNet over UDP instead of TCP are the following:

The protocol specification was designed keeping in mind the possibility of implementing a certain set of performance-related features. For more details on this, see the C++ reference implementation.

The image below shows an overview of the structural format of a kNet UDP datagram.

kNet_UDP_Structure.png

Structure of the kNet UDP Datagram

kNet Transport over TCP

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

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

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. The structure of the TCP packet can be found below.

kNet_TCP_Structure.png

kNet Transport over SCTP

kNet SCTP is currently quite the same as the kNet TCP so the information located in the TCP section goes here as well.

Example Traffic

The traffic captured in these samples are from port 2350 so remember to change the port in Wireshark Preferences dialog

kNet-UDP-Packets.pcap

kNet-TCP-Packets.pcap

kNet-SCTP-Packets.pcap

Note: The samples contain a lot of packets which the kNet dissector says are unknown. Actually these packets are application specific data from realXtend Naali. These messages are not specified in the kNet specification so they are treated as unknown/appdata. This is because one can send arbitrary application data over kNet so it is impossible to know exactly what kind of data the payload section contains.

Other

The display filter for UDP is udp and knet , for TCP tcp and knet and for SCTP sctp and knet

The port can be changed from the Wireshark preferences dialog. The default port is 2345.

kNet (last edited 2011-11-30 08:04:40 by AlexisLaGoutte)