Transmission/Réception partielle de structure via socket

**Djakisback** · 07/12/2009, 13h16

Bonjour,
pourrait-on me confirmer que la continuité des données en mémoire d'une structure n'est pas garantie ? Mon idée est la suivante pour la définition d'une structure de requête de client à serveur. Mettons que pour une requête de type 0 on doive transmettre data1 et pour une requête de type 1 on doive transmettre data1 et data2 :

Code :

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

1
2
3
4
5
6
typedef struct {
	int requestType; 		
	int data1;
	char[20] data2;
	//etc...
} request;

Le client envoie toujours la même structure mais pas forcément en entier, ex :

Code :

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

1
2
3
4
5
6
7
request req;
//...
// Type 0, envoi de requestType et data1 uniquement (2 int)
ret = send(socket, (void*)&req, sizeof(int) * 2, 0);
 
// Type 1, envoi de requestType, data1 et data 2
ret = send(socket, (void*)&req, sizeof(int) * 2 + sizeof(char) * 20, 0);

Et du côté du serveur la réception se fait en fonction de requestType, ex :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
request req;
//...
// Réception du type de requête
ret = recv(socket, (void*)req->requestType, sizeOf(req.requestType), 0);
// Poursuite de la lecture des données
if(req->requestType > -1)  {
	ret = recv(socket, (void*)req->data1, sizeOf(req.data1), 0);
	if(req->requestType > 0)  {
		ret = recv(socket, (void*)req.data2, sizeOf(req.data2) * 20, 0);
	}
	//etc.
}

Pensez-vous que ce principe puisse fonctionner ? (a priori je dirais que non)
Merci d'avance.
(Je vais essayer de mon côté mais je n'ai pas de compilateur sous la main.

**orfix** · 07/12/2009, 14h01

Les éléments de la structure seront adjacents, mais pour des soucis d'alignement il se pourrait qu'il y ai des trous entre ces derniers ainsi qu'à la fin de la structure, auquel cas ceci ne fonctionnerais pas :

Code Djakisback :

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

1
2
3
4
5
6
7
request req;
//...
// Type 0, envoi de requestType et data1 uniquement (2 int)
ret = send(socket, (void*)&req, sizeof(int) * 2, 0);
 
// Type 1, envoi de requestType, data1 et data 2
ret = send(socket, (void*)&req, sizeof(int) * 2 + sizeof(char) * 20, 0);

moi je procéderais en plusieurs temps comme suit :

Code :

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

1
2
3
send(socket, &req.requestType, sizeof req.requestType, 0);
send(socket, &req.data1, sizeof req.data1, 0);
/* ...et ainsi de suite */

**Djakisback** · 07/12/2009, 16h18

Salut et merci pour ta réponse

Envoyé par ssmario2

Les éléments de la structure seront adjacents, mais pour des soucis d'alignement il se pourrait qu'il y ai des trous entre les derniers ainsi qu'à la fin de la structure, auquel cas ceci ne fonctionnerais pas

Effectivement je m'attendais à un truc du style ^^
Oui, donc si je fais l'envoi en plusieurs fois ça fonctionnera mais dans ce cas la structure n'a d'intérêt que pour le stockage local des données, dommage je trouvais l'idée sympa.

En gros de ce que je comprends, on a le choix entre :
- avoir plusieurs structures pour différents type de requêtes et complexifier le code serveur/client
- utiliser une structure de requête générique. Donc avoir du code simplifié mais envoyer des octets inutiles car non initialisés

**Mac LAK** · 07/12/2009, 16h53

Envoyé par Djakisback

Oui, donc si je fais l'envoi en plusieurs fois ça fonctionnera mais dans ce cas la structure n'a d'intérêt que pour le stockage local des données, dommage je trouvais l'idée sympa.

En fait, tu peux avoir deux parties plus ou moins distinctes pour ta structure : la partie "commune", déterminant notamment le type de requête, et la partie variable (dont la taille reste à définir par protocole et/ou par un champ de taille dans la requête elle-même). Pour émettre la partie commune (et surtout, en avoir la taille), il te suffit de faire la différence entre l'adresse du premier champ variable et l'adresse du début de la structure : ce sera constant sur la vie du programme, donc à voir si tu initialises une globale avec cette valeur (si c'est calculé systématiquement) ou si l'optimisation permet de le faire via un #define.

En ce cas, tu effectues seulement deux envois quel que soit la requête : le premier inconditionnellement, le second au sein d'un switch conditionné par l'identifiant de requête. Par contre, cela impose de connaître et de figer l'alignement de ta structure, ainsi que les tailles des données et l'endianness afin de garantir une communication fiable entre le client et le serveur. A titre de simplification, tu peux bien sûr décider d'utiliser du little-endian, mais habituellement, en réseau, c'est plutôt du big-endian que l'on utilise.

Envoyé par Djakisback

En gros de ce que je comprends, on a le choix entre :
- avoir plusieurs structures pour différents type de requêtes et complexifier le code serveur/client
- utiliser une structure de requête générique. Donc avoir du code simplifié mais envoyer des octets inutiles car non initialisés

Non, une seule structure contenant :

Un entête commun à toutes les requêtes (sous-structure ou envoi partiel),
Une union de N éléments variables en fonction de la requête définie dans l'entête.

Dans tous les cas, ne pas figer l'alignement, la taille des données et l'endianness lors d'une communication réseau binaire, c'est plutôt casse-gueule...

**Djakisback** · 08/12/2009, 10h21

Merci pour ces précisions

Mais à vrai dire je ne comprends pas bien, est-ce que tu aurais un exemple rapide ?
Car j'ai l'impression que d'après ce que tu dis, ce que je proposais dans mon premier exemple fonctionnerait ? Tu proposes bien d'envoyer la structure en 2 temps ? Mais le problème soulevé par ssmario2 reste le même non ?

[edit]En réalité, tu proposes d'envoyer une union de N éléments variables en fonction de la requête définie dans l'entête.[/edit] Donc si je comprends bien tu proposes d'envoyer toujours la même taille de données ?

**Mac LAK** · 08/12/2009, 10h50

Envoyé par Djakisback

Donc si je comprends bien tu proposes d'envoyer toujours la même taille de données ?

La taille de l'union est certes la taille de la plus grande de ses alternatives... Mais qui a dit que tu étais obligé d'envoyer le sizeof(union), en lieu et place du sizeof() spécifique associé à la requête ?

En gros (cf. points en rouge) :

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
typedef struct {
  struct header {
    int request_type ;
    int data1 ;
    char common_data[XXX] ;
    .....
  } h ;
  union data {
    struct data_r1 {
      char xxxx ;
    } d1 ;
    struct data_r2 {
      char yyyy[10000] ;
      float zzzz ;
    } d2 ;
    ......
  } d ;
} request ;


int send_request ( int socket, request* req ) {

  int ret ;

  ret = send(socket,&(req->h),sizeof(req->h),0);
  if (ret==0)
    switch (req->h.request_type) {
      case REQUEST1 :
        ret = send(socket,&(req->d.d1),sizeof(req->d.d1),0);
        break ;

      case REQUEST2 :
        ret = send(socket,&(req->d.d2),sizeof(req->d.d2),0);
        break ;

      default :
        ret = -1 ;
        break ;
    }
    return ret ;
}

C'est plus clair ?

**Djakisback** · 08/12/2009, 14h07

Oui merci c'est plus clair

Ca permet donc d'utiliser un seul type, le type 'request' et de ne faire que 2 envois, comme tu le disais (cette technique est pas mal du tout ^^).
En revanche, quand tu parles de fixer l'alignement, je ne comprends pas pourquoi cela peut poser un problème de ne pas le faire avec cette méthode ?

**Mac LAK** · 08/12/2009, 17h12

Parce que l'alignement ne sera pas forcément le même entre un code compilé avec Visual Studio, GCC, pour Windows ou Linux, sans parler des machines 64 bits et/ou ayant une endianness différente de ta machine de développement.

**Djakisback** · 08/12/2009, 17h35

ok, merci pour tout

Effectivement, je n'avais pas pensé à ça.
Je vais donc partir sur cette méthode.

**Mac LAK** · 08/12/2009, 17h43

Envoyé par Djakisback

ok, merci pour tout

Effectivement, je n'avais pas pensé à ça.
Je vais donc partir sur cette méthode.

De rien.

Je sais que ce genre de technique fait un peu "hack" sur les bords, mais c'est un truc assez courant au niveau d'une pile réseau afin de garantir des performances un minimum décentes.
Si tu peux assurer la présence de toutes les parties de l'union au même offset dans la structure (ça se teste facilement), tu peux carrément faire un seul envoi en sommant directement la taille de l'entête et des données, et en envoyant la structure de base avec cette somme : il te suffit alors de faire le switch avant, de préparer la taille des données, puis d'expédier le tout d'un bloc.

Par contre, garantir que les composants d'une union seront systématiquement alignés sur le même offset de la structure englobante peut poser quelques soucis. C'est négligeable lorsque l'on vérifie tout (inclus endianness), mais ça peut être source d'erreurs sur un code fait exclusivement pour une seule cible (et donc, moins "blindé" côté alignement).

**souviron34** · 09/12/2009, 13h33

disons que tant que les réseaux n'étaient pas très rapide, c'était un moyen efficace de communication directe..

Cela devient maintenant plus un inconvénient majeur (liens extrêmemement violents d'un binaire à l'autre) qu'un avantage..

Un passage "explicite" de la structure par mots clés est certainement le plus adapté de nos jours (et depuis un bon moment)..

**Mac LAK** · 09/12/2009, 14h59

Envoyé par souviron34

disons que tant que les réseaux n'étaient pas très rapide, c'était un moyen efficace de communication directe..

Cela devient maintenant plus un inconvénient majeur (liens extrêmemement violents d'un binaire à l'autre) qu'un avantage..

Un passage "explicite" de la structure par mots clés est certainement le plus adapté de nos jours (et depuis un bon moment)..

Je nuancerais un peu plus : tout dépend du niveau du protocole dans le modèle OSI... Si c'est le dernier (le plus haut), la communication non-binaire est souvent préférable pour des raisons de portabilité (cf. HTTP, FTP, SMTP, etc. qui fonctionnent ainsi).
En dessous, ou sur les bus de terrain, c'est par contre strictement nécessaire, notamment lorsque l'on n'a pas le choix du format de trame : il vaut mieux dans ce cas savoir comment ça marche et comment on résout le problème, par exemple en le faisant au moins une fois.

Réimplémenter TCP/IP en mode "texte" plutôt que binaire serait par exemple une énorme régression sur les performances...

**Médinoc** · 09/12/2009, 15h16

Un gros inconvénient du texte, c'est le fait de ne pas connaître la taille à l'avance. Même si je suppose qu'il y a des limites dans les normes.

**souviron34** · 09/12/2009, 15h41

Envoyé par Mac LAK

Je nuancerais un peu plus : tout dépend du niveau du protocole dans le modèle OSI... Si c'est le dernier (le plus haut), la communication non-binaire est souvent préférable pour des raisons de portabilité (cf. HTTP, FTP, SMTP, etc. qui fonctionnent ainsi).
En dessous, ou sur les bus de terrain, c'est par contre strictement nécessaire, notamment lorsque l'on n'a pas le choix du format de trame : il vaut mieux dans ce cas savoir comment ça marche et comment on résout le problème, par exemple en le faisant au moins une fois.

Réimplémenter TCP/IP en mode "texte" plutôt que binaire serait par exemple une énorme régression sur les performances...

C'est sûr, mais vu la question du PO, et celles en général posées ici, les POs ne travaillent pas sur des bus..

Dans le cadre d'un logiciel, même très complexe, mais ayant par exemple 6 ou 7 binaires distincts, pouvant tourner sur des machines distinctes, mais nécessitant un temps réponse "quasi-réel", ce qui pouvait se comprendre à la fin des annes 80 st aujourdhui largement dépassé et contraignant..

J'ai eu il y a maintenant presque 2 ans à travailler sur un simulateur d'aéroport, dont la structure était celle-ci, toutes les structure se passant en binaires..

L'imposition de mise à jour (et de compilation) de l'ensemble alors qu'on ne rajoutait qu'un flag utile juste entre 2 binaires devenait rhédibitoire (6h de compil)..

L'avantage d'un protocole ASCII de passage de structures étant justement la possible hétérogénéité des versions, pour peu que les mots ne changent pas, mais qu'ils s'en rajoutent..

Envoyé par Médinoc

Un gros inconvénient du texte, c'est le fait de ne pas connaître la taille à l'avance. Même si je suppose qu'il y a des limites dans les normes.

Euh.. Je ne vois pas de quoi tu parles...

**Médinoc** · 09/12/2009, 15h52

Tu ne connais pas à l'avance la longueur d'une ligne, donc la meilleure taille pour ton buffer.
Alors qu'en binaire, tu peux toujours te faire un format avec la taille en premier, puis les données...

**souviron34** · 09/12/2009, 16h58

qu'est-ce que ça a à voir, la taille d'une ligne, dans un protocole ASCII ?

Tu envoies un message de 1000, 4000, 100000 caractères d'affilée, ça ne pose aucun problème ..

On en donne ici des exemples régulièrement..

Tu peux très bien faire un bloc de 60 000 caractères sans faire de retour à la ligne..

Je ne vois pas où tu vois un problème...

Code :

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

1
2
while socket != empty
   recv..

**Médinoc** · 09/12/2009, 17h17

Envoyé par souviron34

Tu peux très bien faire un bloc de 60 000 caractères sans faire de retour à la ligne..

Je ne vois pas où tu vois un problème...

Mais c'est justement le problème. La plupart des protocoles ASCII sont gérés au niveau ligne, donc tu te retrouves à avoir besoin de realloc() en boucle avant de pouvoir commencer à interpréter la demande du client!

...Ou bien, tu fixes une taille maximale et pour tout ce qui dépasse, tu retournes HTTP 414: Way Too F#%&ing Long.

Désolé si j'ai l'air d'avoir un poil dans la main, mais moi je préfère connaître à l'avance la taille que je suis censé recevoir. Je n'aime pas les realloc() en boucle, donc si je peux faire autrement, je ne m'en prive pas.

**souviron34** · 09/12/2009, 17h53

Envoyé par Médinoc

Mais c'est justement le problème. La plupart des protocoles ASCII sont gérés au niveau ligne, donc tu te retrouves à avoir besoin de realloc() en boucle avant de pouvoir commencer à interpréter la demande du client!

...Ou bien, tu fixes une taille maximale et pour tout ce qui dépasse, tu retournes HTTP 414: Way Too F#%&ing Long.

Désolé si j'ai l'air d'avoir un poil dans la main, mais moi je préfère connaître à l'avance la taille que je suis censé recevoir. Je n'aime pas les realloc() en boucle, donc si je peux faire autrement, je ne m'en prive pas.

tu parles de protocoles ASCII...

LESQUELS SONT GERES AU NIVEAU LIGNE ???

Pas un protocole digne de ce nom..

Maintenant, si tu ne souhaites pas faire de rzlloc, c'est on choix, mais ça n'est pas celui qui est en général..

Et de plus, dans le cas du passage de strcutures, faut pas charrier, un tableau de 5 à 10 000 caractères devrait suffire à passer de TRES grosses strcutures complexes..

Moi je passais des grilles de modèles atmosphériques de la Terre en une seule fois... (avec non seulement les coordonées des points (lat/lon) mais par exemple la valeur des températures ou des vents, le tout dans le même message...

Donc plutôt des séries de points..

Mais passer une structure, même si elle a 50 ou 60 paramètres, c'est pas la mort...

Tu peux par exemple faire des buffers de 10 000, et éventuellement réallouer par pas de 10 000...

Franchement, je ne vois pas le problème..

D'ailleurs, c'est ce que (devrait) faire un navigateur/interpreteur HTML, puisque rien n'est dans la nome HTML pour des retours charriots.. Donc tout une page pourrait être sur une seule ligne... (on en avait déjà parlé ailleurs, il me semble (et j'avais trouvé ça absurde))..

**Mac LAK** · 09/12/2009, 18h01

Envoyé par souviron34

C'est sûr, mais vu la question du PO, et celles en général posées ici, les POs ne travaillent pas sur des bus..

Pas gagné d'avance, j'ai déjà vu des questions sur Modbus ou des protocoles bas niveau (type RS-232) ici...

Envoyé par souviron34

L'imposition de mise à jour (et de compilation) de l'ensemble alors qu'on ne rajoutait qu'un flag utile juste entre 2 binaires devenait rhédibitoire (6h de compil)..

Je dirais "structure binaire mal conçue", car binaire ne veut pas dire non-évolutif (exemple concret : payload d'une trame Ethernet / IP / UDP / TCP, vraiment au hasard).
Certes, c'est plus contraignant en binaire qu'en ASCII.

Toutefois, il est illusoire de croire que ce n'était utile que dans les années 80 : c'est non seulement toujours d'actualité, très vastement utilisé, et comme je le précisais les protocoles courant de transport (Ethernet et TCP/IP principalement) sont basés sur ce principe.
Côté "autres bus / protocoles", tu peux avoir, en vrac : CAN, MVB, Arinc, Modbus, AFDX, USB, FireWire, PCI / PCIe, et de façon générale toute communication avec un (micro)contrôleur et autres DSP / FPGA...

Envoyé par souviron34

L'avantage d'un protocole ASCII de passage de structures étant justement la possible hétérogénéité des versions, pour peu que les mots ne changent pas, mais qu'ils s'en rajoutent..

La même chose est possible en binaire, à condition d'avoir prévu à la base d'utiliser un champ "version" et un champ "taille" faisant partie intégrante du message.
Cependant, même en ASCII, ça peut planter : j'ai déjà vu (souvent) ce genre de protocole planter parce qu'une clé inconnue est considérée comme une erreur lexicale, et envoie donc gentiment la trame aux orties...

De plus, l'ASCII ne règle QUE le problème d'endianness et d'alignement. Il te reste toujours le problème des tailles des données (réadaptation dynamique à chaque valeur et/ou réservation maximale), et tu peux introduire des nouveaux problèmes qui peuvent devenir velus (au hasard, l'Unicode et l'encodage des caractères). De plus, en fonction de la cible choisie, la (dé)sérialisation des données vers de l'ASCII peut devenir assez vite un gouffre à temps CPU. Enfin, le C n'est pas aussi bien équipé que le C++ à ce niveau, ce qui oblige soit à faire des send unitaires (risque de fragmentation lourde sur le réseau), soit à utiliser des buffers monstrueux...

@Médinoc : +1, j'ai également horreur des réallocations sauvages au milieu des boucles de réception... Si l'on veut un truc robuste, cela finit en général par un automate à états alimenté par le flux de données, et c'est franchement pénible au final.

Envoyé par souviron34

tu parles de protocoles ASCII...
LESQUELS SONT GERES AU NIVEAU LIGNE ???

...

D'ailleurs, c'est ce que (devrait) faire un navigateur/interpreteur HTML, puisque rien n'est dans la nome HTML pour des retours charriots.. Donc tout une page pourrait être sur une seule ligne... (on en avait déjà parlé ailleurs, il me semble (et j'avais trouvé ça absurde))..

HTML n'est pas un protocole : c'est HTTP qui est dessous la plupart du temps... Et ce protocole, comme Telnet, FTP ou encore SMTP/POP3, impose une commande ligne par ligne, et des fins de lignes normalisées (CR/LF, d'ailleurs).

Ce qui n'empêche absolument pas d'expédier la page sous forme d'une seule ligne, d'ailleurs, c'est même une technique de "compression" des pages HTML assez utilisée. Et derrière, ben il faut réussir à la supporter au niveau du client HTTP, avant de la passer à l'interpréteur HTML...