Discussion :

[jnussas]

( j'avais posté ce message ailleurs mais n'ayant pas de réponse je pense que je me suis trompé de lieu )

Je suis en train de travailler sur l'implémentation d'u protocole Haut débit (voir très ). J'ai toujours utiliser les méthodes posix d'écriture socket ( send/sendto, recv/recvFrom ).

J'ai vu que WSASendTo permet d'envoyer plusieurs buffers ( visiblement en les concatenant dans une seule et meme trame ) avec le meme appel.

La question que je me pose est la suivante : en interne, comment cela se passe t'il ? copie des buffers dans une meme mémoire puis envoie ? Utilisation de descriteurs chainés à destination du DMA pour un envoie "en direct" ? ou autre ?

Autres questions :
- A quoi sert l'overlapp ? ON parle de chevauchement d'E/S ... c'est pas clair pour moi
- Les callBack "completion routine " sont executées dans quel contexte ?

[jnussas]

comme d'ab windows on sait ce que ca fait mais on sait pas comment ca le fait !
pfff

[3DArchi]

comme d'ab windows on sait ce que ca fait mais on sait pas comment ca le fait !
pfff

L'implémentation relève du droit de la propriété industrielle de Micro$oft. Donc, c'est pas anormale que le code ne soit pas public!

A quoi sert l'overlapp ? ON parle de chevauchement d'E/S ... c'est pas clair pour moi

De mémoire, et si je ne dis pas de bêtise, ça sert à travailler en asynchrone sans passer par le mode non bloquant au niveau des sockets. Il y a aussi une optimisation des buffers utilisés puisque ceux-ci sont fournis par l'appelant et sont supposés être valide jusqu'à l'exécution de la 'completion routine'.

Les callBack "completion routine " sont executées dans quel contexte ?

Je ne comprend pas forcément la question donc la réponse va peut être tombée à côte: les callBack sont appelées dans le cadre du thread courant.

[ram-0000]

Je ne parlerai dans cette réponse que du mode "completion routine", je ne connais pas le mode overlapped.

Dans ce mode, tu crées un pool de thread (en général, un par CPU ou par coeur) et tu associe ces threads avec un completion port.

Ensuite, à chaque fois que tu crées une socket, tu associes aussi cette socket avec le completion port.

Lorsqu'une action peut être réalisée sur un des sockets associé au completion port (read possible, fin de write, accept entrant, close reçu), un des thread associés au completion port est réveillé afin de faire le boulot. Donc les routines sont appelées dans le contexte d'un des threads associé au completion port et pas de le contexte du thread utilisateur.

Ce mode est le mode le plus performant des différents modes possible pour travailler avec les socket, c'est aussi (à mon avis) le plus délicat à comprendre et à mettre en oeuvre.

[jnussas]

Je ne parlerai dans cette réponse que du mode "completion routine", je ne connais pas le mode overlapped.

Dans ce mode, tu crées un pool de thread (en général, un par CPU ou par coeur) et tu associe ces threads avec un completion port.

Ensuite, à chaque fois que tu crées une socket, tu associes aussi cette socket avec le completion port.

Lorsqu'une action peut être réalisée sur un des sockets associé au completion port (read possible, fin de write, accept entrant, close reçu), un des thread associés au completion port est réveillé afin de faire le boulot. Donc les routines sont appelées dans le contexte d'un des threads associé au completion port et pas de le contexte du thread utilisateur.

Ce mode est le mode le plus performant des différents modes possible pour travailler avec les socket, c'est aussi (à mon avis) le plus délicat à comprendre et à mettre en oeuvre.

Pour voir si j'ai bien compris : en gros on a un thread "OS" par methode asynchrone et avec une priorité plus élevée que le thread utlisateur. Ce thread étant réveillé sur evenement système

[ram-0000]

Je ne sais pas ce que tu sous entends pas thread OS mais c'est un thread créé par l'application/l'utilisateur.

La priorité, c'est celle fixée par le programme (effectivement, je les boost un peu pour les mettre en priorité élevée mais c'est mon choix)

Par contre, j'ai pas compris le "par méthode asynchrone".

Le fonctionnement global,

• tu crées un completion port.
• tu crées autant de thread que tu veux (1 par coeur/cpu) que tu mets en attente bloquante sur le complétion port.
• Tu crées tes sockets en les liant avec ce completion port
• dès qu'il y a un événement à traiter, un des thread est débloqué (tu ne sais jamais lequel) et il doit traiter l'événement puis revenir attendre sur le completion port

Cela parait simple comme cela mais la mécanique à mettre en oeuvre est plus complexe que cela.

[Emmanuel Delahaye]

Je suis en train de travailler sur l'implémentation d'u protocole Haut débit (voir très ). J'ai toujours utiliser les méthodes posix d'écriture socket ( send/sendto, recv/recvFrom ).

recvfrom()...

J'ai vu que WSASendTo permet d'envoyer plusieurs buffers ( visiblement en les concatenant dans une seule et meme trame ) avec le meme appel.

Je déconseille l'usage de fonctions non portables. Commence déjà avec sendto(), quitte à faire une boucle et un découpage si nécessaire...

http://emmanuel-delahaye.developpez....eaux.htm#texte

La question que je me pose est la suivante : en interne, comment cela se passe t'il ?

Demande le gentiment à Bill Gates. Les sources ne sont pas publics.

Autres questions :
- A quoi sert l'overlapp ? ON parle de chevauchement d'E/S ... c'est pas clair pour moi

Ca sert quand on met en place l'abominable mécanisme de sockets asynchrone. Si tu débutes en programmation, contente toi du mode synchrone. Il est probablement largement suffisant pour ton application.

http://emmanuel-delahaye.developpez.com/reseaux.htm

- Les callBack "completion routine " sont executées dans quel contexte ?

Mode asynchrone, pour signaler que le travail est terminé. Normal, puis qu'on est en asynchrone, on reprend la main tout de suite. Si on ne veut pas écrabouiller les données, il faut bien un mécanisme pour dire qu'on peut continuer... Tout celà est très complexe, et inutile si on utilise correctement les threads.

http://emmanuel-delahaye.developpez.com/pthreads.htm

[jnussas]

recvfrom()...

mon petit doigt gauche en fait qu'a sa tete

Je déconseille l'usage de fonctions non portables. Commence déjà avec sendto(), quitte à faire une boucle et un découpage si nécessaire...

La contrainte est la vitesse du protocole et les plateformes de destination, il faut donc éviter memcpy et ses camardes... ( i.e. sous VxW, un zéro copy buffer existe => chaine de descripteur de buffers le DMA se charge de passer la chaine au chipset ETH )

Bien entendu je veux faire du code portable en prenant en compte les plateformes BSD,WIN et voire posix : ma question etait destinée à l' implementation du wrapper pour WIN.
On aurait pu utiliser un BOOST ( ou equivalent ) mais c'est pas le choix initial !

[Emmanuel Delahaye]

La contrainte est la vitesse du protocole et les plateformes de destination, il faut donc éviter memcpy et ses camardes...

Rien de tel dans l'exemple que j'ai donné (sur mon site). Le découpage se fait naturellement sans copie (visible).

Avant de te poser des questions sur l'implémentation, fait des essais de performances.