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.

HTTP & WebSocket Traffic

Things like:

• Messages
• Profile Information
• Contact Requests
• Your Inventory
• Items in your Inventory & Your Avatar

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
  • Assets are stored at assets.resonite.com
  • Thumbnails are stored at thumbnails.resonite.com

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 another cloud based 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.
  • LNL relay is the same as above but port 12600.
• 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

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

A bug be here: Due to a bug in the current library the direct connection is not attempted and a NAT Punchthrough is attempted instead. This is normally fine, the middle server would end up creating an identical network, if not for the additional bug below.

NAT Punchthrough

This is used when both sides are behind a NAT (Network Address Translation) layer. These layers are common in household routers and modems. Punchthrough allows a connection directly from one peer inside a NAT into another peer inside a different NAT (hence peer to peer). However, doing so requires a middle server that helps build the connection. The process for this is more complex, and has a higher likelihood of failing. Once a connection is established though, it’s as good as a direct connection in terms of performance, only the connection takes a bit of extra effort and can fail based on how the network is set up.

If you encounter NAT Punchthrough issues, you may be behind a strict, or type 3 NAT; see https://portforward.com/nat-types/ To check this, try one of the following:

• If you have Windows 10/11 with
  • Xbox Console Companion - Settings > Network and click Check Again at least once to ensure it runs a proper check on your NAT type
  • Xbox Networking - Click Check Again at least once to ensure it runs a proper check on your NAT type
• If you have a PlayStation 3 or 4
  • Network > Test Internet Connection > NAT Type is Type 3
• If you have a Nintendo Switch
  • Settings > Internet Settings > Test Connection Type… something, thanks Nintendo

If you are behind a type 3, there are two paths you can take to move out of it

• Your router has a strict NAT
  • Update your router's config to not be a strict NAT, this may be called:
  • Moderate type 2
    • Open
    • Strict Port
    • Full Cone
    • Something else, check your router manual
  • Your ISP has put you behind a strict NAT
    • To check this ensure the IP address provided to you by the service provider is the same as your public IP.
    • To get your public address:
      • https://ipv6-test.com/
      • http://test-ipv6.com/
      • https://whatismyipaddress.com/
    • To get your router address you will need to log into the router, this will be specific to the router.
    • If the two addresses do not match
      • check with your ISP if they can move you from behind a NAT
    • If the two addresses match
      • Check the router config,following the guidelines outlined here: https://wiki.Resonite.com/Networking_Information#Recommended_Router_Configuration

A possible bug be here: 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.

Another bug be here: 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).

LNL Relay

This one comes 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)

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 your ISP supports IPv6 using CGNAT
  • turn off CGNAT
  • Use IPv4 PPPoE instead

Port Forwarding:

• Check what port is used in your headless, you can set the port using the “forceport” property of the headless config.
• Configure your network as applicable to forward said port, if UPnP is available this is likely not needed.

Guide users to use Direct IP instead of the relay

• It is suggested headless world hosts make premade objects for this, such as a fancy looking button that summons the user to your world. Make this an elaborate calling card. This is your chance to have a user keep a link to your world in their world, make it pretty!

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 forumin 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.