[RESOLU] [DB-RS] Peut-on envoyer une information à la connexion ?

[Autodidactelife]

Bonjour à tous !

Je viens poser la question car j'avais eux un échange ici même, mais ça reste vague pour moi.
Je voulais juste une confirmation du faite qu'on ne pouvait rien envoyer au serveur Unity durant la connexion du client et que niveau serveur nous ne pouvons rien faire avant d'accepter la connexion ?

La seule façon de faire une identification avec logins c'est de faire son propre échange socket on est d'accord?
On ne peut pas envoyer ne serais-ce qu'un int qu'on pourrait lire et vérifier avant d'accepter la connexion?

Merci !

Cordialement !

[Farstone]

Oui c'est exact, je ne connait pas la réponse exact mais même en regardant un peu dans les sources de bibliothèque low level, c'est toujours plusieurs message qui sont envoyé (donc le socket ne change pas la règle), dont 1 qui sert à atteindre le serveur en premier, j'avais même posté un message sur le forum de Unity officiel qui ma confirmé qu'il en fallait plusieurs pour UNET HLAPI. Donc t'inquiète pas trop et envoie un autre packet quand la connexion est établie pour le client (pourquoi surcharger le serveur). Si le client trafique les sources pour ne pas l'envoyer, le serveur ne l'accepteras tout simplement jamais

[Autodidactelife]

Niveau trafique des sources je n'ai pas vraiment peur pour ça.
Mais le soucis c'est que la seule façon de faire ça c'est de:

- Connecté le client au serveur
- Envoyer un message au serveur pour s'identifier
- Accepter ou kick

La seule sécurité pour pas qu'une personne soit connecté sans être identifier c'est déjà de mettre juste un gameObject avec un script de connexion pas de joueur et d'auto kick au bout de 1s par exemple (Je pars du principe qu'une mauvaise connexion à un ping en moyenne de 400, sachant qu'un ping c'est un aller retour, ici il faut juste que le serveur récupère l'info donc un simple aller client > serveur (même si il y à une réponse du serveur évidemment) mais le serveur à partir de là ne kickera pas.)

Et il y à un très gros soucis à ce niveau, dès que le client est connecté au serveur avant même d'envoyer le message d'identifiant si il bidouille il peut avoir accès à TOUTES les informations charger sur Unity c'est à dire:

Tout ce qui est synchronisé il à accès (joueurs, variables sync (pseudo, position, rotation etc etc). Donc il à accès à une vision complète en direct avant la connexion.
Même si on veut faire un ban IP, on est obligé de vérifier l'IP après la connexion donc là encore la personne peut toujours avoir accès entièrement au serveur.

Donc je vais pas faire de jeux en ligne à moins que ce sois un jeu open (à la slither.io et tout les jeux du même genre).

Merci pour la réponse ^^



Edit1: Bien évidemment quand je parlais "d'envoie avant connexion" la première chose évidente à faire est une ... Connexion
Mais une fois la connexion établie ça aurait était bien qu'Unity lance une fonction de connexion en premier qui retourne une boolean pour accepter ou non la connexion (avec les infos de base tel que l'ip).

Ensuite une fois accepter on peut côté client si réponse de la connexion alors tel fonction et là on vérifie si elle à était accepter ou refuser, si accepter on envoie un message au serveur.

Le serveur vérifie les infos (logins ici) et si il les acceptes alors il lance la synchro avec ce joueur.

Ce qui est dommage aussi c'est que ça aurait était presque possible, il aurait suffit de faire un échange socket basique sans à avoir gérer le serveur et si accepter alors déconnexion et reconnexion au serveur cette fois. Je ne sais pas si c'est possible mais je penses que si on à l'ip et le port du serveur on peut directement y accéder ...


Edit2: Et sinon si Unity permettait de ne pas sync une connexion avec un joueur et qu'on puisse manuellement autoriser le sync, ça aurait était aussi parfait

[Farstone]

Je ne sait pas si tu te rappel de ma mise en garde au niveau de HLAPI, mais je pense que tu est là ou ça commence à devenir embêtant, je suppose que tu utilise HLAPI avec le NetworkManager. Si j'ai bien compris, quand tu te connecte avec le client, le serveur autorise automatiquement la connexion et permet au joueur d'avoir accès aux informations public du serveur (public dans le sens "visible par tout les joueurs sensé être autorisé") si c'est bien le cas alors tu va devoir envisager un changement pour le système hybride de UNET qui consiste a crée ton propre NetworkManager grâce au MessageBase comme ça tu a un contrôle de t'es clients. Ou tu peux aussi utiliser une bibliothèque high level comme Forge, ou une low level comme UNET LLAPI ou LiteNetLib (je te déconseille tout ce qui est UNET), c'est à prendre avec des pincettes car je ne connait pas ton problème à 100%, dans tout les cas si tu utilise le NetworkManager, c'est perdue d'avance pour plusieurs raisons. J'ai aussi fait cette erreur (le système hybride de UNET avait aussi c'est limites) a toi de réfléchir quel chemin tu veux prendre

[Autodidactelife]

Exactement, justement j'ai un peu tout mélanger et je préférais avoir la certitude justement en posant la question correctement

Je vais noter tout ça, en tout cas ça me permet d'être fixer sur une 2eme chose, je ne sais pas la différent UNET HLAPI etc, je vais un peu me renseigner dessus et voir du côté UNET.

Je note tout ça et j'y reviendrais plus tard, ça à l'air simple si on fait les échanges avec les messagesbases, je ne sais pas si j'utilisais de la bonne façon mais ce que j'utilisais pour envoyer un message dans le chat par exemple, ça vérifier si c'était une commande local, si non ça envoyait et le serveur vérifier si c'était une commande serveur, les autorisations si nécessaire et sinon il envoyait le message dans le tchat en RCP.

J'utilisais aussi pour les messages d'erreur à la connexion, envoyer l'inventaire au joueur etc.

Bref, je vais me renseigner dessus, juste pour un peu chatouiller et apprendre.

Merci encore

Edit: Ah ouai je crois c'était toi aussi qui m'avait parler pour vérifier les déplacements, car j'avais utilisé le système du remplacement du callback3D, je vérifier directement dans la fonction si le déplacement est légit, comme le serveur l'a en direct il peut voir si le joueur ce téléporte ou si il rentre dans un mur et j'avais mis une sync des joueurs à 0,5s je crois, ça évité les saccades des joueurs quand ils marchent, c'était en direct et pas besoin de clientprédiction ^^