Networking Information/fr

Resonite est un moteur de jeu puissant connecté a ses utilisateurs directement et aux services Cloud Resonite. Si vous êtes curieux ou avez un pare-feu que vous voulez configurer, les informations suivantes peuvent aider.

Traffic HTTP et WebSocket

Les informations comme le profil et objets dans votre inventaire sont stockés dans le Cloud de Resonite. Votre client va utiliser HTTPS ou WebSocket pour obtenir ces informations.

Voici une liste de domaines sur lesquels vous verrez probablement des connexions:

• La plupart du traffic HTTPS est vers api.resonite.com
• SignalR (mises à jour en temps réel) créé une connexion WebSocket vers un service sur api.resonite.com
• Les Assets (avatars, modèles, textures, etc) et autres binaires sont stockés sur une variétés d'hôtes:
  • Les variant d'assets sont stockés sur variants.resonite.com et skyfrost-archive.resonite.com/variants
  • Les assets sont stockés sur assets.resonite.com et skyfrost-archive.resonite.com/assets
  • Les vignettes sont stockées sur thumbnails.resonite.com et skyfrost-archive.resonite.com/thumbnails

Traffic de sessions

Quand vous vous connectez a une session Resonite, vous établissez une connexion vers l'hôte de la session. Généralement, cela est l'ordinateur de l'utilisateur mais dans certains cas, cela peut être un serveur qui pourrait être hébergé n'importe ou; les cas les plus communs étant un ordinateur additional ou un serveur loué en centre de données.

Dépendant de vos options et les options de l'hôte, vous vous connecterez avec l'un des protocoles suivants:

• LNL (LiteNetLib)
• Steam Sockets. Aussi appelé "Steam Networking Socket", "Steam Network", "SNS", etc.

LNL

• LNL utilise UDP
• Les ports utilisés varient et peuvent être n'importe quel port sur l'hôte tant que celui-ci est libre.
• Dans d'autres cas, un relais sera utilisé.
• Après un punch-through ou relais, la connexion s'établira.

Steam Sockets

Steam Sockets est un protocole réseau créé par Valve. Vous pouvez trouver des informations sur celui-ci sur leur site officiel.

Établir des connections

Resonite utilise plusieurs méthodes pour tenter de se connecter a une session. Cela peut être illustré dans le graphique suivant.

Resonite va tenter de se connecter directement quand il peut, par exemple sur un réseau local. Cela n'est cependant pas toujours possible dépendant sur le réseau et sa sécurité.

Connexion directe

En général, une connexion directe est le meilleur cas. Vous vous connectez directement quand Resonite sait exactement ou aller et comment y aller (généralement directement avec une adresse IP, nom de domaine et port ouvert).

Pour utiliser une connexion directe

• Utilisez une node ProtoFlux OpenWorld et ajoutez une URI avec l'adresse IP et port comme cela: lnl://<adresse IP>:<Port>/
  • Pour IPv6, mettez l'adresse entre crochets: lnl://[<adresse IPv6>]:<port>/
  • Vous pouvez aussi utiliser un domaine pour cela: lnl://<domaine>:<port>/
• Un port est demandé et fait partie de l'URI.
• Dans la plupart des cas, cela est utile pour se connecter a un serveur ayant une adresse IP statique et le port ouvert.

Comme exemple, une session hébergée avec l'adresse IPv4 203.0.113.7, l'adresse IPv6 2001:db8::7 et le domaine seven.example.com sur le port 12100:

lnl:///203.0.113.7:12100/: Connexion IPv4 directe

lnl://[2001:db8::7]:12100/: Connexion IPv6 directe

lnl://seven.example.com:12100/: Connexion directe via un domaine

Perforation UDP (NAT Punchthrough LNL)

La perforation UDP est utilisée par LNL dans Resonite pour établir une connexion bidirectionnelle entre l'utilisateur et l'hôte de session, quand l'un d'entre eux est derrière NAT.

Cela est facilité grâce aux serveurs LNL Punchthrough de Resonite (les mêmes hôtes qui peuvent êtres vu sur relais LNL), ou l'utilisateur et l'hôte établissent une connexion pour en établir une pair-a-pair. Cela devrait être indistinguable d'une connexion directe.

Si vous avez des problèmes avec le Punchthrough NAT, vous êtes probablement derrière un NAT Strict (aussi appelé de Type 3) ou la perforation ne fonctionne pas.

Vous pouvez voir quel type de NAT vous avez en visitant https://networktest.razortune.com dans un navigateur web - c'est un outil hébergé par le membre de la communauté Rucio et est fait spécifiquement pour Resonite.

Si votre NAT est strict, il y a deux causes communes:

• Votre routeur peut avoir des options en place qui font que NAT soit en mode strict - vous voulez un NAT 1:1 ou statique (la terminologie diffère de routeurs en routeurs)
• Votre FAI peut avoir CGNAT (example: free.fr) ce qui peut causer cela - vous pouvez voir si vous êtes derrière CGNAT en visitant un site comme https://ipinfo.io et voir sur votre routeur quelle est votre adresse IP. Si les deux addresses diffèrent, vous êtes probablement derrière CGNAT.

Si c'est sur votre routeur:

Regardez dans le options de votre routeur - une bonne manière est de chercher "<routeur> NAT ouvert" et voir quels sont les résultats

Si c'est votre FAI:

Vous pouvez contactez votre FAI pour leur demander soit une adresse IPv4 dédiée publique ou de vous bouger hors de CGNAT. Cela peut parfois venir a un coût additionnel.

Si vous ne pouvez pas résoudre votre situation, il est recommandé d'utiliser une connexion directe suivi par l'utilisation d'un relais LNL pour se connecter aux sessions.

Bugs possibles

• Un bug connu fait que Resonite va tenter la perforation UDP, ne va pas attendre assez longtemps pour la réponse et va directement essayer d'autres méthodes de connexion.

• Le serveur LNL ne supporte pas IPv6, utilisant a la place IPv4 seulement. Certains FAIs, comme au Japon, utilisent uniquement IPv6. Les utilisateurs sur ces réseaux ne pourront pas utiliser la perforation LNL. (Github Issue #143)

Relais LNL

Cette méthode implique des pertes de performance. Les relais agissent come un intermédiaire entre les deux clients et tout le traffic est routé par le relais. La latence est généralement plus haute (mais pas toujours). Si le relais a des problèmes, l'utilisateur l'utilisant souffrira des mêmes problèmes.

• Nous avons les relais suivants
  • uswest1.resonite.com - Ouest USA (Hillsboro, Oregon)
  • 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:

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.