Sockets : Commend savoir qu'un send() a été consommé
13 réponses
Marc
Bonjour,
J'ai besoin de transférer des gros blocs par sockets, donc je suis obligé de
"tronçonner" en plusieurs messages.
Mon problème est que dès le 2ème appel à send(), l'appli de bloque car le
recepteur n'a pas fini le traitement du 1er send().
Le problème disparait si je mets une tempo après chaque send.
Est-ce qu'il est possible de savoir, après avoir fait un send() si le
recepteur l'a consommé et s'il est prêt à en recevoir un nouveau ?
Pour des raisons de performance et de simplicité, je voudrais éviter de
devoir faire un recv() entre 2 send() même si ça peut résoudre le problème
de synchro.
> Sinon, si tu veux regarder un exemple de qqchose qui envoie via TCP des paquets et qui vérifie que c'est unitaire, tu peux regarder par exemple la classe de notre Middleware OMiSCID (http://omiscid.gforge.inria.fr/), dans la couche 0 (abstraction C++ du systeme) il y a une classe Socket et une classe MsgSocket dans le repertoire Com (layer 1).
Mon besoin peut paraître dans le fond assez générique, et j'ai un peu l'impression de réinventer la roue. J'ai écarté (à tord ?) ICE parce que ça m'a paru un peu lourd, et .Net Remoting parce que je ne suis pas sûr que ça puisse tenir avec plusieurs centaines de clients (.Net semble consommer pas mal de mémoire).
Je vais jeter un oeil sur OMiSCID, même si le nom fait peur ;-)
> Sinon, si tu veux regarder un exemple de qqchose qui envoie via TCP des
paquets
et qui vérifie que c'est unitaire, tu peux regarder par exemple la
classe de notre
Middleware OMiSCID (http://omiscid.gforge.inria.fr/), dans la couche 0
(abstraction C++ du systeme) il y a une classe Socket et une classe
MsgSocket
dans le repertoire Com (layer 1).
Mon besoin peut paraître dans le fond assez générique, et j'ai un peu
l'impression de réinventer la roue.
J'ai écarté (à tord ?) ICE parce que ça m'a paru un peu lourd, et .Net
Remoting parce que je ne suis pas sûr que ça puisse tenir avec plusieurs
centaines de clients (.Net semble consommer pas mal de mémoire).
Je vais jeter un oeil sur OMiSCID, même si le nom fait peur ;-)
> Sinon, si tu veux regarder un exemple de qqchose qui envoie via TCP des paquets et qui vérifie que c'est unitaire, tu peux regarder par exemple la classe de notre Middleware OMiSCID (http://omiscid.gforge.inria.fr/), dans la couche 0 (abstraction C++ du systeme) il y a une classe Socket et une classe MsgSocket dans le repertoire Com (layer 1).
Mon besoin peut paraître dans le fond assez générique, et j'ai un peu l'impression de réinventer la roue. J'ai écarté (à tord ?) ICE parce que ça m'a paru un peu lourd, et .Net Remoting parce que je ne suis pas sûr que ça puisse tenir avec plusieurs centaines de clients (.Net semble consommer pas mal de mémoire).
Je vais jeter un oeil sur OMiSCID, même si le nom fait peur ;-)
Dominique Vaufreydaz
Re,
Un middleware - Potentiellement plusieurs centaines de clients - Le temps de réponse doit être le plus court possible - Les messages peuvent aussi bien contenir quelques octets ou quelques Mo (besoin de transporter des images) - Doit être bidirectionnel asynchrone : pas uniquement question/réponse, le serveur peut aussi décider d'envoyer un message à un client sans requête préalable de celui-ci. - L'application doit pouvoir s'installer sur une machine de faible puissance (ram, cpu) s'il y a peu de clients à servir.
OMiSCID ;-P
Ok, ok pub gratuite ;-P
Doms.
Re,
Un middleware
- Potentiellement plusieurs centaines de clients
- Le temps de réponse doit être le plus court possible
- Les messages peuvent aussi bien contenir quelques octets ou
quelques Mo (besoin de transporter des images)
- Doit être bidirectionnel asynchrone : pas uniquement
question/réponse, le serveur peut aussi décider d'envoyer un message
à un client sans requête préalable de celui-ci.
- L'application doit pouvoir s'installer sur une machine de faible
puissance (ram, cpu) s'il y a peu de clients à servir.
Un middleware - Potentiellement plusieurs centaines de clients - Le temps de réponse doit être le plus court possible - Les messages peuvent aussi bien contenir quelques octets ou quelques Mo (besoin de transporter des images) - Doit être bidirectionnel asynchrone : pas uniquement question/réponse, le serveur peut aussi décider d'envoyer un message à un client sans requête préalable de celui-ci. - L'application doit pouvoir s'installer sur une machine de faible puissance (ram, cpu) s'il y a peu de clients à servir.
OMiSCID ;-P
Ok, ok pub gratuite ;-P
Doms.
Dominique Vaufreydaz
Bonjour,
Mon besoin peut paraître dans le fond assez générique, et j'ai un peu l'impression de réinventer la roue. J'ai écarté (à tord ?) ICE parce que ça m'a paru un peu lourd, et .Net Remoting parce que je ne suis pas sûr que ça puisse tenir avec plusieurs centaines de clients (.Net semble consommer pas mal de mémoire).
Nous avions la meme impression mais au final : - on voulait du multiplateforme TCP/UDM (bientot memoire partagée) - on voulait du Java/C++ parceque c'est obligatoire pour chez nous. Donc on a reinventer la roue nous aussi. Et comme on aime bien partager la roue, on la partage !
Je vais jeter un oeil sur OMiSCID, même si le nom fait peur ;-)
C'est fait expres... Ca, au moins, on se souvient du nom ! Difficile de trouver un accronyme.
Doms.
Bonjour,
Mon besoin peut paraître dans le fond assez générique, et j'ai un peu
l'impression de réinventer la roue.
J'ai écarté (à tord ?) ICE parce que ça m'a paru un peu lourd, et .Net
Remoting parce que je ne suis pas sûr que ça puisse tenir avec
plusieurs centaines de clients (.Net semble consommer pas mal de
mémoire).
Nous avions la meme impression mais au final :
- on voulait du multiplateforme TCP/UDM (bientot memoire partagée)
- on voulait du Java/C++ parceque c'est obligatoire pour chez nous.
Donc on a reinventer la roue nous aussi. Et comme on aime bien partager
la roue, on la partage !
Je vais jeter un oeil sur OMiSCID, même si le nom fait peur ;-)
C'est fait expres... Ca, au moins, on se souvient du nom !
Difficile de trouver un accronyme.
Mon besoin peut paraître dans le fond assez générique, et j'ai un peu l'impression de réinventer la roue. J'ai écarté (à tord ?) ICE parce que ça m'a paru un peu lourd, et .Net Remoting parce que je ne suis pas sûr que ça puisse tenir avec plusieurs centaines de clients (.Net semble consommer pas mal de mémoire).
Nous avions la meme impression mais au final : - on voulait du multiplateforme TCP/UDM (bientot memoire partagée) - on voulait du Java/C++ parceque c'est obligatoire pour chez nous. Donc on a reinventer la roue nous aussi. Et comme on aime bien partager la roue, on la partage !
Je vais jeter un oeil sur OMiSCID, même si le nom fait peur ;-)
C'est fait expres... Ca, au moins, on se souvient du nom ! Difficile de trouver un accronyme.
