Networking Information

Resonite is a feature rich engine that is connected both to other users and the Resonite cloud services. If you're concerned or have a firewall you'd like to configure then read on to find out more.

HTTP & WebSocket Traffic

Things like messages, profile information and items in your inventory are all stored within the Resonite cloud. Your copy of Resonite will use HTTP(S) or WebSockets to retrieve this information.

Here is a list of places you might see connections to:

• Most HTTPS Traffic is from api.resonite.com
• SignalR (real time updates) makes a WebSocket connection to the Microsoft managed service also at api.resonite.com
• Assets (avatars, meshes, textures etc.) and other blobs (large files) come from a variety of hosts:
  • Asset variants are stored at variants.resonite.com and skyfrost-archive.resonite.com/variants
  • Assets are stored at assets.resonite.com and skyfrost-archive.resonite.com/assets
  • Thumbnails are stored at thumbnails.resonite.com and skyfrost-archive.resonite.com/thumbnails

Session Traffic

When you connect to a Resonite session, you're starting a connection to the session's host. This is usually another user's computer but sometimes can be a headless session which could be hosted in a number of places - two of the most common ones being on someone's spare computer or on a computer rented in a data center.

Depending on your settings and the settings of the session host you'll connect with either one of the following protocols:

• LNL (LiteNetLib)
• Steam Sockets. Sometimes called "Steam Networking Sockets", "Steam Network", "SNS" etc.

LNL

• LNL uses UDP to connect.
• Ports will vary and can be any port depending on the host as it lets the host pick a free port
• In other cases a relay will be used.
• After punch-through or relay, the actual connection to the user can be any IP or port.

Steam Sockets

Steam Sockets is a Valve created networking protocol. You can find information on it here

Establishing Connections

Resonite utilizes multiple methods to attempt to connect users to sessions on remote machines. This can be illustrated in the following flow chart.

Flow chart showing the decision making process for connecting users.

Resonite will attempt to directly connect users where it can, for example over a LAN. However, this is not always possible due to a variety of network security constraints.

Direct IP

In general, direct IP is best. You’re connecting directly with the remote server and are telling Resonite exactly where to go and how to get there (you are connecting with a direct IP address or domain name).

To use direct IP

• Use an OpenWorld ProtoFlux node and add a Uri (purple input second from top) with the IP address and port like this: lnl://<IPv4 address>:<Port>/
  • For IPv6, wrap the address in brackets lnl://[<IPv6 address>]:<port>/
  • You can also use a DNS record for this - lnl://<domain>:<port>/
• A port is currently required as part of the URL
• This is mostly applicable to headless sessions where the session has a static IP address and port. Keep an eye out for session owners providing items that include direct links for their worlds as that will be the most reliable and expedient way to connect to said world.

As an example for a session hosted with the IPv4 address 203.0.113.7, IPv6 address 2001:db8::7, the DNS record seven.example.com on port 12100:

lnl:///203.0.113.7:12100/: IPv4 direct connection

lnl://[2001:db8::7]:12100/: IPv6 direct connection

lnl://seven.example.com:12100/: DNS direct connection

UDP Hole Punching (LNL NAT Punchthrough)

UDP hole punching is used by LNL in Resonite in order to establish a bidirectional connection between you and a session host where Network Address Translation (NAT) is in play on one or both sides of a connection.

This is facilitated by one of Resonite's LNL punchthrough servers (the same hosts that can be seen in #LNL Relay), where both you and the host establish a connection in order to establish a peer to peer connection between you and the host that should be indistinguishable from directly connecting.

If you encounter issues with NAT punchthrough, you may be behind a Strict (also known as Type 3) NAT, where the conditions of the NAT make it so hole punching doesn't work.

You can check your NAT type by going to https://networktest.razortune.com/ in a web browser - this is a tool hosted by community member Rucio and is specific towards Resonite networking.

If your NAT type is Strict, there are two common causes for this:

• Your router could have settings in place for its NAT causing this to happen - what you want is a 1:1 NAT or a static NAT (terminology may differ depending on router)
• Your ISP could be doing CGNAT in a way that causes this - you can see if you're behind CGNAT by checking what your router reports your WAN address as being and what a site like https://ipinfo.io says; if these two addresses differ, you're likely behind CGNAT.

If it's your router:

Check your router settings - a good way to start is by searching "<router> Open NAT" and seeing what comes up setting wise.

If it's your ISP:

You may be able to contact your ISP to get them to either take you out from behind CGNAT or give you a static, public IPv4 address. This may come at a cost for something like a static IP.

If you're unable to resolve being in a strict NAT situation, it is recommended to use #Direct IP connections followed by using the #LNL Relay to connect to sessions.

Possible Bugs

• One current issue seems to be that the NAT punchthrough server occasionally does not respond very quickly, and the client does not always wait for a response and tries the next protocol on it’s internal list to attempt.

• The punchthrough server does not support IPv6, instead only supporting IPv4. Some ISPs in some parts of the world, such as Japan, use exclusively IPv6. Users in these networks may not be able to use NAT punchthrough (this gets very complicated very quickly, results will vary). (Github Issue #143)

LNL Relay

This can come with performance implications. The relay acts as a third point between both clients, and all traffic is routed through it. Ping will likely be worse here (but not always). If the relay has issues or is overloaded, you may also get service issues.

• We have the following LNL Relays
  • uswest1.resonite.com - US West (Hillsboro, OR)
  • au1.resonite.com - Oceania (Sydney, Australia)
  • japan1.resonite.com - Asia Pacific (Tokyo, Japan)
  • europe.resonite.com - Europe (Helsinki, Finland)

You can see the status of these relays at https://status.yellowdogman.com or in a raw format at https://api.resonite.com/networknodes

How LNL Relays Work

When a relay is required, the client sends a request to https://api.resonite.com/networknodes to retrieve the currently available relays. From there, the client makes a determination based upon multiple factors which relay is the best one for it to utilize. For example, the relay's currently available capacity, and its ping. The ports for the relay are determined by the relay server's operating system and port availability. Do not assume any consistency for the relays.

Here's a diagram illustrating the relay connection flow:

{{Diagram:LNLRelayConnection/Template:TRANSLATIONLANGUAGE}}

At this time, we do not support the ability to pick a specific relay.

Recommendations for Headless Servers

To better support direct connection conditions it is suggested server hosts try to promote direct IP connections and IPv6 support.

If you have a public IPv4 address that you can use, you can port forward the session's port. To do this, set the forcePort option for the world in your headless config file & forward the port through your router. You can find out how to do this by searching "<Router Model> port forward" - for most routers, you'll be able to find an example somewhere on the internet.

If you have IPv6 support, use it when possible by setting forcePort as in the IPv4 example, allowing the session's port through your firewall & direct connecting (See #Direct IP for how to directly connect to a session)

You may not be to port forward in all situations, such as if you're using a router that doesn't let you port forward or if you're behind CGNAT.

If you are behind CGNAT (Carrier Grade NAT), see if you can get off it - depending on your ISP and the type of your internet connection, you may get varying results. Some will take you off CGNAT if you ask, some will get you to pay for a static IP address and some may not allow you to get off CGNAT at all.

If you're having users with issues connecting via LNL punchthrough, direct them to directly connecting to your session. Making an object that connects them - such as a button that they can press and just connect makes doing this quite easy.

Recommended Router Configuration

Many consumer routers are configured by default to provide optimal connectivity for Resonite by routing traffic in such a way which permits the ability for users to directly establish a connection to other users on the Internet. However, some advanced routers employ a type of NAT (Network Address Translation) where port numbers are not preserved when communicating with other hosts on the internet. This type of NAT is often referred to as strict, or “Type-3”. As the name implies, the strict nature of this type of NAT does not permit the ability to establish connections with other users.

For the best Resonite experience, it is recommended to configure your router in such a way to permit a moderate or Type-2 NAT from the computer running Resonite. Each manufacturer implements this configuration differently and the terminology is not often the same between brands. Please refer to the documentation for your particular router or ask for assistance in the #questions-help forum in the Resonite Discord server.

LNL Relay Support for Strict NAT

Resonite provides a method for users who are using a router with strict NAT to connect to other users by using an intermediary server known as the Resonite LNL Relay. Although this solution will work for occasional use, it may not provide the best performance depending on geographic location and network load/congestion.

You can determine if you are connecting through an LNL Relay by the presence of the “LNL Relay” text appearing under the “Loading…” message while joining a world. The presence of the “LNL Relay” text when joining a world means that Resonite was unable to connect to the host user directly and the Resonite LNL Relay server was used.

The presence of the “LNL Relay” text typically indicates that either you, the host user, or both users may be behind a strict / Type-3 NAT. If you see this message each time you connect to a world, there is a good chance that you are behind a router that is configured for strict / Type-3 NAT.

It is recommended to use a moderate or Type-2 NAT to avoid the dependency on using the LNL Relay. See the Router Configuration section above for more information.

uPNP/NAT-PMP and Port Forwarding

Resonite does not currently offer support for port forwarding or uPNP/NAT-PMP.