Forum de la communauté SFML

Aide => Réseau => Discussion démarrée par: Crone123 le Août 07, 2012, 11:32:41 pm

Titre: Socket qui bloque sur NotReady ! / Problème de paquets...
Posté par: Crone123 le Août 07, 2012, 11:32:41 pm
Bonjour,
J'avais déjà parlé de ça, j'ai un bug avec des sockets aussi bien TCP que UDP, il arrive, mais c'est purement aléatoire, c'est a dire que d'une machine a l'autre ça va marcher ou non, que les socket restent bloqués en écoute sur NotReady.

Une fois bloqué, plus moyen de transférer des données..

Donc mon code est bien standard et j'utilise les sf::Packet (mais j'avais déjà le bug sans).
Je suis passé de la 1.6 sur laquelle j'avais le bug a la 2.0 et j'ai toujours le bug.


Donc le socket reste connecté, je l'ai vu avec le TCP je peux encore envoyer des données (en UDP aussi d'ailleurs) et le serveur les reçois et les interprètes, mais le client ne peut plus en recevoir et coté serveur c'est bien indiqué "not-ready"

Il m'est déjà arrivé que le serveur soit bloqué en NotReady temporairement mais ça ne le fait quasiment jamais.

Je précise que les socket sont en "non-bloquant" et les écoutes se font en haut de la boucle principale je ne sais pas si ça peut jouer...

Dans mon cas par exemple avec les pare-feu sur off Ordi1 peut se connecter sur Ordi2 sans pb mais l'inverse ne fonctionne pas, les sockets restent bloqués. (Il va se connecter, mais au bout de quelques données échangées il va se bloquer sur "NotReady")
Et il arrive que lorsque que Ordi1 est connecté sur Ordi2 il ne reçoive plus les positions des autres joueurs parce que le socket UDP est resté bloqué sur "NotReady"....

Quelqu'un a t-il déjà eut le problème?
Quelqu'un sait-il comment le corriger?
Quelqu'un a t-il des conseils a me donner pour éviter ce genre de problèmes ou sur la meilleure utilisation possible des socket? (façon de l'utiliser)
Merci :)

EDIT: J'ai trouvé ça: http://en.sfml-dev.org/forums/index.php?topic=7435.0 qui parle du même problème mais en anglais..je suis en train de le lire pour voir...

EDIT2: En fait non, c'est un autre problème, carrément pas de connexion, enfin, ça m'est arrivé aussi, mais c'est pas mon problème actuel....et il les utilise aussi en non-bloquant et avec un timeout de 0...

EDIT3: Est-ce mieux de mettre les connexion sur Thread en mode bloquant? Ou de les laisser comme maintenant (sans thread) dans la boucle principale? En sachant que j'ai besoin de perfs et que ça ne rame pas (surtout sous Windows, je sais que Linux gère bien les Threads mais sous Windows c'est une horreur....)
Titre: Re : Socket qui bloque sur NotReady !
Posté par: Laurent le Août 08, 2012, 08:21:45 am
Il faudrait un (ou plutôt deux : client et serveur) code complet minimal qui reproduit le problème, afin que nous puissions tester.
Titre: Re : Socket qui bloque sur NotReady !
Posté par: Crone123 le Août 08, 2012, 11:59:24 am
Bah c'est a voir, mais c'est difficile quand on sait que dans un sens ça marche dans l'autre pas....

Ordi1 client → Ordi2 serveur ça peut marcher
Ordi2 client → Ordi1 serveur le socket va vite (0.5s) rester bloqué sur NotReady

Je vais voir si j'arrive a le reproduire en minimal...

Titre: Re : Socket qui bloque sur NotReady !
Posté par: Laurent le Août 08, 2012, 12:17:48 pm
Il faut déjà trouver le facteur déclencheur (volume de données trop important ? envois trop rapides ? ...), et ensuite faire un petit code qui amplifie ce facteur pour être certain de opuvoir reproduire le problème à coup sûr.
Titre: Re : Socket qui bloque sur NotReady !
Posté par: Crone123 le Août 08, 2012, 08:41:08 pm
Et une fois le problème détecté, il faudra trouver une correction: Dans le programme en question, ou dans la SFML?
Titre: Re : Socket qui bloque sur NotReady !
Posté par: Laurent le Août 08, 2012, 08:43:20 pm
Comment veux-tu répondre à cette question avant d'avoir trouvé l'origine du problème ? :P
Titre: Re : Socket qui bloque sur NotReady !
Posté par: Crone123 le Août 08, 2012, 10:33:24 pm
Je ne sais pas, mais la réponse sera soit l'un soit l'autre :)
Titre: Re : Socket qui bloque sur NotReady !
Posté par: Crone123 le Août 09, 2012, 04:05:19 am
J'ai trouvé !
Le socket plante en envoyant un sf::Packet de 8964o.

J'ai diminué le nombre de case de map chargée a la fois (par socket, de 500 et 100), la vitesse est considérablement réduite, je passe de 7s a 40s pour une map de 500*500, la vitesse de chargement passe de 21000cases/s (450 - 500ko/s env) a 6000cases/s (116ko/s)

Je ne sais pas si on peut considérer que 8ko c'est beaucoup sur un socket, parce que plus j'envoie de données d'un coup dans un socket et plus ça se charge vite, et encore, je suis sur réseau local et je ne vais qu'as 500ko/s (avec des socket de 8ko maximum) alors que j'ai un débit maximal de 12.6mo/s, donc monter a 1 ou 2mo ne devrait normalement pas être un problème.

Maintenant, le problème n'est pas partout, donc le bug a l'air de venir des sf::Packet au transfert, mais sur certains ordis ça fonctionne, sur d'autres ça bloque.

Personnellement, j'ai déjà eut des blocages en UDP aussi, je suis obligé de limite faire lagguer le jeu en réseau en mettant les fréquences de rafraîchissement des positions des jours très basse alors que je n'envoie pas grand chose en UDP pour la position des persos, sinon le socket se bloque définitivement.

Quand je vois les autres jeux ce qu'ils peuvent envoyer je me dis que c'est pas trop normal...
Et le http par exemple, ça ne bloque pas sous prétexte que l'on télécharge a plus de 150ko/s (c'est un exemple, mais ça montre que si on arrive a atteindre des débits plus élevés sur le réseau sans bugguer ailleurs c'est que la SFML doit avoir un bug...quelque part..)

Notez que je fais bien attention a ne pas envoyer plusieurs sockets a la fois, c'est a dire que je regroupe tout ce que j'ai besoin d'envoyer a un client dans une variable et j'envoie tout a la fin de l'image, donc ça limite le nombre de socket (y compris en UDP), et pour le chargement de la map (TCP), j'attends une réponse du client indiquant qu'il a bien chargé ce que je lui ai envoyé pour lui envoyer la suite, je n'envoie pas tout d'un coup n'importe comment...

Si ça peut vous aider, voici le PC capable de faire serveur et donc d'envoyer les données, mais pour lequel ça bloque directement si il reçois un socket de 8ko (parfois beaucoup moins..).
Le PC est récent, il date de fin 2009 début 2010:
Il tourne sous Ubuntu 12.04 LTS 64bits (je n'utilises que Linux personnellement, et très rarement Windows..)
Et voici donc le résultat de la commande lspci histoire que vous aillez le détail matériel, par exemple la carte réseau ou autres si ça peut vous servir:
Code: [Sélectionner]
00:00.0 RAM memory: NVIDIA Corporation MCP78S [GeForce 8200] Memory Controller (rev a2)
00:01.0 ISA bridge: NVIDIA Corporation MCP78S [GeForce 8200] LPC Bridge (rev a2)
00:01.1 SMBus: NVIDIA Corporation MCP78S [GeForce 8200] SMBus (rev a1)
00:01.2 RAM memory: NVIDIA Corporation MCP78S [GeForce 8200] Memory Controller (rev a1)
00:01.3 Co-processor: NVIDIA Corporation MCP78S [GeForce 8200] Co-Processor (rev a2)
00:01.4 RAM memory: NVIDIA Corporation MCP78S [GeForce 8200] Memory Controller (rev a1)
00:02.0 USB controller: NVIDIA Corporation MCP78S [GeForce 8200] OHCI USB 1.1 Controller (rev a1)
00:02.1 USB controller: NVIDIA Corporation MCP78S [GeForce 8200] EHCI USB 2.0 Controller (rev a1)
00:04.0 USB controller: NVIDIA Corporation MCP78S [GeForce 8200] OHCI USB 1.1 Controller (rev a1)
00:04.1 USB controller: NVIDIA Corporation MCP78S [GeForce 8200] EHCI USB 2.0 Controller (rev a1)
00:06.0 IDE interface: NVIDIA Corporation MCP78S [GeForce 8200] IDE (rev a1)
00:07.0 Audio device: NVIDIA Corporation MCP72XE/MCP72P/MCP78U/MCP78S High Definition Audio (rev a1)
00:08.0 PCI bridge: NVIDIA Corporation MCP78S [GeForce 8200] PCI Bridge (rev a1)
00:09.0 SATA controller: NVIDIA Corporation MCP78S [GeForce 8200] AHCI Controller (rev a2)
00:0a.0 Ethernet controller: NVIDIA Corporation MCP77 Ethernet (rev a2)
00:10.0 PCI bridge: NVIDIA Corporation MCP78S [GeForce 8200] PCI Express Bridge (rev a1)
00:12.0 PCI bridge: NVIDIA Corporation MCP78S [GeForce 8200] PCI Express Bridge (rev a1)
00:13.0 PCI bridge: NVIDIA Corporation MCP78S [GeForce 8200] PCI Bridge (rev a1)
00:18.0 Host bridge: Advanced Micro Devices [AMD] Family 10h Processor HyperTransport Configuration
00:18.1 Host bridge: Advanced Micro Devices [AMD] Family 10h Processor Address Map
00:18.2 Host bridge: Advanced Micro Devices [AMD] Family 10h Processor DRAM Controller
00:18.3 Host bridge: Advanced Micro Devices [AMD] Family 10h Processor Miscellaneous Control
00:18.4 Host bridge: Advanced Micro Devices [AMD] Family 10h Processor Link Control
02:00.0 VGA compatible controller: NVIDIA Corporation GT216 [GeForce GT 220] (rev a2)
02:00.1 Audio device: NVIDIA Corporation High Definition Audio Controller (rev a1)
04:00.0 FireWire (IEEE 1394): VIA Technologies, Inc. VT6315 Series Firewire Controller
Et le PC pour lequel je n'ai pas eut de problème avec les socket de 8ko, par contre j'ai déjà eut aussi des socket bloqués donc ça arrive aussi dessus, en UDP et a d'autres moment dans le jeu (ça dépends des fois..):
Le PC est aussi récent, il date de mi 2011: (je ne rapporte pas de bugs pour des vielles machines ça n'aurait pas de sens :) )
Il tourne aussi sous Ubuntu 12.04 LTS 64bits
Code: [Sélectionner]
00:00.0 Host bridge: Intel Corporation Core Processor DRAM Controller (rev 18)
00:01.0 PCI bridge: Intel Corporation Core Processor PCI Express x16 Root Port (rev 18)
00:1a.0 USB controller: Intel Corporation 5 Series/3400 Series Chipset USB2 Enhanced Host Controller (rev 06)
00:1b.0 Audio device: Intel Corporation 5 Series/3400 Series Chipset High Definition Audio (rev 06)
00:1c.0 PCI bridge: Intel Corporation 5 Series/3400 Series Chipset PCI Express Root Port 1 (rev 06)
00:1c.2 PCI bridge: Intel Corporation 5 Series/3400 Series Chipset PCI Express Root Port 3 (rev 06)
00:1d.0 USB controller: Intel Corporation 5 Series/3400 Series Chipset USB2 Enhanced Host Controller (rev 06)
00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev a6)
00:1f.0 ISA bridge: Intel Corporation 5 Series Chipset LPC Interface Controller (rev 06)
00:1f.2 RAID bus controller: Intel Corporation 82801 SATA Controller [RAID mode] (rev 06)
00:1f.3 SMBus: Intel Corporation 5 Series/3400 Series Chipset SMBus Controller (rev 06)
01:00.0 VGA compatible controller: NVIDIA Corporation Device 0dc0 (rev a1)
01:00.1 Audio device: NVIDIA Corporation GF106 High Definition Audio Controller (rev a1)
03:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 06)
ff:00.0 Host bridge: Intel Corporation Core Processor QuickPath Architecture Generic Non-core Registers (rev 05)
ff:00.1 Host bridge: Intel Corporation Core Processor QuickPath Architecture System Address Decoder (rev 05)
ff:02.0 Host bridge: Intel Corporation Core Processor QPI Link 0 (rev 05)
ff:02.1 Host bridge: Intel Corporation Core Processor QPI Physical 0 (rev 05)
ff:02.2 Host bridge: Intel Corporation Core Processor Reserved (rev 05)
ff:02.3 Host bridge: Intel Corporation Core Processor Reserved (rev 05)
Voilà, a mon avis le problème viens des sf::Packet qui bien que hyper pratique, ont un problème pour transférer plus de données.
Je ne crois pas avoir déjà eut ce problème avant quand le jeu ne les utilisait pas (il utilisait les chaines standard), par contre le jeu ramait avec les chaines standard qui envoyaient des caractères vides a tout bout de champs, et j'avais d'autres problèmes du a la limite de caractères qui était fixe.

Si je me rappelle bien, quand j'utilisais encode beaucoup Game Develop (il y a environ 1an ou 1an et demi) pour créer mes jeux en 2D (c'est comme ça que j'ai connu la SFML et c'est aussi pour ça que la SFML est la première bibliothèque que j'ai appris a utiliser quand j'ai commencé a programmer en C++), j'avais crée un jeu type TPS pour tester un truc, et j'avais déjà ce bug le jeu n'arrivait plus a recevoir de données, et du au logiciel (GD) ou pas, le jeu freezait même des fois après qu'il ne puisse plus recevoir de données....bon, le freeze ne doit pas venir de la SFML puisque je n'ai pas rencontré ce problème en C++...

Voilà, la SFML 2.0 est en RC ça tombe bien, si vous trouvez ce fameux bug dans les socket ça fera une version 2.0 parfaitement stable :)
Merci :)

PS: J'utilisais Game Develop sous Windows 7 64bits, et j'ai eu le problème avec le premier PC dont j'ai parlé qui testait le jeu avec Wine (Ubuntu 10.04 LTS 64bits), 3 autres PC portables (Ordis avec lesquels j'ai testé le jeu) qui étaient sous Windows 7 64bits et une tour un peu plus ancienne (5 - 6ans) sous Windows Xp 32bits.
J'avais pris soin de faire plusieurs tests même en ne mettant que des PC's portables sous Windows 7 64bits etc pour supprimer les possibles bugs de Wine, et le jeu n'as jamais marché correctement, toujours un moment ou un joueur ne recevait plus rien, si c'était pas plusieurs joueurs....

PS2: J'ai aussi en C++ testé 2 versions de mon serveur, une version graphique, qui affiche tout ce qui se passe sur le serveur en graphique, et une version console (terminal) qui fonctionne de la même façon sans faire les calculs graphiques (en supposant que ça aurait pu ralentir le trafic a cause des calculs), et j'obtiens le même résultat, hors mis que la version terminal consomme évidement beaucoup moins de ressources sur l'ordi.

PS3: J'ai déjà bossé un maximum  sur l'optimisation du jeu, et a chaque fois ça se bloquait sur les socket, quel que soit l'optimisation, aujourd'hui le jeu a un algorithme pour charger dynamiquement les maps sur les clients (en temps réel) et rapidement, et en consommant le moins de connexion possible, disons que maintenant plus on consomme et plus ça charge vite, mais j'ai toujours eu ce bug en utilisant les sockets SFML (TCP/UDP)

L'envoi ne doit pas poser de problèmes, c'est la réception qui pose problème a mon avis puisque c'est celui qui reçoit qui bloque et pas celui qui envoie, et que j'ai testé de connecter plusieurs clients a la fois en même temps, je n'ai pas de perte de vitesse, donc le jeu est capable d'envoyer tout ça sans problèmes sur les 2 clients ça va aussi vite que si ils étaient tout seuls (sinon ça bloquerait coté serveur), et le débit est stable. En revanche la réception doit avoir un bug qui paralyse le socket en cours de réception de données...
Titre: Re : Socket qui bloque sur NotReady !
Posté par: Laurent le Août 09, 2012, 08:15:58 am
Bien :)

Maintenant il ne te reste plus qu'à écrire un client/serveur minimal qui ne fait qu'envoyer des paquets de 8964 octets (je pense que la "vraie" limite est en fait pas loin de 8192). Comme ça je pourrai d'une part vérifier qu'il n'y a aucune erreur dedans, et d'autre part, avec un peu de chance, reproduire le problème chez moi et debugger.
Titre: Re : Socket qui bloque sur NotReady !
Posté par: Crone123 le Août 10, 2012, 02:35:56 am
J'ai fait le code minimal qui bug, j'ai fait quelques tests, donc j'ai déjà des résultats de tests a vous fournir en même temps que le code, c'est d'ailleurs assez intéressant :)
Voici le lien du 7z contenant les sources, une version compilée pour Ubuntu 64 bits avec les .so de la SFML2, 2 fichiers de démarrage (Client et Serveur) pour l’exécutable, et le fichier Readme.txt contenant mon test.
http://dl.smglive.org/Crone123/SF-SOCKET-TEST.7z
env 368ko en 7z, 1.1Mo une fois extrait.

Le fichier StartClient.sh est a adapter, vous devez mettre l'IP de l'Ordi sur lequel vous avez lancé le serveur a la place de celle qui est présente.
Le fichier StartServer.sh n'as pas besoin d'être adapté :)

Note: C'est mieux de lancer le serveur avant de lancer le client, puisque le client va essayer de se connecter dans le vide sinon...

Les sources: (présentes dans l'archive)
main.cpp
#include <SFML/Network.hpp>
#include <string>
#include <sstream>
#include <iostream>
#include <ctime>
using namespace std;

int main(int argc, char * argv[])
{
    bool Continue(true);//Mettre a false = fermer le programme.
    string Mode; //Variable contenant le mode (client ou serveur)
    sf::IpAddress IP;//Variable contenant l'IP, uniquement pour se connecter au serveur.
    int Port(36000); //Variable contenant le port utilisé.

    /** Recuperation des paramètres de commande **/
    if(argc >= 2)
    {
        Mode = argv[1];
    }
    if(argc >= 3)
    {
        IP = string(argv[2]);
    }
    else if(Mode != "--server")
    {
        cout << "Veulliez entrer une IP pour choisir le serveur." << endl;
        return 0;
    }

    /** Test **/
    if(Mode == "--client")
    {
        /** PARTIE CLIENT **/
        sf::TcpSocket Serveur;//Socket pour se connecter au serveur.
        Serveur.setBlocking(false);
        bool connected(false);
        while(Continue)
        {
            if(!connected)
            {
                sf::Socket::Status Rep = Serveur.connect(IP, Port);
                if(Rep == sf::Socket::Done)
                {
                    cout << "Connexion reussie a " << IP.toString() << endl;
                    connected = true;
                    sf::Packet Paquet;
                    Paquet << "<Send>";
                    Serveur.send(Paquet);//On demande un envoi de socket au serveur.
                }
                else if(Rep == sf::Socket::NotReady)
                {
                    cout << "Connexion impossible: NotReady" << endl;
                }
                else if(Rep == sf::Socket::Error)
                {
                    cout << "Connexion impossible: Erreur" << endl;
                }
                else
                {
                    cout << "Connexion impossible: Autre" << endl;
                }
            }
            else //Connnecté !
            {
                sf::Packet Paquet;
                sf::Socket::Status Rep = Serveur.receive(Paquet);
                static int compteur(0);
                if(Rep == sf::Socket::Done)
                {
                    ++compteur;
                    string Tmp;
                    Paquet >> Tmp;
                    cout << time(0) << ": Socket N " << compteur << ": " << Tmp.size() << "o" << endl;
                    Paquet.clear();
                    Paquet << "<Send>";
                    Serveur.send(Paquet);//On demande un envoi de socket au serveur.
                }
                else if(Rep == sf::Socket::Error)
                {
                    cout << time(0) << ": Erreur de reception du socket !" << endl;
                }
                else if(Rep == sf::Socket::Disconnected)
                {
                    cout << time(0) << ": Connexion terminee !" << endl;
                    Continue = false;
                }
            }
            sf::sleep(sf::seconds( 1 / 60)); //Simulation d'un jeu tournant a 60FPS.
        }
    }
    else if(Mode == "--server")
    {
        /** PARTIE SERVEUR **/
        sf::TcpListener Listener;
        if(Listener.listen(Port) == sf::Socket::Done)
        {
            cout << "Ecoute du port: " << Port << endl;
        }
        else
        {
            cout << "Impossible d'ecouter le port: " << Port << endl;
            return 0;
        }
        sf::TcpSocket Client;
        Client.setBlocking(false);
        Listener.setBlocking(false);
        bool connected(false);
        while(Continue)
        {
            static int compteur(0), taille(100);
            if(!connected)
            {
                sf::Socket::Status Rep = Listener.accept(Client);
                if(Rep == sf::Socket::Done)//Client connecté, on prépare l'envoi.
                {
                    cout << time(0) << ": Connexion de: " << Client.getRemoteAddress() << endl;
                    cout << time(0) << ": Envoi de donnees... " << endl;
                    connected = true;
                    taille = 100;
                    compteur = 0;
                }
            }
            else
            {
                sf::Packet Paquet;
                sf::Socket::Status Rep = Client.receive(Paquet);
                if(Rep == sf::Socket::Done)
                {
                    string CT;//Contenu du paquet
                    Paquet >> CT;
                    if(CT == "<Send>")
                    {
                        Paquet.clear();
                        ++compteur;
                        CT.clear();
                        for(unsigned int compteur2(0); compteur2 < taille; ++compteur2)
                        {
                            CT += '1';
                        }
                        Paquet << CT;
                        bool CW(true);//Continue While
                        int N(0);
                        while(CW)
                        {
                            Rep = Client.send(Paquet);
                            if(Rep == sf::Socket::Done)
                            {
                                CW = false;//On quitte la boucle
                                cout << time(0) << ": Envoye: N " << compteur << ": " << taille << "o" << endl;
                                taille += 100;
                            }
                            else if(Rep == sf::Socket::NotReady)
                            {
                                cout << time(0) << ": NotReady: N " << compteur << ": " << taille << "o" << endl;
                            }
                            else if(Rep == sf::Socket::Error)
                            {
                                cout << time(0) << ": Erreur: N" << compteur << ": " << taille << "o" << endl;
                            }
                            if(N == 20)
                            {
                                cout << "Stoppe pour 20 erreur d'affilee !" << endl;
                                CW = false;
                            }
                            ++N;
                        }
                    }
                }
                else if(Rep == sf::Socket::Error)
                {
                    cout << time(0) << ": Erreur de reception du socket !" << endl;
                }
                else if(Rep == sf::Socket::Disconnected)
                {
                    Client.disconnect();
                    connected = false;
                    cout << "Client deconnecte !" << endl;
                }

            }
            sf::sleep(sf::seconds( 1 / 60)); //Simulation d'un jeu tournant a 60FPS.
        }
    }
    else
    {
        cout << "Les options possibles sont --client IP et --server !" << endl;
    }
    return 0;
}

 

Démarrer:
./SF_SOCKET_TEST [mode] [IP]
Mode peut être:
--server (dans ce cas, pas besoin de spécifier IP)
--client (dans ce cas, IP = Serveur auquel se connecter)
Le port est par défaut 36000 est modifiable dans les sources :)

J'ai crée ça avec QtCreator, donc les fichiers .pro etc sont dans l'archive :)

C'est pas du grand code on est d'accord, mais c'est le code minimal qui reproduit le bug :)
Vous pouvez bien entendu l'adapter comme bon vous semble pour vos tests :)

Et le Readme.txt (Pour le cas ou vous n'utilisez pas l'archive...)
Code: [Sélectionner]
Socket sur lequel ça bloque en fonction des conditions:
La taille est progressive, elle commence a 100o et augmente de 100o a chaque nouveau socket.
1 = 100
2 = 200
3 = 300
...
Le sens d'envoi des données va de Serveur vers Client, c'est donc le client qui reçois, et c'est lui qui va bloquer un moment.
Localhost: (AMD Athlon II X2 a 2.7Ghz) (généralement pas de pb en Localhost)
Socket N 5898: 589800o
Durée du test: Environ 10 - 15s

→ A bloqué 1 fois, les plantages sont rares comme je l'ai dit en localhost j'en ai pas vu sur l'I5, et j'en ai eu 1 sur l'AMD Athlon (voir ci dessus) et en laissant tourner quelques minutes j'en ai pas eu d'autres.

A ce test je vois d'ailleurs que l'I5 trace l'AMD Athlon niveau vitesse c'est peut être pour ça qu'il supporte mieux sur le test en Ethernet.

Ils ont dépassé les 30000sockets sans bugguer ensuite en local, rien d'étonnant, en local mon jeu a eu de très rares bugs.







Réseau Local Ethernet a 100Mb: (12.6Mo/s, vitesse réelle [testé])

Ethernet: Ordi1 Serveur (AMD Athlon II X2 a 2.7Ghz), Ordi2 Client (Intel Core I5 Dual-Core avec 2 thread par coeur [4coeurs virtuels] a 3.2Ghz):
Socket N 406: 40600o
Socket N 419: 41900o
Socket N 406: 40600o
Durée du test: 1.5 - 2s environ.

Ethernet: Ordi2 Serveur (Intel Core I5 Dual-Core avec 2 thread par coeur [4coeurs virtuels] a 3.2Ghz), Ordi1 Client (AMD Athlon II X2 a 2.7Ghz):
Socket N 73: 7300o
Socket N 73: 7300o
Socket N 72: 7200o
Durée du test: 1 - 1.5s environ.

Dans les 2 cas, c'est le client qui bloque niveau reception, normal c'est lui qui reçois le plus.
Si vous faites le test dans l'autre sens, c'est a dire serveur qui reçois c'est le serveur qui va bloquer a la reception.
Comme vous le verrez sûrement les tests "local" (127.0.0.1) ne bloquent quasiment jamais....et vous voyez que en fonction de la condition, les tests sont a peu près identiques.

Et sur un PC plus puissant (Le PC avec l'I5 a tout de plus puissant que le PC avec l'AMD Athlon) ça tiens mieux, mais ça se compte a 1s d'écart sur le test, puisque l'un supporte 8ko, l'autre 40ko.
Mais les 2 PC sont déjà des PC's bien puissants, des Jeux Open GL (Nexuiz, Xonotic, Red Eclipse, etc...) passent entre la qualité Maximum et une qualité haute pas loin en fonction du jeu (Pour le PC avec i5 tout est toujours au max), et pour des Jeux Direct X, bien que je n'y joue pas beaucoup puisque je suis majoritairement sous Linux, pour l'I5 tout tourne en qualité maximum avec par contre Anticrenelage et Antialiasing au maximum a X2 (ça ne supporte pas trop plus).
L'AMD Athlon supporte moins, mais il supporte quand même les jeux en qualité standard pour les jeux comme Crysis Warhead, et sinon les jeux comme Oblivion, Skyrim,  etc... passent en qualité Haute sans problèmes.
Tout ça bien sur sans anti-crenelage et anti-aliasing ou sans dépasser le X2 ou billinéaire comme pour l'I5 sans quoi ça peu ralentir un peu...

Donc les 2 PC sont bien puissants, aucun problèmes là dessus je me répète mais ça ne peut pas venir du fait que les machines soient trop peu puissantes ou trop anciennes :) (elles sont récentes)

Donc j'espère que vous arriverez a reproduire le bug avec ça et que vous arriverez a voir d'où il viens et le corriger, si y a des tests a faire, je veux bien tester chez moi les modifications si vous avez besoin (histoire de comparer les tests, et voir si c'est résolu), en sachant que a partir de mardi soir je ne suis pas là pendant 1 semaine (vacances) mais d'ici là, je n'ai aucun problèmes a tester, et après non plus.
En vacances je n'aurais que mon PC portable donc seul et sans d'autres ordis a moi c'est pas génial pour faire ce genre de tests....
Ah, un dernier détail: Le test est ici en TCP, le bug se produit aussi en UDP, sauf qu'en UDP c'est pas possible de savoir si l'autre a reçu ou pas le paquet, donc pour un test de ce genre c'est pas génial....

Voilà, Merci d'avance :)
Titre: Re : Socket qui bloque sur NotReady !
Posté par: Laurent le Août 10, 2012, 08:14:09 am
Quand un PC bloque, il y a quoi affiché sur la sortie standard juste avant le bloquage ?

Et au fait :
sf::sleep(sf::seconds( 1 / 60)); //Simulation d'un jeu tournant a 60FPS.
1 / 60 == 0 car c'est une division entière. Essaye plutôt 1.f / 60.
Titre: Re : Socket qui bloque sur NotReady !
Posté par: Crone123 le Août 10, 2012, 04:02:35 pm
Ah oui effectivement j'ai oublié le détail que c'était du int....Merci :)

Quand un PC bloque, bah, il n'affiche rien de plus que ce qu'on affiche avec le programme (cout <<), coté client il ne va plus rien afficher (il affiche le message du dernier socket reçu et rien de plus après), coté serveur on a le droit a 20 erreur disant que le client est NotReady avant que je coupe ma boucle.
Si vous ne coupez pas la boucle le serveur vous renverra indéfiniment cette erreur parce que le client ne reçois plus rien (bloqué)...
Titre: Re : Socket qui bloque sur NotReady !
Posté par: Laurent le Août 10, 2012, 05:44:14 pm
Ok, bon je vais essayer de tester ça mais j'ai peu de temps libre alors je ne te promets rien.
Titre: Re : Socket qui bloque sur NotReady !
Posté par: Crone123 le Août 10, 2012, 05:44:58 pm
OK Merci :)
Titre: Re : Socket qui bloque sur NotReady !
Posté par: Crone123 le Octobre 22, 2012, 10:55:27 pm
J'ai du nouveau concernant ce bug, ou un bug similaire.
Donc, je ne cherche pas a dire que la SFML est bugguée hein, j'aime beaucoup cette bibliothèque, mais j'étais en train de transférer des données d'un serveur vers un client (une map pour un jeu).
Et encore une fois le socket a bloqué, en TCP avec la SFML 2.0RC.
J'ai du trasnférer quelque chose comme 7 ou 8 mo a une vitesse de 160ko/s sur un réseau local fillaire et de ma machine a elle même (donc c'est pas un problème de vitesse du réseau).
Donc, classique, tout se passait très bien, et d'un coup la transmission s'est arrêtée.
Coté client c'est du NotReady si je veux envoyer.
Coté serveur, lancé en débug sur GDB, j'ai eut ce message:
Program received signal SIGPIPE, Broken pipe.
0x00007ffff5d1f2cc in __libc_send (fd=<optimized out>, buf=<optimized out>,
    n=<optimized out>, flags=<optimized out>)
    at ../sysdeps/unix/sysv/linux/x86_64/send.c:33
33      ../sysdeps/unix/sysv/linux/x86_64/send.c: Aucun fichier ou dossier de ce type.
(gdb)
Un plantage de ce type, ça ne peut pas venir de mon programme directement puisque je ne manipule pas directement ces fichiers, j'utilise la SFML pour le faire et voilà la preuve du bug écrit dans le backtrace:
(gdb) bt
#0  0x00007ffff5d1f2cc in __libc_send (fd=<optimized out>,
    buf=<optimized out>, n=<optimized out>, flags=<optimized out>)
    at ../sysdeps/unix/sysv/linux/x86_64/send.c:33
#1  0x00007ffff731441b in sf::TcpSocket::send(void const*, unsigned long) ()
   from ./libsfml-network.so.2
#2  0x00007ffff7314628 in sf::TcpSocket::send(sf::Packet&) ()
   from ./libsfml-network.so.2
#3  0x00000000004608b9 in Server_Main::server_Send (this=0x8f0500,
    Command=..., Client=0xa995e0) at Server_Main_SR.cpp:47
#4  0x0000000000432230 in Server_Main::OnUpdate (this=0x8f0500)
    at Server_Main.cpp:646
#5  0x000000000042d5fe in Server_Main::Server_Main (this=0x8f0500, parent=0x0,
    Position=..., Size=..., LTmp=0x778570, G=false) at Server_Main.cpp:190
#6  0x000000000040e85a in main (argc=2, argv=0x7fffffffe258) at main.cpp:176
(gdb)
Bon, je ne voudrais pas voir des bugs partout (ou donner l'impression que je suis parano..), mais cette fois ci je pense que ça peut être pris au sérieux étant donné que l'effet coté client est un NotReady continu (comme précédemment dit), le transfert s'arrête comme je l'avais dit.
Et coté serveur cette fois ci j'ai eut droit a un crash, d'habitude je relançais directement le serveur j'attendais pas quelques secondes avec le débugger pour voir d'où ça pouvait venir. (donc j'ai jamais vu si ça crashait ou pas..)
Donc normalement maintenant vous pouvez savoir d'où viens précisément le bug :)
Merci :)
Titre: Re : Socket qui bloque sur NotReady !
Posté par: Laurent le Octobre 23, 2012, 06:49:11 am
Le SIGPIPE est doit être pris plus à la légère, il signifie une déconnexion et non un crash :
https://github.com/SFML/SFML/issues/72
Titre: Re : Socket qui bloque sur NotReady !
Posté par: Crone123 le Octobre 23, 2012, 05:04:35 pm
Donc le bug est connu?
(L'effet est le même qu'un crash avec le débugger par contre...)
La correction est prévue assez rapidement où bien je dois rajouter une de ces lignes de codes pour que ça ne bug plus?
Je suis sous Linux, donc a priori c'est la 2ème ligne, si c'est a moi de la rajouter, je dois la rajouter où dans mon projet et comment?
Si c'est un bug de la SFML, quand pensez-vous qu'il y aura une correction?
Merci :)
Titre: Re : Socket qui bloque sur NotReady !
Posté par: Laurent le Octobre 23, 2012, 05:17:08 pm
Citer
Donc le bug est connu?
C'est pas un bug, juste que le comportement par défaut de Linux n'est pas ce que SFML veut ;)

Citer
L'effet est le même qu'un crash avec le débugger par contre...
Un signal non rattrapé, c'est comme une exception non rattrapée, et le debugger te montre ça de la même manière qu'un crash effectivement. C'est normal.

Citer
Je suis sous Linux, donc a priori c'est la 2ème ligne, si c'est a moi de la rajouter, je dois la rajouter où dans mon projet et comment?
Il faut juste ajouter le paramètre MSG_NOSIGNAL aux appels à la fonction send (il doit y avoir un seul appel, dans sf::TcpSocket). Actuellement il doit y avoir un 0 à la place de ce paramètre.
Du coup tu dois modifier SFML. Sinon je pense que tu peux mettre en place un handler pour le signal SIGPIPE, mais il faut chercher comment faire.

Citer
Si c'est un bug de la SFML, quand pensez-vous qu'il y aura une correction?
Sûrement dans 2.1, ça n'a pas l'air méchant.
Titre: Re : Socket qui bloque sur NotReady !
Posté par: Crone123 le Octobre 23, 2012, 05:24:38 pm
D'accord, donc en fait c'est une exception non rattrapée sur un comportement par défaut de Linux.
Donc le bug n'est pas sous Windows.
Donc en gros, je télécharges les sources de la SFML, je modifie la ligne qui bug dans les sf::TcpSocket et je la compile?
Bon, j'espère arriver à la compiler, mais je veux bien essayer. (au pire si besoin d'aide pour compiler je poste ici..)
Sinon (sans vouloir être embêtant bien sûr :) ), avez vous une idée de date approximative pour la SFML 2.1?
Fin du mois? Fin du mois prochain? Un autre moment?
Merci :)
Titre: Re : Socket qui bloque sur NotReady !
Posté par: Laurent le Octobre 23, 2012, 06:35:42 pm
Citer
avez vous une idée de date approximative pour la SFML 2.1?
Fin du mois? Fin du mois prochain? Un autre moment?
J'ai même pas de date pour 2.0... :P
Titre: Re : Socket qui bloque sur NotReady !
Posté par: Crone123 le Octobre 23, 2012, 07:17:37 pm
Ah OK, et pour la 2.0 ça ne peut pas être corrigé? (si il suffit de modifier une ligne....)
Sinon, j'ai téléchargé les sources, je vais essayer de compiler la bibliothèque....
Titre: Re : Socket qui bloque sur NotReady !
Posté par: Laurent le Octobre 23, 2012, 08:50:57 pm
Citer
Ah OK, et pour la 2.0 ça ne peut pas être corrigé? (si il suffit de modifier une ligne....)
Non ;)
Il faut faire des tests, vérifier que ça ne casse rien, etc. C'est déjà trop tard pour la 2.0.
Titre: Re : Socket qui bloque sur NotReady !
Posté par: Crone123 le Octobre 23, 2012, 08:57:30 pm
Trop tard :o
Hé ben, il en faut du temps pour tout ça :o
(On dirait pas comme ça)

Sinon, j'ai essayé de compiler la SFML, je pense que j'ai réussi, mais elle ne fonctionne pas dans mon projet.

J'ai utilisé cmake comme le montre le tuto, mais je ne sais pas si il m'a compilé une version C ou C++.
En tout cas, j'ai des fichiers .so qui ont une taille très différente de la taille normale.
Et par exemple en compilant mon projet sf::Text::Text(std::string Machin); n'existe pas.
En fait, il ne la trouve pas dans les définitions de fonctions, bien qu'il me le propose.
ça fonctionnait avant.
Je me demande si il ne m'a pas compilé une version C au lieu de C++ puisque CMake a l'air de faire du C.

Pouvez-vous m'aider?
Merci :)
Titre: Re : Socket qui bloque sur NotReady !
Posté par: Laurent le Octobre 23, 2012, 09:05:14 pm
Citer
Hé ben, il en faut du temps pour tout ça
Il faut le temps que les gens l'utilisent suffisamment et rapportent d'éventuels problèmes. Donc oui, ça prend du temps. Surtout concernant le module réseau, qui n'est pas le plus utilisé. Les choses ne sont pas aussi simples qu'elles y paraissent.

Citer
Je me demande si il ne m'a pas compilé une version C au lieu de C++ puisque CMake a l'air de faire du C.
;D
CMake n'est pas un compilateur, il fait ce que tu lui demandes de faire avec le compilo que tu choisis. Donc ça peut être du C++ (et en l'occurence ça l'est). Et je vois mal comment tu pourrais produire une version C de SFML comme ça, le code c'est quand même du C++ hein ;)

Citer
En tout cas, j'ai des fichiers .so qui ont une taille très différente de la taille normale.
Et c'est quoi la "taille normale" ? Si tu as compilé en debug, ça peut être plus gros. Par exemple.

Citer
Et par exemple en compilant mon projet sf::Text::Text(std::string Machin); n'existe pas.
L'erreur exacte c'est quoi ? Parce que "n'existe pas" ça peut être plein de choses différentes, qui ont chacune une cause bien différente.
Titre: Re : Socket qui bloque sur NotReady !
Posté par: Crone123 le Octobre 23, 2012, 10:34:54 pm
Euh, en fait Firefox s'est fermé, donc j'ai perdu le message que j'étais en train d'écrire.
Donc, pour le message d'erreur ça viens du module graphique qui a un problème a la compilation, il me dit cette fois ci que la fonction sf::Font::getDefaultFont() n'est pas définie.

Avec la version du module réseau utilisant NO_MSG a la place de 0, j'ai eut de meilleures performances qu'avant.
Et si avant la récupération était impossible, maintenant quand ça bloque au bout de quelques secondes le jeu arrive a reprendre le transfert.
Il y a souvent des interruptions par contre, ça serait bien de corriger ça.
Enfin, ne nous plaignons pas, avant je n'arrivais pas a transférer plus de 1% de ma map.
Actuellement alors que j'écris ce message j'ai transféré 61% de la map.
Une belle avancée quoi :)

Par contre, la map est bien trop grosse, je la découperais en petites zones après...mais avant même les petites maps avaient du mal a passer....

Et sinon, niveau socket: Si je kille un programme, je n'ai aucun problèmes niveau fermeture des socket.
En revanche, si je quitte normalement le programme en fermant proprement les socket, bah, après je ne peux plus lancer le programme pendant une minute (temps que le système supprime lui même l'écoute de port) parce que le port reste considéré comme écouté.
Là dessus, je ne sais pas quoi faire, j'utilise bien les fonctions close/disconnect/unbind suivant le cas et pourtant rien a faire, les socket en écoutent le restent la plupart du temps.

On aurait pu soupçonner le fait que j'utilise Qt a coté et qu’éventuellement il empêcherait la fermeture, mais le serveur (qui a beaucoup de problèmes de ce coté là) n'utilise pas Qt, il a sa propre boucle avec la SFML.
J'avais essayé avec boost d'écouter des ports et je n'ai pas eu ce bug, avec la SFML je l'ai systématiquement, et sur tous les ordis sur lequel j'ai essayé le jeu....et tous les programmes que j'ai crée utilisant la SFML pour le réseau ont ce problème.

(Je le dis et je le répète, je ne suis pas là pour dire qu'il y a des bugs partout hein, je fais une simple constatation sur des problèmes que j'ai avec la SFML afin qu'ils puissent être éventuellement améliorés par la suite)
Merci :)
Titre: Re : Socket qui bloque sur NotReady !
Posté par: Laurent le Octobre 23, 2012, 10:53:32 pm
Citer
il me dit cette fois ci que la fonction sf::Font::getDefaultFont() n'est pas définie
Ce qui est vrai. Elle a été retirée depuis la RC.

Citer
Il y a souvent des interruptions par contre, ça serait bien de corriger ça.
Des interruptions ? C'est-à-dire ?

Citer
En revanche, si je quitte normalement le programme en fermant proprement les socket, bah, après je ne peux plus lancer le programme pendant une minute (temps que le système supprime lui même l'écoute de port) parce que le port reste considéré comme écouté.
Il faut vraiment que tu penses à chercher d'abord, lorsque tu tombes sur un os.
https://github.com/SFML/SFML/issues/150
Titre: Re : Socket qui bloque sur NotReady !
Posté par: Crone123 le Octobre 24, 2012, 01:41:57 pm
Citer
Ce qui est vrai. Elle a été retirée depuis la RC.
Mais moi je n'utilise pas la fonction, c'est lors d'un appel d'un constructeur de sf::Text avec en paramètre un std::string que j'ai cette erreur.
La SFML ne l'appelle pas en interne?
Citer
Des interruptions ? C'est-à-dire ?
Des coupures de 5 a 10s pendant les transferts réseaux.

Citer
Il faut vraiment que tu penses à chercher d'abord, lorsque tu tombes sur un os.
Ah, désolé, en fait j'ai toujours du mal pour trouver les endroit de signalement de bug, surtout si c'est en anglais je ne formule pas forcément correctement le bug en anglais.
Titre: Re : Socket qui bloque sur NotReady !
Posté par: Laurent le Octobre 24, 2012, 01:51:26 pm
Citer
Mais moi je n'utilise pas la fonction, c'est lors d'un appel d'un constructeur de sf::Text avec en paramètre un std::string que j'ai cette erreur.
La SFML ne l'appelle pas en interne?
Cette fonction n'existe plus car il n'y a plus de police par défaut, tu es obligé d'en charger une et de la passer à ton sf::Text maintenant.

Citer
Des coupures de 5 a 10s pendant les transferts réseaux.
Peut-être une surcharge de la socket, si tu envoies trop de données trop rapidement ?

Citer
Ah, désolé, en fait j'ai toujours du mal pour trouver les endroit de signalement de bug, surtout si c'est en anglais je ne formule pas forcément correctement le bug en anglais.
Oui, c'est vrai que celui-ci n'était pas forcément évident à trouver, surtout avec un titre pareil :)
Titre: Re : Socket qui bloque sur NotReady !
Posté par: Crone123 le Octobre 24, 2012, 03:33:46 pm
Euh, pourquoi plus de police par défaut?
C'est franchement très mauvais comme "amélioration", parce que d'une part il faut avoir des polices, ensuite, c'est moins cool pour créer un sf::Text (on a pas forcément envie de mettre une police autre, celle par défaut va souvent très bien) et pour finir, j'ai un projet qui compte 21163Lignes de code + un SDK de 3000Lignes de codes qui va avec, donc là dedans je vais devoir m'amuser a retrouver tous les sf::Text pour leurs remettre une police par défaut :o
Là franchement je ne vois pas du tout l’intérêt, c'est mauvais comme changement.
Titre: Re : Socket qui bloque sur NotReady !
Posté par: Laurent le Octobre 24, 2012, 04:08:58 pm
La police par défaut était un cas particulier qui n'était selon moi pas si justifié que ça. J'ai juste retiré cette "irrégularité", et rendu l'API plus homogène.

La police par défaut c'était bien pour prototyper ou pour faire du debug. Mais dans l'application finale, personne ne va l'utiliser, tu vas forcément charger une police qui va mieux que ce bête Arial.

Et si tu veux tout de même Arial, et bien il n'y a qu'à le copier depuis le répertoire de polices de ton OS vers ton application, et le gérer comme toutes les autres ressources de ton application. Je ne vois pas de gros problème.

Bien sûr, ce n'est pas la raison pour laquelle ça a été retiré, c'est à la base parce que la police par défaut était une instance à portée globale qui causait des crashs à la fermeture, et que la seule façon propre de régler ça était de la supprimer.
Titre: Re : Socket qui bloque sur NotReady !
Posté par: Crone123 le Octobre 24, 2012, 04:10:52 pm
Bah, c'est ce que je fais déjà actuellement. (je savais pas que c'était arial..)
Mais ce qui est chiant là dedans c'est qu'il va falloir modifier toutes les déclarations de sf::Text...
Titre: Re : Socket qui bloque sur NotReady !
Posté par: Laurent le Octobre 24, 2012, 04:24:43 pm
Citer
Mais ce qui est chiant là dedans c'est qu'il va falloir modifier toutes les déclarations de sf::Text...
Oui c'est chiant, c'est sûr. C'est l'inconvénient d'être entre deux versions majeures -- c'est le seul moment où on peut tout péter. Une fois que SFML 2.0 sera sortie, la compatibilité descendante sera conservée dans toutes les versions mineures qui vont suivre, et le prochain "pétage" de l'API publique devra attendre SFML 3.0.

Bon, et puis ce n'est pas la mort, il n'y a qu'à suivre les erreurs de compilation et rajouter un petit paramètre sur chaque ligne incriminée ;)
Titre: Re : Socket qui bloque sur NotReady !
Posté par: Crone123 le Octobre 24, 2012, 06:44:54 pm
OK, bah j'ose espérer que la version finale de la 2.0 sera bien :)
Concernant les bugs graphiques (même si c'est hors sujet vu qu'on parle de bug voilà) des cartes ATI sur Linux vous comptez faire des améliorations pour la 2.0 ou c'est a ATI de résoudre le problème? (et a mon avis c'est pas prêt d'être corrigé de la part d'ATI..)
Merci :)
Titre: Re : Socket qui bloque sur NotReady !
Posté par: Laurent le Octobre 24, 2012, 10:49:26 pm
Citer
OK, bah j'ose espérer que la version finale de la 2.0 sera bien
Elle l'est déjà, en tout cas elle ne bougera pratiquement plus d'ici la sortie.

Citer
Concernant les bugs graphiques (même si c'est hors sujet vu qu'on parle de bug voilà) des cartes ATI sur Linux vous comptez faire des améliorations pour la 2.0 ou c'est a ATI de résoudre le problème? (et a mon avis c'est pas prêt d'être corrigé de la part d'ATI..)
Tu parles de quel(s) bug(s) au juste ? Pour ma part il n'y en a plus.
Titre: Re : Socket qui bloque sur NotReady !
Posté par: Crone123 le Octobre 26, 2012, 11:55:52 pm
Pas de bug?
(http://dl.smglive.org/FJ_1344871724.62_ViewMin169)
Et tous le sf::ConvexShape (où quasiment tous) me font ça sur les cartes ATI (Linux 64bits - Ubuntu 12.04 LTS).
Titre: Re : Socket qui bloque sur NotReady !
Posté par: Laurent le Octobre 27, 2012, 07:54:23 am
Si personne ne me remonte le bug, je ne peux pas deviner qu'il y en a un. Je ne peux parler que des bugs dont j'ai connaissance ;)

Fais moi un rapport complet en bonne et dûe forme dans le forum approprié, et je jetterai un oeil.
Titre: Re : Socket qui bloque sur NotReady !
Posté par: Crone123 le Octobre 27, 2012, 07:08:59 pm
J'en avais déjà rapidement parlé avant... (et j'avais ces bugs avec les sprites de temps en temps sur la SFML 1.6, a priori plus sur la 2.0 mais les sf::ConvexShape buggent..)

Citer
Fais moi un rapport complet en bonne et dûe forme dans le forum approprié, et je jetterai un oeil.
C'est a dire?
Un sujet dédié?
Merci :)

EDIT: Oui, en fait j'ai mal lu, donc un sujet dédié :)
Titre: Re : Socket qui bloque sur NotReady !
Posté par: christophedlr le Novembre 06, 2012, 03:22:00 pm
Cela dit concernant ATI, on peut imputer un peu aux drivers aussi, car à moins que Laurent face directement le lien avec les cartes graphiques, il passe obligatoirement par le driver de la carte graphique dont la communication basique est identique. Elle est normalement si je me trompe pas, différente seulement sur les fonctionnalités propre à ATI ou propre à NVidia, ce qui est en général des extensions OpenGL bien particulières et plutôt utiliser dans la 3D.
Titre: Re : Socket qui bloque sur NotReady !
Posté par: Crone123 le Novembre 06, 2012, 03:28:53 pm
Oui justement si je précise a chaque fois que ce sont des cartes ATI ou Nvidia c'est justement pour ça: Les drivers Nvidia n'ont aucuns problèmes (du moins pas que je saches) alors que les drivers ATI sont souvent "foireux" même si ils tendent a s'améliorer ces derniers temps...
Et d'ailleurs je précise que toutes les fois où j'ai eu des problèmes graphiques (comme je l'ai déjà dit) c'était exclusivement sur des cartes ATI.
Pour le même programme, aucun problème sur carte Nvidia.
Il faudrait que je compile mon programme pour Windows pour voir la réaction des cartes, si je me plante pas les cartes ATI avaient eut d'énormes problèmes un moment sous Windows mais c'est corrigé, en revanche le support Linux est moins bien assuré.
Donc le bug présent est peut être présent sous Linux et pas sous Windows car les drivers sont peut être différents.
Je teste quand j'ai le temps, mais je pense que le résultat sera prévisible: Probablement pas de bug avec les drivers Windows car meilleur support de chez ATI...
A quand des drivers compilés pour chaque carte graphique pour Linux? (Bon, vous direz coté Nvidia même si les drivers sont génériques on est pas a plaindre :) )
Titre: Re : Socket qui bloque sur NotReady !
Posté par: Laurent le Novembre 06, 2012, 03:31:24 pm
Si vous voulez continuer à discuter des cartes graphiques, ce serait bien d'arrêter de le faire dans ce sujet qui concerne les sockets ;)
Titre: Re : Socket qui bloque sur NotReady !
Posté par: Crone123 le Novembre 06, 2012, 03:33:16 pm
Oui, j'avais d'ailleurs crée un sujet pour les cartes graphiques: http://fr.sfml-dev.org/forums/index.php?topic=9533.0
Je continuerais de poster mes résultats dans l'autre sujet.
Titre: Re : Socket qui bloque sur NotReady !
Posté par: Crone123 le Juin 07, 2013, 04:39:55 pm
Bonjour,
Je déterre un peu mon topic:
Je ne sais pas si ça a un rapport avec le bug précédent, ou le socket restait bloqué sur "NotReady", mais en créant ma propre classe qui gère elle même les transmissions de paquets, j'ai aussi eu un problème de blocage.

J'ai creusé un peu pour voir d'où ça venait, et j'ai l'impression qu'il y a une correction a faire dans les socket de la SFML.
Donc, j'explique ma classe, le test que j'ai fait, et le résultat que j'ai obtenu, ainsi que ma conclusion:

Donc, je voulais me faire une classe qui gérait elle même le découpage des données, de multiples canaux d'envoi, un cryptage léger des paquets et bien sûr l'envoi et la réception.

Fonctionnement:
A la connexion avec un client, en supposant que l'on veuille envoyer des données assez grosses (un fichier par exemple), pouvoir en même temps envoyer des commandes (type shell) est intéressant.

Du coup, j'ai commencé par créer un système tournant sur du 64o par paquet pour voir.
Le premier paquet réserve 8o d'information de canaux, de séquence, et de taille totale de la trame.
On arrive donc a ceci:
[unsigned short ID][short sequence][unsigned int Taille][char * données]
Les autres paquets envoyés sur le même canal (même ID) suivent la première séquence, mais la taille n'est plus présente, elle est remplacée par 4o de données supplémentaire.

Avec des paquets de 64o, tout va plutôt bien, sauf que c'est extrêmement lent même sur la même machine.
J'y ai intégré un système de gestion d'erreur, capable de ré-envoyer un paquet qui ne serait pas arrivé, ou bien de renvoyer complètement une trame sans doublons si besoin.
J'y ai intégré le cryptage, et ça fonctionnait aussi.

Vu que c'était super lent, j'ai décidé d'augmenter la taille de chaque paquet.
Les paquets font maintenant 1468o.
→ Pour rappel, je n'utilise dans ce test aucun sf::Packet, mais uniquement des tableaux de char.

Problème, sur cette taille, y a 2 solutions: soit ça passe, soit ça casse. Et ça casse très fréquemment, alors que je transfère vers 127.0.0.1.
Donc j'ai cherché a voir d'où venait la casse, pourquoi d'un seul coup le transfert s'arrête alors qu'il n'y a priori aucune erreur, et que contrairement au cas des sf::Packet ça ne reste pas bloqué sur NotReady.

J'ai testé beaucoup de cas, beaucoup de données, et j'ai fini par trouver un pépin:
De temps en temps, la taille de la trame utilisée est complètement fausse.
En envoyant 2o, le destinataire attends 16777471o

Je vous rassure tout de suite: J'utilise correctement htons, ntohs, htonl, ntohl, et je convertis correctement les entiers en tableaux de char, et inversement (pareil pour les short).
Pour en être sûr, j'ai même affiché ce que donne une reconversion dans l'autre sens pour être sur que la conversion ne foire pas.

En affichant les données reçues, j'ai fini par trouver des données de l'entier de taille dans ce qui est censé être des données a recevoir.

J'ai donc décidé d'afficher chaque caractère contenu dans le tableau d'envoi et de reception sous la forme de son entier pour pouvoir comparer humainement les caractères.

Pour mon envoi de 2o, j'arrive a ceci pour l'envoi:
Code: [Sélectionner]
0, 0, -1, -1, 0, 0, 0, 2, 49, 115, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
Quand la connexion fonctionne, et donc que tout marche, j'obtiens la même chose en réception.
Mais si la réception échoue, et donc que le transfert se bloque, j'obtiens ceci en réception:
Code: [Sélectionner]
0, 0, -1, -1, 1, 0, 0, -1, -1, 0, 0, 0, 2, 49, 115, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,Et a partir de ça, on peut comprendre pourquoi ça ne fonctionne pas.

Regardez les premiers octet, en envoi:
Code: [Sélectionner]
0, 0, -1, -1, 0, 0, 0, 2, 49, 115En réception;
Code: [Sélectionner]
0, 0, -1, -1, 1, 0, 0, -1, -1, 0, 0, 0, 2, 49, 115
Quand je dis 2o, ça correspond donc a l'envoi de 8o d'en-tête +2o de données.
49 et 115 sont donc les 2o de données.
0 et 0, sont donc l'ID du canal (ici 0)
-1 et -1 est donc l'ID de séquence (ici -1)
Et 0, 0, 0, 2 est l'entier de taille qui vaut 2.
Le paquet a l'envoi est donc intact, et pour preuve, il arrive qu'il arrive exactement pareil.
En revanche, ce qu'il faudra m'expliquer c'est l'apparition du 1, 0, 0, -1, -1 dans le paquet reçu.
Et justement, c'est ce qui fait bugger la taille, puisque la réception lis ces octets comme taille, et considère les suivants comme des données.
Tous les 0 seront aussi considéré comme des données puisque la taille que renvoie 1, 0, 0, -1 est très grande, donc la réception ne lis pas que 2 o.

Mais c'est pas l'entier qui est buggué, puisque l'on retrouve 0, 0, 0, 2 derrière, suivi correctement de 49, 115.

J'ai donc l'impression forte que la SFML a du mal avec l'envoi de paquets d'une certaine taille, en envoyant pas exactement ce qu'elle devrait envoyer.

Si les sf::Packet utilisent aussi leurs système de transmission du même genre que le miens, ce que je pense tout a fait probable, alors la réception d'un paquet faussé pourrait corrompre tout simplement la réception.
Le système pourrait être buggué de la même façon que le miens. A la différence près que le miens gérant plusieurs canaux, seule la trame bugguée ne passera pas, mais restera continuellement en attente de réception d'un coté.
Si le système de sf::Packet envoi les paquets l'un après l'autre, alors le fait qu'un seul paquet soit bloqué en attente de réception ça suffira pour bloquer le socket.

Et c'est exactement ce que j'ai en envoyant des données d'une certaine taille via des sf::Packet.

Voilà, j'ai peut être trouvé l'explication a mon problème d'il y a un certain temps, et au bug que j'ai actuellement.
Maintenant, il reste a trouver la cause dans la SFML (si effectivement ça proviens de là), et trouver la correction au bug :)

Au niveau de la SFML, si le bug est confirmé, il peut se trouver aussi bien dans l'envoi que la réception.
L'envoi peu envoyer n'importe quoi de temps en temps, ou la réception peut mal recevoir les données de temps en temps. (reste a savoir pourquoi)
En tout cas, mon test montre que le bug se produit a un moment ou moi utilisateur ne je peux plus voir ce qui se passe avec les données.
Est-ce que tu pourrais regarder ça Laurent?
Merci :)


EDIT: Après un autre test avec des paquets de 64o, en fait ça ne doit pas dépendre de la taille...
Envoi:
Code: [Sélectionner]
0, 0, -1, -1, 0, 0, 0, 2, 49, 108, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, Envoi:
Code: [Sélectionner]
0, 0, -1, -1, 1, 0, 0, -1, -1, 0, 0, 0, 2, 49, 108, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,J'ai l'impression que l'envoi ou la réception au moment du bug envoie les octet 1 et 2 du paquet, puis rajoute char(1), puis renvoie les octet 1 et 2 du paquet, puis envoie le reste du paquet.
Merci :)

EDIT2: Sinon autre test:
Code: [Sélectionner]
0, 0, -1, -1, 0, 0, 0, 2, 49, 97, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
Code: [Sélectionner]
0, 0, -1, -1, 1, 0, 0, -1, -1, 0, 0, 0, 2, 49, 97, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
La même suite d'octet se rajoute au 3ème octet encore une fois.
Titre: Re : Socket qui bloque sur NotReady ! / Problème de paquets...
Posté par: Laurent le Juin 07, 2013, 05:08:53 pm
J'ai pas lu la fin, c'est trop long, mais il y a ceci qui est apparu récemment : https://github.com/SFML/SFML/pull/402
Titre: Re : Socket qui bloque sur NotReady ! / Problème de paquets...
Posté par: Crone123 le Juin 07, 2013, 06:21:32 pm
C'est ressemblant, de la corruption de données.
Dans mon premier cas avec les sf::Packet c'est proche, voir même c'est ça.

Par contre, dans mon second cas, j'utilise directement sf::TcpSocket::send() avec un char * et ça me corrompt les données assez souvent...
Mais j'utilise effectivement le mode non-bloquant a chaque fois.

La SFML transformerait mon char * en sf::Packet?
Titre: Re : Socket qui bloque sur NotReady ! / Problème de paquets...
Posté par: Laurent le Juin 07, 2013, 09:05:18 pm
Citer
La SFML transformerait mon char * en sf::Packet?
Non.
Titre: Re : Socket qui bloque sur NotReady ! / Problème de paquets...
Posté par: Crone123 le Juin 07, 2013, 10:14:01 pm
Bah, en tout cas j'ai tout testé, le bug viens a tous les coups de l'envoi par la SFML (ou de la réception), de mon coté le code s’exécute a chaque fois correctement (j'ai passé du temps pour tester tout ça)

Je vais essayer de recompiler la lib avec l'autre modif que tu m'avais dit la dernière fois. Je sais pas si ça a vraiment une chance de marcher, mais je peux toujours essayer.
Titre: Re : Socket qui bloque sur NotReady ! / Problème de paquets...
Posté par: Laurent le Juin 07, 2013, 10:29:30 pm
Quelle modif ?
Titre: Re : Socket qui bloque sur NotReady ! / Problème de paquets...
Posté par: Crone123 le Juin 07, 2013, 10:30:57 pm
Je pensais a ce que tu m'avais sortit:
https://github.com/SFML/SFML/issues/72
Mais en fait, ça n'as un peu rien a voir finalement...
Titre: Re : Socket qui bloque sur NotReady ! / Problème de paquets...
Posté par: Laurent le Juin 07, 2013, 10:31:41 pm
Oui en effet ;)
Titre: Re : Socket qui bloque sur NotReady ! / Problème de paquets...
Posté par: Crone123 le Juin 07, 2013, 10:34:10 pm
Mais mon char * est envoyé directement?

Parce que je ne vois pas pourquoi j'ai des problèmes comme ça, nul part dans mon code ça ne crée ce problème... la ligne avant l'envoi toutes les données sont impeccables, j'envoie, et la ligne juste après la réception j'ai des octet qui se sont incrustés dans le paquet...
Titre: Re : Socket qui bloque sur NotReady ! / Problème de paquets...
Posté par: Laurent le Juin 07, 2013, 11:16:02 pm
Là ça doit être autre chose. Si tu peux reproduire le problème dans un code complet minimal, j'essayerai de tester.
Titre: Re : Socket qui bloque sur NotReady ! / Problème de paquets...
Posté par: Crone123 le Juin 07, 2013, 11:27:34 pm
Euh, bah, si j'ai le temps j'essaierais de reproduire ça, mais bon, je sens que je vais encore mettre un bout de temps avant de réussir a faire ça....

J'ai remarqué un truc aussi, a prendre ou pas:
A l'origine, où ça ne bugguait pas, les données ne circulaient que dans 1sens.

En gros, j'envoyais du 1468o et l'autre devait tout récupérer ensuite.

Le problème c'est que en local ça marche, mais sur le réseau, ça fait trop de données d'un coup (a priori, bizarre, ça crashe pour envoyer 9mo en 10s alors que le SSH connecté me transfert du 80mo/s....sans problèmes....).
→ Mais dans ce cas là, c'est clairement une demande trop importante.

Donc, pour palier au problème, j'ai fait le système suivant:
On va appeler E l’émetteur, et R le récepteur.
E → Envoie 1468o avec 1460o de données dedans.
R → Réceptionne les données
R → Envoie 5o de données de confirmation
E → Réceptionne la confirmation
E → Envoie 1468o avec 1464o de données dedans.
R → Réceptionne les données
R → Envoie la confirmation de 5o
etc...

Si les socket veulent bien marcher, le système fonctionne.
Mais bon, très souvent ça ça bug....


Je pense a un truc au fait:
Pour boost::asio, il ne faut pas que le buffer soit de la mémoire temporaire. (d'après ce que j'ai lu)
La SFML a telle la même restriction? (Si oui, ça peut expliquer quelques problèmes)
Enfin, jusqu'à maintenant, en dehors des quelques octet rajoutés de on ne sait pas où ça n'as jamais fait de segmentation fault a cause de ça...
Merci :)
Titre: Re : Socket qui bloque sur NotReady ! / Problème de paquets...
Posté par: Laurent le Juin 08, 2013, 09:05:51 am
Citer
Pour boost::asio, il ne faut pas que le buffer soit de la mémoire temporaire. (d'après ce que j'ai lu)
La SFML a telle la même restriction?
Non. Les données sont copiées par les couches internes, tu n'as pas à te soucier de ça.
Titre: Re : Socket qui bloque sur NotReady ! / Problème de paquets...
Posté par: Crone123 le Juin 08, 2013, 11:50:20 am
OK, donc faudra essayer de reproduire le bug...
Titre: Re : Socket qui bloque sur NotReady ! / Problème de paquets...
Posté par: Crone123 le Juin 12, 2013, 06:37:45 pm
En fait, je pense que si j'utilise des socket bloquants et que je les met en thread avec des mutex ça devrait faire l'affaire.
Je vais me coder une classe pour gérer ça, on verra bien :)
Titre: Re : Socket qui bloque sur NotReady ! / Problème de paquets...
Posté par: Crone123 le Juin 13, 2013, 01:49:50 am
Le bug peut t-il provenir du fait que je n'utilise pas de sf::SocketSelector?
Le socket pouvant être testé via cet objet, mon code pourrait en fait utiliser le socket quand il n'est pas prêt non?
Merci :)
Titre: Re : Socket qui bloque sur NotReady ! / Problème de paquets...
Posté par: Laurent le Juin 13, 2013, 08:40:32 am
Non, si la socket n'est pas prête elle te le dit tout simplement, sans provoquer d'erreur ou de choses bizarres.

Au lieu de jouer aux devinettes, ce qui peut litéralement durer des mois, tu devrais essayer de bidouiller ton code pour lui faire cracher plus d'informations. Réduis-le au minimum, fais des tests un peu plus restreints et ciblés que "faire tourner ta grosse appli", etc. C'est comme ça que ça marche ;)
Titre: Re : Socket qui bloque sur NotReady ! / Problème de paquets...
Posté par: Crone123 le Juin 13, 2013, 02:08:03 pm
J'ai recrée un système de socket en mode bloquant.
J'utilise plusieurs threads pour gérer Envoi, Réception et Acceptation. (de façon a ce qu'il utilise des socket bloquants, mais sur des threads, donc non-bloquant pour le programme)
Après une série de test et d'optimisation du système, j'arrive a un truc qui marche correctement.
Donc j'ai encore des tests a faire pour assurer que c'est stable, mais a priori c'est vraiment le mode non-bloquant qui pose problème...