Discussion :

[nuFox]

Bonsoir ...

Je me pose des questions sur la fonction recv() ...

Alors voila, je vous explique !

Du cote serveur, j'effectue l'envoie d'un message avec un send() ...
Je ne fais pas de recv() tout de suite ...
Ou est ce que le message est stocké ?

Enfin, est ce que vous avez de la doc sur le fonctionnement d'une carte réseau, sur la facon de gerer les paquet qui arrive ?

merci

[Emmanuel Delahaye]

Je me pose des questions sur la fonction recv() ...

Du cote serveur, j'effectue l'envoie d'un message avec un send() ...
Je ne fais pas de recv() tout de suite ...
Ou est ce que le message est stocké ?

Dans les buffers des couches systèmes. Quand il n'y a plus de place, les paquets (les plus anciens ?) sont perdus...

Il font conserver un certain synchronisme...

Enfin, est ce que vous avez de la doc sur le fonctionnement d'une carte réseau, sur la facon de gerer les paquet qui arrive ?

La notion de carte réseau est très 'bas niveau'. Les systèmes proposent en général une abstraction appelée socket (tu connais, puisque recv() en fait partie) qui évite les tracas liés à la gestion des cartes réseaux (Ethernet, USB, Wifi... peu importe. Un socket est un socket...)

Quelle est la vraie question ?

[nuFox]

Merci pour ta premiere réponse ...

Enfait voila ... j'ai du mal a m'expliquer ...

Le paquet recu sur un socket ... Est ce que je peux le recup quand je veux avec la fonction recv() ? Ou est ce que je suis obligé de faire un send()/recv() l'un après l'autre ?

Est ce que les paquets recu s'entassent dans un pile de type FIFO ?

Il ne s'entasse pas sur un buffer de la carte réseaux ? Mais sur le buffer que l'on a créée vec le socket ?

[Emmanuel Delahaye]

Le paquet recu sur un socket ... Est ce que je peux le recup quand je veux avec la fonction recv() ?

Ben pas 2 heures après... En fait ça dépend du débit, du système, du protocole...

En UDP, c'est du "send and forget". Celui qui reçoit doit être prêt, car l'émetteur balance ses paquets à la suite... Il y a des risques de perte ou de congestion. Néanmoins, un protocole 'supérieur' (TFTP, par exemple) peut gérer ça...

En TCP, chaque paquet est 'acquitté'. Le paquet suivant n'est émis que si le précédent est arrivé à bon port. Est-ce qu ça signifie qu'il a été lu ? Je ne pense pas (à vérifier dans la doc 'SOCKET'). Je pense que ça veut surtout dire qu'il a été reçu par le système et stocké en FIFO. Il y a risque de congestion si on dépasse le nombre de stockage autorisé, qui dépend du système...

Ou est ce que je suis obligé de faire un send()/recv() l'un après l'autre ?

Bah, ça dépend un peu de ton application (volume, débit , taille des paquets...). Tu veux faire quoi ?

Est ce que les paquets recu s'entassent dans un pile de type FIFO ?

Oui.

Il ne s'entasse pas sur un buffer de la carte réseaux ? Mais sur le buffer que l'on a créée vec le socket ?

Non. C'est dans le système. On n'y a pas accès...

Mais pourquoi toutes ces questions ? Essayes, tu verras bien...

[nuFox]

Enfait je dois réaliser une DLL de communication avec un serveur (donc moi je suis le client), cette DLL aura pour but d'envoyer et recevoir des paquets ...
(assez petit il ne depasse pas 14Byte de données). C'est dll est cyclique,

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
 
  // Step = 0 -> Initialisation + connection.
  if(step == 0){
    connection();
  }
 
  // Step = 1 -> Recuperer tout les parametres.
  if(step == 1){
 
    sending(2, cpt, 0);
    receive(cluster1, paramLv);
 
    // Compteur de passage dans initialisation
    cpt++;
 
    // Initialisation terminee
    if(cpt == NBPARAM){
      memcpy((void *)paramOld, (const void*)paramLv, NBPARAM);
      step = 2;
    }
  }
 
  //Step = 2 -> Envoyer et recevoir des données normalement.
  if(step == 2){
 
    //receive(cluster1, paramLv);
 
    // Boucle pour voir si le tableau des parametres a été modifié.
    for(cpt = 0; cpt < NBPARAM; cpt++){
      if(paramLv[cpt] != paramOld[cpt]){
        sending(3, cpt, paramLv[cpt]);
        receive(cluster1, paramLv);
        paramOld[cpt] = paramLv[cpt];
        cpt = NBPARAM;
      }
    }
 
    // Status and Measures reading (TCS request)
    cptReqStat++;
    if(cptReqStat == 10){
      sending(1,0,0);
      receive(cluster1, paramLv);
      cptReqStat = 0;
    }
  }
 
  //Step = 3 -> Deconnection.
  if(step == 3){
    close(); 
  }           
}

Pour la réalisation, chaque fois que je fais un send (sur le client vers le serveur), je fais le recv tout de suite ... Parce que dans la configuration du projet, le client envoie un message au serveur et le serveur lui renvoie la réponse ... Donc pour chaque send() effectué j'ai un recv() qui le suit (Pour ne pas que le recv() soit bloquant, j'utilise un select) ... Cette méthode me parrassait bonne (comme indiqué au dessus) ...

Mais la personne responsable de mon stage, voudrait que je fasse tout mes send() et ne faire qu'un recv() en premier donc :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
 
  //Fonction recv() qui va prendre les paquets sur la cible
  receive(cluster1, paramLv);
 
  // Step = 0 -> Initialisation + connection.
  if(step == 0){
    connection();
  }
 
  // Step = 1 -> Recuperer tout les parametres.
  if(step == 1){
 
    sending(2, cpt, 0);
 
    // Compteur de passage dans initialisation
    cpt++;
 
    // Initialisation terminee
    if(cpt == NBPARAM){
      memcpy((void *)paramOld, (const void*)paramLv, NBPARAM);
      step = 2;
    }
  }
 
  //Step = 2 -> Envoyer et recevoir des données normalement.
  if(step == 2){
 
    // Boucle pour voir si le tableau des parametres a été modifié.
    for(cpt = 0; cpt < NBPARAM; cpt++){
      if(paramLv[cpt] != paramOld[cpt]){
        sending(3, cpt, paramLv[cpt]);
        paramOld[cpt] = paramLv[cpt];
        cpt = NBPARAM;
      }
    }
 
    // Status and Measures reading (TCS request)
    cptReqStat++;
    if(cptReqStat == 10){
      sending(1,0,0);
      cptReqStat = 0;
    }
  }
 
  //Step = 3 -> Deconnection.
  if(step == 3){
    close(); 
  }           
}

Donc c'est pour ca que je voulais savoir si le socket stockait ces messages quelque part avant que l'on fasse un recv() ... Pour savoir si meme 4paquets sont arrivés, si je vais les recevoir dans l'ordre dans lequel je les ai demandé.

Et donc si j'ai bien compris, la fonction recv() va aller chercher les paquets sur la pile systeme ... ?

Merci de ton aide et du temps que tu passes sur mes questions !

[Emmanuel Delahaye]

Enfait je dois réaliser une DLL de communication avec un serveur (donc moi je suis le client), cette DLL aura pour but d'envoyer et recevoir des paquets ...

Bizarre. En général, on met la partie socket dans l'application. Pourquoi une DLL ? Enfin, je suppose que c'est possible... Et si plusieurs applications utilisent cette DLL, c'est prévu ? On sait qui fait quoi ? Les données sont bien contextuelles ?

(assez petit il ne depasse pas 14Byte de données). C'est dll est cyclique,

Je ne comprends pas cette phrase, il y a 2 verbes... Tu veux dire "Cette DLL est cyclique" ? Ca n'a aucun sens. Une DLL n'est pas un processus. Elle n'a pas de vie propre. C'est une bibliothèque qui dépend d'un processus courant (application).

Tu es sûr que ce n'est pas un 'service' (ou daemon) que tu veux faire ?

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
 
  // Step = 0 -> Initialisation + connection.
  if(step == 0){
    connection();
  }
 
  // Step = 1 -> Recuperer tout les parametres.
  if(step == 1){
 
    sending(2, cpt, 0);
    receive(cluster1, paramLv);
 
    // Compteur de passage dans initialisation
    cpt++;
 
    // Initialisation terminee
    if(cpt == NBPARAM){
      memcpy((void *)paramOld, (const void*)paramLv, NBPARAM);
      step = 2;
    }
  }
 
  //Step = 2 -> Envoyer et recevoir des données normalement.
  if(step == 2){
 
    //receive(cluster1, paramLv);
 
    // Boucle pour voir si le tableau des parametres a été modifié.
    for(cpt = 0; cpt < NBPARAM; cpt++){
      if(paramLv[cpt] != paramOld[cpt]){
        sending(3, cpt, paramLv[cpt]);
        receive(cluster1, paramLv);
        paramOld[cpt] = paramLv[cpt];
        cpt = NBPARAM;
      }
    }
 
    // Status and Measures reading (TCS request)
    cptReqStat++;
    if(cptReqStat == 10){
      sending(1,0,0);
      receive(cluster1, paramLv);
      cptReqStat = 0;
    }
  }
 
  //Step = 3 -> Deconnection.
  if(step == 3){
    close(); 
  }           
}

Euh, c'est le code quoi ça ? Il y a plein de fonctions inconnues... (connection(), sending(), receive()) C'est un automate ? Il est géré par qui ?

Pour la réalisation, chaque fois que je fais un send (sur le client vers le serveur),

Tu veux dire "du client vers le serveur ?"

je fais le recv tout de suite ... Parce que dans la configuration du projet, le client envoie un message au serveur et le serveur lui renvoie la réponse ... Donc pour chaque send() effectué j'ai un recv() qui le suit (Pour ne pas que le recv() soit bloquant, j'utilise un select) ... Cette méthode me parrassait bonne (comme indiqué au dessus) ...

Ca me parait correct. Le select() est aussi bloquant que le recv(), mais il peut se débloquer sur timeout... Attention, je rappelle que sous Windows, select() ne gère que les sockets.

Mais la personne responsable de mon stage, voudrait que je fasse tout mes send() et ne faire qu'un recv() en premier donc :

Comment ça en premier ? ON peut éventuellement faire ceci :

Code :

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

1
2
3
4
5
 
send()
send()
send()
recv()

mais pas l'inverse,

Code :

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

1
2
3
4
5
 
recv()
send()
send()
send()

ça n'a aucun sens pour un client.

Le protocle applicatif est forcément du genre

Code :

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

1
2
3
4
5
6
7
8
9
 
    Client      Serveur
      |           |
      |  commande |
send()| --------->|recv()
      |           |
      |  reponse  |
recv()| <---------|send()
      |           |

sinon, ça ne tient pas debout...