LiteNetLib transport

[willneedit]

Mirror supports pluggable network transports, changing transports needs only changes for the connection establishment. For example, the Steamworks transport needs the Steam AppID, not an IP address.

And I'm seriously considering the LiteNetLib transport ( https://mirror-networking.gitbook.io/docs/manual/transports/litenetlib-transport ) -

Why?

1. UDP, not TCP (maybe some changes for voice transport), lessens impacts of suboptimal networks
2. Better adaptability to the user's network environments (like, MTU detection)
3. NAT hole punching

The catch is, the latest of the Mirror's adaptation of LiteNetLib is from 2020 and from the 0.9.1 LiteNetLib codebase. LiteNetLib is at version 1.2.0 now.

Maybe I have to take the LiteNetLib Mirror as-is, and once it works, I'll have to update the undercarriage to improve, for example, the NAT hole punching.

For the end user?

Little. Better stability, and maybe less to think about - the router considerations would be gone.

[willneedit]

Just as I thought. The Mirror transport adaptation is horribly outdated.

Maybe it's easier to get the current version of LiteNetLib and write the transport interface on my own.

Bleh. ☹

[willneedit]

Easier and better than expected.

• The LiteNetLib core, based from v1.2.0, is just stripped and not modified
• The Transport has been made of an amalgamation from the original LiteNetLibTransport and TelepathyTransport.
• Some code cleanup, and added a configuration option for the NAT hole punching.

Benefits

• Even if UPnP support switched off, both in Arteranos and the router, connections are possible using IPv6, because, no NAT necessary.
• Server operators resorting to IPv4 have to enable UPnP, or to configure port forwarding.
• Client-only users don't need to care about UPnP or port forwarding whatsoever! 😄 😄