Protocols

A Client MUST be using the same protocol as the Server it is connecting to, and a Server MUST be using the same protocol as the Clients connecting to it. There is no difference between the two protocols as far as code and implementation goes, it only (rather noticeably) changes the back-end operations of the Networking session.

TCP

The TCP Protocol is the slower of the two protocols, but it ensure that the data is received in full and in order, and depending on configuration, without corruption (set TcpNoDelay to false for corruption checking and fixing, but this slows the connection noticeably!). However, TCP is incredibly slow compared to UDP. This is ideal for chat applications, file transfer applications, remote management, web, or other data that can be transmitted at a slower rate. If it doesn't need to be real-time (such as streaming, voice chat, or video games) then it is recommended to use TCP. TCP is a global standard protocol and can be used across any program using TCP.

UDP

The UDP Protocol is the fastest protocol available in the engine. It makes no guarantee that the data will even be received, and it is possible to receive corrupted or incomplete data, and data can be received in incorrect order (working on a solution for this, keep eyes out for future updates). However, it is incredibly fast, easy, and efficient. It is recommended to use UDP only for real-time applications such as streaming services, voice chat applications, or video games. UDP is a global standard protocol and can be used across any program using UDP.

rUDP

This feature is currently under development and does not work as of right now. The rUDP protocol (Reliable UDP) is a slightly customized protocol that is specific to this engine, meaning that both the Server and this Client must be using this networking engine to communicate, that works in the same was as regular UDP, but ensures that data is received in the correct order. rUDP most likely will not attempt to retrieve missing or corrupted data, but this may change as the protocol reaches production stage of development. Unlike TCP and UDP, this protocol allows for reverse-compatibility with the UDP protocol, meaning that the client can connect to a server using either UDP or rUDP, and the engine will recognize if the Server being connected to supports rUDP. If so, the Server and Client will communicate using rUDP. If the Server does not support rUDP, then the Client will log this information and continue connecting using regular UDP. If a Client connecting to a rUDP Server does not support/use rUDP, the Server will log this information and continue the connection using regular UDP.