|
Publicité ' | |||||||||||||||||||||||
|
|
#1 | ||||
|
Membre du Club
![]() ![]() Inscription : février 2007 Messages : 103 ![]() |
Bonjour.
J'ai une problème avec les sockets de type SocketChannel et NIO en mode non bloquant. Ce code permet de sérialiser binairement des classes avec une sérialisation perso (je sais que java a ses propres systèmes de sérialisation mais la question n'est pas là) dont le but est de s'échanger des classes entre C++ (QT) et Java (C++ <-> C++ et C++ <-> Java). Le code créé fonctionne presque parfaitement. Sauf lorsque je crée artificiellement 100000 envoie d'élément sur la socket et que le récepteur ne peut pas tout lire aussi rapidement (le principe est de tester que si l'on envoie plus vite que le récepteur ne peut lire, rien n'est perdu). Je tiens à préciser que la partie C++ -> C++ fonctionne parfaitement. Je vous donne une partie du code source qui ne fonctionne pas... Code :
-> un thread créé dans init(SocketChannel aSocket) qui est en attente des différents evènements sockets appel processSelectionKey(selKey); sur chaque évènement. -> Une fonction processSelectionKey(selKey) qui aiguille sur chaque fonction en fonction du type de notification. -> Une fonction writeToSocket qui appelle l'instance fSendMessagesManager.writeToSocket(aKey) et qui, en fonction du retour set ou unset le SelectionKey.OP_WRITE pour être notifée lorsque de la place est disponible en sortie de la socket ou pas (en fonction de s'il a encore des éléments à envoyer ou pas). -> la fonction writeToSocket de mon inner class qui contient une liste d'élément à sérialiser. S'il en reste un et que le buffer interne est à 0 (tout a été envoyé), il dépile le message à envoyer, le sérialise (SerializationArchive) puis l'envoie sur la socket. Si, en sortie du write sur la socket tout n'est pas envoyé la fonction quitte et le OP_WRITE sera mis à true, sinon, tant qu'il reste des éléments à envoyer et que la socket absorbe tout (le write retourne la taille buffer qu'il a a écrire indiquant qu'il a tout envoyé) il continue à dépiler et envoyer les éléments tant qu'il n'en reste plus. Ceci fonctionne.... presque... En fait, tant que j'envoie (100 000 éléments en quelques secondes), le programme C++ reçoit correctement. Lorsque le programme Java a tout envoyé, le programme C++ en est à 2500 environ. A ce moment là, OP_WRITE est mis à 0 et la socket côté java est en attente ... normal ... sauf que le programme C++ arrête de recevoir !!! Et ça c'est pas normal ! Au début j'avais pensé que je perdais des informations... mais en fait non... Si j'envoie régulièrement (toute les secondes par exemple) un buffer d'un octet à 0 alors la socket se déploque et le programme C++ lit le message 2501,2502,2503,etc... (qui fait 150 octets, donc le programme C++ peut lire 150 octets pour un octet à 0 écrit dans la socket côté Java) comme s'il fallait stimuler continuellement la socket pour qu'elle envoie encore ses données mises en cache... La socket est configurée comme suit : Code :
|
||||
|
|
00
|
|
|
#2 |
|
Membre du Club
![]() ![]() Inscription : février 2007 Messages : 103 ![]() |
Bon, le fait de mettre ses idées au clair aide parfois...
J'ai trouvé la solution. Et cela venait du programme C++ sous QT. En effet, à chaque notification de type READ je lisais un et un seul message alors que la socket devait en contenir plein. Je pensais recevoir une autre notificationde la part de la socket plus tard car je n'avais pas tout lu (a priori c'est ce qui est fait sous wxWidgets car ce code C++ sous QT a été porté d'une lib existante sous wxWidgets avec laquelle je n'avais pas de problème de ce type (faudra que je reteste)), mais en fait non, je ne reçois plus de notification sauf en cas de nouvelles choses à lire... Du coup, après correction, il s'avère que l'envoi prend beaucoup plus de temps (ce qui parait bien plus logique) et les deux programmes sont bien plus synchrones. Le problème maintenant, c'est que si je reçoit trop de messages, je suis bloqué dans la lecture et je ne passe plus dans la boucle de messages... A tester. Désolé pour le dérangement. |
|
|
00
|
Copyright © 2000-2012 - www.developpez.com