Discussion :

[Thorna]

Bonjour.
Je cherche des informations techniques (matérielles et logicielles) sur le fonctionnement du réseau sur un PC moderne et j'ai plusieurs questions sur le sujet. A priori, c'est assez difficile à trouver, sauf tenter de lire le code de toute la couche réseau d'un Linux de base... ou encore je cherche n'importe comment, ce qui n'est pas à exclure ! Alors je me lance.

• la carte réseau (ou la partie de la carte mère qui fait fonction de carte réseau), je veux dire par là la partie matérielle, dispose-t-elle d'une "intelligence" minimale, comme par exemple pour décoder l'en-tête ethernet, l'en-tête IP ou plus encore, ou se contente-t-elle de recevoir des données du cable réseau ou du wifi ou de la fibre, etc. et de les balancer au driver réseau qui devra se taper tout seul le décodage des différentes couches ?
• A quel niveau se fait l'aiguillage qui envoie vers mon browser les résultats de mes requêtes Web, vers mon jeu les envois du serveur, vers mon OS les mises à jour windows, etc. ? Bref, qui répartit le trafic entrant en fonction du port de destination ?
• Le transfert des données depuis l'arrivée (cable, fibre, etc.) jusqu'au buffer mémoire que j'ai désigné dans Receive ou ReceiveFrom par exemple, se fait-il directement, ou via une suite de buffers "driver" puis "OS" puis... où les données sont recopiées plusieurs fois ?
• En parlant de recopies plusieurs fois, le décodage des différentes couches successives provoque-t-il une recopie à chaque fois du contenu des "données" de la couche vers un nouveau buffer passé à la couche suivante ?
• Si j'ai un seul Thread qui fait un Select, je suppose que tout ce qui est à destination de mon programme passe par lui et que je "dépile" au fur et à mesure et séquentiellement dans l'ordre d'arrivée tout ce qui arrive. Mais si j'ai 2 ou N Threads qui font tous les 2 ou tous les N un Select, lequel prend quoi ? Et ce n'est peut-être pas une bonne organisation logicielle...
• Même question, inversement en émission : si j'ai plusieurs Threads qui font des Send en même temps, où se passe la synchronisation, la remise à la queue-le-leu consistante de tout ce trafic pour aboutir sur une seule sortie physique ?
• Lorsque le Thread qui envoie des données par Send, par exemple, s'arrête juste après l'envoi, travail fini, quel Thread exécute le callback lorsque l'opération est terminée ?

Voilà, c'est un peu fouilli et pas mal dispersé, mais merci à ceux qui pourront y voir clair !

[Thorna]

Hello !
Comme le sujet est tordu et ne passionne pas réellement les foules, ce que je comprends très bien , j'ai persévéré et je pense avoir trouvé 2 ou 3 trucs intéressants. Mais il reste encore pas mal de points nébuleux !
Au cas où quelqu'un se poserait mystérieusement les mêmes questions :
-> Ici une première explication...
-> Ici une deuxième...

[gangsoleil]

• la carte réseau (ou la partie de la carte mère qui fait fonction de carte réseau), je veux dire par là la partie matérielle, dispose-t-elle d'une "intelligence" minimale, comme par exemple pour décoder l'en-tête ethernet, l'en-tête IP ou plus encore, ou se contente-t-elle de recevoir des données du cable réseau ou du wifi ou de la fibre, etc. et de les balancer au driver réseau qui devra se taper tout seul le décodage des différentes couches ?

Difficile de répondre dans l'absolu, car les contrôleurs réseaux ne sont pas tous identiques, mais globalement la carte suit le modèle OSI, donc elle n'a pas d'intelligence.

• A quel niveau se fait l'aiguillage qui envoie vers mon browser les résultats de mes requêtes Web, vers mon jeu les envois du serveur, vers mon OS les mises à jour windows, etc. ? Bref, qui répartit le trafic entrant en fonction du port de destination ?

Lorsque tu ouvres une socket de communication bi-directionnelle, tu précises le port sur lequel tu écoutes, et c'est l'OS qui s'occupe de transmettre les paquets qu'il reçoit vers la bonne application. On pourrait préciser la couche réseau de l'OS même.

• Le transfert des données depuis l'arrivée (cable, fibre, etc.) jusqu'au buffer mémoire que j'ai désigné dans Receive ou ReceiveFrom par exemple, se fait-il directement, ou via une suite de buffers "driver" puis "OS" puis... où les données sont recopiées plusieurs fois ?

Là encore, ça dépend. Il y a des buffers de réception bien sûr, mais de là à pouvoir t'indiquer si le buffer est transmis ou recopié, c'est trop dépendant.

• En parlant de recopies plusieurs fois, le décodage des différentes couches successives provoque-t-il une recopie à chaque fois du contenu des "données" de la couche vers un nouveau buffer passé à la couche suivante ?

Pas forcément. Je peux très bien prendre un paquet "brut", et identifier sans recopie l'en-tête ethernet, IP, TCP, ...

• Si j'ai un seul Thread qui fait un Select, je suppose que tout ce qui est à destination de mon programme passe par lui et que je "dépile" au fur et à mesure et séquentiellement dans l'ordre d'arrivée tout ce qui arrive. Mais si j'ai 2 ou N Threads qui font tous les 2 ou tous les N un Select, lequel prend quoi ? Et ce n'est peut-être pas une bonne organisation logicielle...

Ça dépend. Si tu es en TCP, qui te garantit l'ordonnancement des paquets, et que chaque paquet peut être traité indépendamment, alors c'est une bonne organisation (mais tu as un soucis de conception car si tes paquets peuvent être traités indépendamment, il est peu probable que tu aies besoin de garantir l'ordonnancement, mais c'est un autre débat).
Sinon, si tu es par exemple en UDP et que tu peux recevoir différents types de messages, tu as un thread qui fait une lecture en écoute, et qui identifie les données, et qui les passe à des threads de traitement. Et rien ne t'empêche d'avoir plusieurs threads qui font le même traitement.

• Même question, inversement en émission : si j'ai plusieurs Threads qui font des Send en même temps, où se passe la synchronisation, la remise à la queue-le-leu consistante de tout ce trafic pour aboutir sur une seule sortie physique ?

En environnement unixoïde, l'ordre d'écriture est l'ordre d'émission. Donc si tu as les écritures suivantes dans la même file d'émission : T1, T2, T2, T1, tu auras les paquets dans cet ordre d'envoi. Si tu es en TCP, ce sera aussi l'ordre de réception. Si ta carte réseau a plusieurs files d'émission et que chaque thread écrit dans une file différente, il faut voir les paramètres de la carte, c'est sûrement configurable.

• Lorsque le Thread qui envoie des données par Send, par exemple, s'arrête juste après l'envoi, travail fini, quel Thread exécute le callback lorsque l'opération est terminée ?

Je n'ai pas compris : quelle callback ?

[BufferBob]

salut,

la carte réseau (ou la partie de la carte mère qui fait fonction de carte réseau), je veux dire par là la partie matérielle, dispose-t-elle d'une "intelligence" minimale, comme par exemple pour décoder l'en-tête ethernet, l'en-tête IP ou plus encore, ou se contente-t-elle de recevoir des données du cable réseau ou du wifi ou de la fibre, etc. et de les balancer au driver réseau qui devra se taper tout seul le décodage des différentes couches ?

la plupart des cartes réseau actuelles permettent le calcul de certains CRC dans le paquet sortant, sous Windows l'option est activée par défaut si la carte le supporte

Si j'ai un seul Thread qui fait un Select, je suppose que tout ce qui est à destination de mon programme passe par lui et que je "dépile" au fur et à mesure et séquentiellement dans l'ordre d'arrivée tout ce qui arrive. Mais si j'ai 2 ou N Threads qui font tous les 2 ou tous les N un Select, lequel prend quoi ?

là encore c'est une question d'identification par le numéro de socket, select ne fait qu'indiquer s'il y a des données prêtes à être lues (...) sur la socket spécifiée, en gros on pourrait résumer par "premier arrivé, premier servi", le thread lit dans la socket ce qu'il veut (tout ou juste un certain nombre d'octets), s'il reste des octets à lire, le prochain select remontera à son tour, les deux threads lisent (recv/recvfrom) depuis le même buffer interne du noyau

[Thorna]

Merci de ces réponses ! Après des heures de lectures d'innombrables articles qui se répètent plus ou moins, je pense que j'en arrivais à peu près à comprendre ça. Reste à me plonger dans le code Linux, histoire de "suivre un paquet à la trace"...

Je n'ai pas compris : quelle callback ?

En fait, je parlais d'une commande comme celle-ci (dotnet) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

BeginSend(Byte[], Int32, Int32, SocketFlags, AsyncCallback, Object)

pour laquelle, outre les données, on indique une fonction (AsyncCallback) qui sera appelée par l'OS une fois que le send sera terminé. Je me demandais quel thread exécutait le callback.