Bonsoir tout le monde.
Voila j'utile en ce moment les sockets de SFML pour envoyer des scenes 3D créer avec irrlicht par le réseau.
Le but étant au final de pouvoir synchroniser deux machines sur la même scene en 3D, ceci formera le mode observateur de mon futur jeu
La scene 3D est enregistrer dans un fichier sans problème coté serveur.
Je lis le fichier pour mettre tout les caractères dans un string.
Ensuite j'envoie le string par une socket UDP(les TCP me donnant un résultat bien trop lent...).
Sauf que une scene vide sans rajouter aucun meshs et aucun autre paramètres pèse 472 octets.
L'envoi et la reception de la scene vide fonctionne parfaitement.

Maintenant je décide de rajouter un mesh et une camera, le poid en est nettement alourdis : le fichier pèse désormais 7 036 octets (6,87 Ko)
Et lorsque je tente de l'envoyer par UDP... c'est le drame
En fait sa ignore l'envoi, ou plutôt sa envoi une chaîne de caractères vide.
Alors je commence à me poser la question : les socket UDP on-t-ils une limite de données à envoyer ? (en TCP sa fonctionne sans problème, c'est juste lent)

Après quelques recherches tout ce que j'ai trouvé c'est des nombres différents.
Du tout au moins, j'ai vus 1465 octets, 2000, et même 65536 octets.
Du coup je sais plus à combien d'octets je dois limiter(ou découper) mes paquets...


Merci

la différence entre UDP et TCP c'est qu'en UDP il n'y a pas de vérification des données (s'il manque un bout en TCP il est renvoyé).
UDP est plutôt utilisé là où le manque de certaines données n'est pas fatal (comme le streaming).
Tu devrais utiliser TCP car s'il manque qu'un octet à ton fichier il est invalide.

Ok, mais bon à la limite si la scene n'arrive pas ce n'est pas fatal, elle est renvoyer constamment, c'est pour sa que je peut pas utiliser TCP.
Donc est ce que il y a une limite à l'UDP ?
A la limite je peut envoyer la taille à récéptionner en TCP et recevoir le gros en UDP et renvoyer une requête si le recu est différent de ce que renvoie la requête TCP non ?

Non, si tu as besoin de rapidité, dans ton packet tu ajoute au paquet un champ taille et par exemple checksum(très simple à calculer pour pas alourdir le chargement) comme çà tu vérifie facilement si le paquet est bon ou pas.

Ok donc je rajoute la taille a recevoir directement dans le paquet UDP ?
Je ne connaissais pas le checksum, j'ai chercher et je crois avoir vaguement compris.
Donc pour un code avec SFML je dois faire comme sa ?

Envoi côter serveur


Reception côter client



Ensuite je teste dans l'operateur >> si le fichier reconstituer fait bien la taille du premier element du paquet envoyer par le serveur ?
Mais je suis pas sûr que cela règle le problème, car je ne peut pas préciser directement la taille à envoyer a SFML, et je me demande si la lib ne limite pas elle même la longueur des paquet...

EDIT : les operateur << et >> de sfPacket sont surcharger pour pouvoir y stocker le graph, la conversion entre graph à chaine de caractères y est faite dedans.

Non il manque quelque chose, car il faut récupérer la taille du paquet et vérifier qu'elle est conforme:

Mais la vérification de la taille n'est pas le plus important à mon avis, un checksum convient mieux, même simple.

Arf oui j'avais oublier de tester côter client
Ok, je vais faire des teste avec sa.
Sinon là je suis perdu avec ces histoire de checksum, en fait je ne sais pas comment on fait sa et je savais pas ce que c'était jusqu'a ce que tu en parle(je viens juste de voir une définition sur le net...)

Est ce que on pourrait m'expliquer comment sa marche

EDIT : Après quelques teste j'en conclus que les socket UDP de SFML sont limité à un envoi de 1015 octets.
La segmentation des paquets va être inevitable...

EDIT 2 : Il ne faut pas non plus oublier de rajouter + sizeof(string) dans le teste de longueur car j'avais 8 octets de plus que la taille de la chaîne, 4 pour le unsigned int, 4 pour le string