[Résolu]Network - Le client se connecte sans serveur

[kerkael]

Bonjour

Hier je suis chez moi, j'ouvre le port UDP de mon routeur pour faire des tests client/serveur ... et ça marchait.

Aujourd'hui je suis au bureau. Pour m'amuser, je relancer mon application client, qui essaye de se connecter à l'IP de ma maison, et bizarre : Ca marche ! Enfin, le client dit qu'il a établi une connexion.

Code client

Code : Tout sélectionner

ConnectionID = OpenNetworkConnection("85.168.38.240", Port,#PB_Network_UDP)

En fait, le client me donne une ConnectionID ... est-ce qu'il faut que je comprenne que mon routeur à la maison, toujours allumé avec la même IP et acceptant le port indiqué pour le rediriger en interne permet effectivement la connexion, mais le client n'a pas besoin d'un retour de mon Appli serveur pour dire OK ?

Si le routeur a accepté la connexion, alors le client est content ?

Comment faire comprendre au client qu'il n'a PAS trouvé le serveur ?

Ça a un rapport avec le choix de UDP plutôt que TCP ?

Merci de votre aide.

[scaraber]

Code : Tout sélectionner

Comment faire comprendre au client qu'il n'a PAS trouvé le serveur ? 

Tu fait une petite boucle avant d'entrer dans la boucle principale qui tourne jusqu'a reception d'un paquete indiquand que le client est bien connecter

[kerkael]

Merci.

Est-ce que ça signifie que lorsqu'une connexion est établie, le client ne vérifie pas qu'il reçoit un commit de cette connexion, que le serveur n'envoie rien non plus ?
Il faut vraiment envoyer manuellement ces paquets et les vérifier ?

[Cls]

Oui ça a un rapport sur le choix du protocole UDP.

Comme UDP n'est pas un mode connecté, la connexion n'est pas réellement établie avec le serveur. Il renvoi donc toujours un identifiant. En mode TCP, la connexion étant réellement établie lors de l'appel à OpenNetworkConnection(), elle peut échouer et renvoyer 0

[kerkael]

Okay, j'avais choisi UDP au départ parce que je n'avais pas réussi à ouvrir le TCP sur mon routeur, sans savoir l'impact sur la connexion réelle ou non.

Bon, j'ai regardé sur le ouaib pour voir les différences entre TCP et UDP. UDP est donc un mode déconnecté.

Si je veux créer une appli client serveur, pour quelle raison utiliser UDP ?
Est-ce que ca permet à mon client de ne pas se planter si jamais le serveur est déconnecté ? Dans ce cas, lorsque le serveur revient, la connexion qui avait été établie la première fois reste exploitable sans que le client ne relance quoi que ce soit ?
Alors que TCP nécessite forcément que le client et le serveur soient liés en permanence, et une fois la connexion perdue, il faut en ouvrir une nouvelle ?

Si c'est bien cela, est-ce qu'il y a d'autres raisons, de sécurité par exemple, d'utiliser de l'UDP plutôt que du TCP ?

M'ci de vos précisions.

[Cls]

Le principal avantage d'UDP par rapport au TCP est la petite taille de ses datagrammes. Il nécéssite moins de bande passante.

Le gros inconvénient est qu'il ne fournit aucune garantie sur l'arrivée du paquet ou non. TCP intègre un protocole de contrôle qui permet de savoir si un paquet est arrivé, et de la retransmettre si besoin (paquet non arrivé ou erroné).

Dans une application client serveur, tu peux utiliser les 2 protocoles : TCP pour les données sensibles qui doivent absolument arriver ; UDP pour les gros flux des données qui ne nécessitent pas forcément de tous arriver (je pense aux déplacements dans un jeu online par exemple).

Si lors de la transmission, la connexion est perdue pour X raisons, le client continuera à envoyer si tu es en UDP. Il est souvent nécessaire de programmer son propre mécanisme de contrôle (via ICMP par exemple) lors de l'utilisation d'UDP.

De manière générale je t'encourage à utiliser TCP car il fournit tout les mécanismes nécessaires à la bonne réception des paquets.

[kerkael]

Super !

Merci pour ces précisions.