[Winsock] WSASendTo implementation interne

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

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 ?

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

Citation:

---

Envoyé par jnussas

:roll:
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!

Citation:

---

Envoyé par jnussas

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'.

Citation:

---

Envoyé par jnussas

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.

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.

Citation:

---

Envoyé par 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.

---

:king:

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

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.

Citation:

---

Envoyé par jnussas

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()...

Citation:

---

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

Citation:

---

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.

Citation:

---

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

Citation:

---

- 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

Citation:

---

Envoyé par Emmanuel Delahaye

recvfrom()...

---

mon petit doigt gauche en fait qu'a sa tete

Citation:

---

Envoyé par Emmanuel Delahaye

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 !

Citation:

---

Envoyé par jnussas

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.

Citation:

---

Envoyé par 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".

---

Une méthode qui s'execute de manière asynchrone par rapport au reste de ton code. Dans le cas qui nous occupe c'est l'os qui se charge de l'appelée.

Citation:

---

Envoyé par Emmanuel Delahaye

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

---

justement j'aimerais avancé sur cette implementation pour que l'on fasse des tests de perf. avant que je mette en place tous les mécanismes de controle