Transmission de données par réseaux

none a écrit

Bonjour,

Créer une communication réseaux via les appel systèmes ne pose généralement
aucun soucis, ceci quelquel soit l'OS utilisé. Les données alors transmise
sont au préalable mise dans un buffer.

La question que je me pose depuis que je fait ce genre de manipulation, c'est
comment faites-vous pour transmettre le contenu d'une structure ? Surtout
lorsque celle-ci possède des pointeurs sur autre structure ou tableau de
char.

Ce que je fait depuis longtemps, c'est un construction d'une chaine pour
transmettre les informations. Mais il faut que je modifie cette construction
de chaine chaque fois que je modifie la structure, nécessitant également le
décodage de l'autre coté.

Donc la question est simple, avez-vous une méthode différente pour
transmettre le contenu d'une structure? Y compris lorsque elle est chainées?

Merci pour vos commentaires.
Vincent

ASN.1 et XML sont de bonnes pistes

Bonsoir.

"none" <""vb"@(none)"> a écrit dans le message de news:
46f8e0c6$0$32052$426a74cc@news.free.fr...

[...]

Donc la question est simple, avez-vous une méthode différente pour
transmettre le contenu d'une structure? Y compris lorsque elle est
chainées?

Merci pour vos commentaires.

Voir (par exemple) les explications sur les attributs des pointeurs en MIDL
(DCOM):
http://msdn2.microsoft.com/en-us/library/aa366731.aspx
Et particulièrement cette page qui détaille la stratégie:
http://msdn2.microsoft.com/en-us/library/aa367149.aspx

Selon les liens entre structures, ça peut être assez complexe.

--
Cordialement.
--
/**************************************************
* Patrick BRUNET
* E-mail: lien sur http://zener131.free.fr/ContactMe
**************************************************/

On 25 sep, 12:19, none <""vb"@(none)"> wrote:

Bonjour,

Créer une communication réseaux via les appel systèmes ne pose
généralement aucun soucis, ceci quelquel soit l'OS utilisé. Les don nées
alors transmise sont au préalable mise dans un buffer.

La question que je me pose depuis que je fait ce genre de manipulation,
c'est comment faites-vous pour transmettre le contenu d'une structure ?
Surtout lorsque celle-ci possède des pointeurs sur autre structure ou
tableau de char.

Ce que je fait depuis longtemps, c'est un construction d'une chaine pour
transmettre les informations. Mais il faut que je modifie cette
construction de chaine chaque fois que je modifie la structure,
nécessitant également le décodage de l'autre coté.

Donc la question est simple, avez-vous une méthode différente pour
transmettre le contenu d'une structure? Y compris lorsque elle est
chainées?

Merci pour vos commentaires.
Vincent

Je ne suis pas sur de comprendre ce que tu veux dire par "une
construction de chaine pour transmettre ". Pour
une variable x, il te suffit d'envoyer sendto( sd , &x,
sizeof(x)) , .. , .. , ..); Bien evidement, quand il s'agit d'une
structure chainee, il faut gerer les (re)-allocations en reception.
Par exemple,la reception d'une liste d'objets :

while ( 1 ) {
ne s'agit pas d'une probemetique de type reseau
Tu as exactement la meme problematique quand
tu transmets tes donnees via un disque..
PL

On 29 sep, 14:35, michko <lange...@univ-tln.fr> wrote:

On 25 sep, 12:19, none <""vb"@(none)"> wrote:

Bonjour,

Créer une communication réseaux via les appel systèmes ne pose
généralement aucun soucis, ceci quelquel soit l'OS utilisé. Les d onnées
alors transmise sont au préalable mise dans un buffer.

La question que je me pose depuis que je fait ce genre de manipulation,
c'est comment faites-vous pour transmettre le contenu d'une structure ?
Surtout lorsque celle-ci possède des pointeurs sur autre structure ou
tableau de char.

Ce que je fait depuis longtemps, c'est un construction d'une chaine pour
transmettre les informations. Mais il faut que je modifie cette
construction de chaine chaque fois que je modifie la structure,
nécessitant également le décodage de l'autre coté.

Donc la question est simple, avez-vous une méthode différente pour
transmettre le contenu d'une structure? Y compris lorsque elle est
chainées?

Merci pour vos commentaires.
Vincent

Je ne suis pas sur de comprendre ce que tu veux dire par "une
construction de chaine pour transmettre ". Pour
une variable x, il te suffit d'envoyer sendto( sd , &x,
sizeof(x)) , .. , .. , ..); Bien evidement, quand il s'agit d'une
structure chainee, il faut gerer les (re)-allocations en reception.
Par exemple,la reception d'une liste d'objets :

while ( 1 ) {
ne s'agit pas d'une probemetique de type reseau
Tu as exactement la meme problematique quand
tu transmets tes donnees via un disque..
PL

Desole mais un clic maladroit et ...

while ( 1) {
adr = lecture de 4 ioctets;
if ( adr ) {

}
else return res;
}

On 29 sep, 14:42, michko <lange...@univ-tln.fr> wrote:

On 29 sep, 14:35, michko <lange...@univ-tln.fr> wrote:

On 25 sep, 12:19, none <""vb"@(none)"> wrote:

Bonjour,

Créer une communication réseaux via les appel systèmes ne pose
généralement aucun soucis, ceci quelquel soit l'OS utilisé. Les données
alors transmise sont au préalable mise dans un buffer.

La question que je me pose depuis que je fait ce genre de manipulatio n,
c'est comment faites-vous pour transmettre le contenu d'une structure ?
Surtout lorsque celle-ci possède des pointeurs sur autre structure ou
tableau de char.

Ce que je fait depuis longtemps, c'est un construction d'une chaine p our
transmettre les informations. Mais il faut que je modifie cette
construction de chaine chaque fois que je modifie la structure,
nécessitant également le décodage de l'autre coté.

Donc la question est simple, avez-vous une méthode différente pour
transmettre le contenu d'une structure? Y compris lorsque elle est
chainées?

Merci pour vos commentaires.
Vincent

Je ne suis pas sur de comprendre ce que tu veux dire par "une
construction de chaine pour transmettre ". Pour
une variable x, il te suffit d'envoyer sendto( sd , &x,
sizeof(x)) , .. , .. , ..); Bien evidement, quand il s'agit d'une
structure chainee, il faut gerer les (re)-allocations en reception.
Par exemple,la reception d'une liste d'objets :

while ( 1 ) {
ne s'agit pas d'une probemetique de type reseau
Tu as exactement la meme problematique quand
tu transmets tes donnees via un disque..
PL

Desole mais un clic maladroit et ...

while ( 1) {
adr = lecture de 4 ioctets;
if ( adr ) {

}
else return res;

}

Re-Re desole, je ne vois pas quel raccourci clavier publie le message
alors que je suis en edition... Donc,
je pensais au pseudo code :
enr * lirechaine( )
{enr *aux;
void *adr;
while ( 1 ) {
adr = lecture de 4 ioctets;
if ( adr ) {
aux = allocation;
*aux = lecture de la structure;
res = chainage(res, aux );
}
else return res;
}
}
sous entendu, cote l'emetteur j'envoie adresse/objet du premier,
adresse/objet du second etc...

PL

michko a écrit

On 29 sep, 14:42, michko <lange...@univ-tln.fr> wrote:

On 29 sep, 14:35, michko <lange...@univ-tln.fr> wrote:

On 25 sep, 12:19, none <""vb"@(none)"> wrote:

Bonjour,

Créer une communication réseaux via les appel systèmes ne pose
généralement aucun soucis, ceci quelquel soit l'OS utilisé. Les données
alors transmise sont au préalable mise dans un buffer.
La question que je me pose depuis que je fait ce genre de manipulation,
c'est comment faites-vous pour transmettre le contenu d'une structure ?
Surtout lorsque celle-ci possède des pointeurs sur autre structure ou
tableau de char.

Ce que je fait depuis longtemps, c'est un construction d'une chaine pour
transmettre les informations. Mais il faut que je modifie cette
construction de chaine chaque fois que je modifie la structure,
nécessitant également le décodage de l'autre coté.
Donc la question est simple, avez-vous une méthode différente pour
transmettre le contenu d'une structure? Y compris lorsque elle est
chainées?

Merci pour vos commentaires.
Vincent

Je ne suis pas sur de comprendre ce que tu veux dire par "une
construction de chaine pour transmettre ". Pour
une variable x, il te suffit d'envoyer sendto( sd , &x,
sizeof(x)) , .. , .. , ..); Bien evidement, quand il s'agit d'une
structure chainee, il faut gerer les (re)-allocations en reception.
Par exemple,la reception d'une liste d'objets :
while ( 1 ) {
ne s'agit pas d'une probemetique de type reseau
Tu as exactement la meme problematique quand
tu transmets tes donnees via un disque..
PL

Desole mais un clic maladroit et ...

while ( 1) {
adr = lecture de 4 ioctets;
if ( adr ) {

}
else return res;

}

Re-Re desole, je ne vois pas quel raccourci clavier publie le message
alors que je suis en edition... Donc,
je pensais au pseudo code :
enr * lirechaine( )
{enr *aux;
void *adr;
while ( 1 ) {
adr = lecture de 4 ioctets;
if ( adr ) {
aux = allocation;
*aux = lecture de la structure;
res = chainage(res, aux );
}
else return res;
}
}
sous entendu, cote l'emetteur j'envoie adresse/objet du premier,
adresse/objet du second etc...

PL

Ca, ca n'est valable qu'entre 2 machines d'architecture identique.
Sinon les petits et les gros endians se bastonnent sérieux ;-)

D'où l'intéret de ASN.1 ou XML

Bonjour.

"ALain Montfranc" <x@x.con> a écrit dans le message de news:
mn.f1e17d797293df85.51095@x.con...

michko a écrit

On 29 sep, 14:42, michko <lange...@univ-tln.fr> wrote:

On 29 sep, 14:35, michko <lange...@univ-tln.fr> wrote:

On 25 sep, 12:19, none <""vb"@(none)"> wrote:

Créer une communication réseaux via les appel systèmes ne pose
généralement aucun soucis, ceci quelquel soit l'OS utilisé. Les
données

alors transmise sont au préalable mise dans un buffer.
La question que je me pose depuis que je fait ce genre de
manipulation,

c'est comment faites-vous pour transmettre le contenu d'une structure
?

Surtout lorsque celle-ci possède des pointeurs sur autre structure ou
tableau de char.
[...]

sous entendu, cote l'emetteur j'envoie adresse/objet du premier,
adresse/objet du second etc...

Ca, ca n'est valable qu'entre 2 machines d'architecture identique.
Sinon les petits et les gros endians se bastonnent sérieux ;-)

D'où l'intéret de ASN.1 ou XML

Bien qu'il soit à la mode, je ne suis pas du tout convaincu de l'intérêt
technique de faire un encodage dans un format textuel.

Notamment, le parsing à la réception est généralement écrit avec des moteurs
à objets qui moulinent du malloc et des copies de buffer à n'en plus finir,
donc du point de vue des performances, c'est catastrophique tant pour la
transmission que pour la manipulation.

Un encodage textuel ne présente que deux intérêts:

- être humainement lisible, ce qui implique une indentation correcte et donc
rajoute du poids. Si on doit régénérer une forme lisible à partir d'une
forme compacte, nul besoin que celle-ci utilise le même encodage,

- si on peut se limiter au jeu de caractères ASCII, donc encodés sur 8 bits,
le texte ne pose pas de problèmes d'endianness. Mais les caractères
exotiques (de plus en plus fréquents) doivent être encodés en &entities; ou
autres &#69; ce qui peut vite faire lourd, et je ne parle pas des pointeurs,
transformés en liens vers des balises...

D'ailleurs il est regrettable que dès l'utilisation d'Unicode, pourtant
récent, le problème d'endianness réapparaisse :o) C'est symptomatique de la
stratégie de guéguerre stérile qui remplace le bon sens dans ce domaine.
Bon, ils ont tout de même prévu un tag au début pour détecter l'encodage...

Et bien je pense que compiler une forme structurée en une forme binaire
portable (sans pointeurs sortants) à endianness connue représente une énorme
optimisation dans l'objectif énoncé qui est de communiquer des données sur
un réseau. Même si l'une des stations a la malchance d'être du mauvais sexe,
retourner systématiquement tous les champs binaires coutera toujours moins
cher que la rédaction et le parsing du langage textuel.

Je crois que le problème initial de l'OP était de trouver comment compiler
une forme structurée en une forme portable (sans pointeurs sortants). C'est
pourquoi j'ai proposé la doc sur les attributs de pointeurs de MIDL.
En effet, on voit bien que les différents espaces pointés vont devoir être
agrégés à la structure initiale, et les pointeurs transformés en index dans
le blob résultant. Et donc ces pointeurs ont des statuts variés:
- il y a les pointeurs dont la cible est non-modifiable et qui sont des
raccourcis dans le blob,
- il y a les pointeurs dont la cible est une zone privée, de taille connue,
modifiable ou pas, pas forcément déjà allouée,
- et il y a les pointeurs généraux, dont la cible est une zone partagée avec
d'autres pointeurs, éventuellement avec des cycles...
Donc l'algorithme doit être capable de calculer la portée d'un pointeur et
les relations entre ces zones, en tenant compte de leur caractère modifiable
ou pas...

Quel que soit l'encodage choisi, c'est ce travail d'analyse qui n'est pas
simple du tout à réaliser, mais il est inévitable dès lors qu'on doit
sérialiser une structure, qu'il s'agisse de la transmettre sur le réseau ou
de l'écrire sur un média.

--
Cordialement.
--
/**************************************************
* Patrick BRUNET
* E-mail: lien sur http://zener131.free.fr/ContactMe
**************************************************/

Le 30/09/07 8:01, dans <mn.f1e17d797293df85.51095@x.con>, « ALain
Montfranc » <x@x.con> a écrit :

Ca, ca n'est valable qu'entre 2 machines d'architecture identique.
Sinon les petits et les gros endians se bastonnent sérieux ;-)

Il faut aussi des pointeurs de même taille (certains CPU ont plusieurs modes
possibles). Il faut aussi utiliser le même compilateur avec les mêmes
options et le même système d'exploitation des 2 côtés (en particulier à
cause du padding des structures).

--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.

Bonjour.

"Eric Levenez" <usenet@levenez.com> a écrit dans le message de news:
C32528A8.B62DF%usenet@levenez.com...

Le 30/09/07 8:01, dans <mn.f1e17d797293df85.51095@x.con>, « ALain

Ca, ca n'est valable qu'entre 2 machines d'architecture identique.
Sinon les petits et les gros endians se bastonnent sérieux ;-)

Il faut aussi des pointeurs de même taille (certains CPU ont plusieurs
modes possibles).

De toute manière, on ne peut pas transmettre des pointeurs, seulement des
offsets dans le blob binaire agrégeant des copies des différentes zones
pointées.
Par contre on peut prévoir des champs capables de contenir un offset et un
pointeur au format le plus gros sur les machines envisagées. Ainsi il peut
être recalculé in situ.

Il faut aussi utiliser le même compilateur avec les mêmes
options et le même système d'exploitation des 2 côtés (en particulier
à cause du padding des structures).

Exact pour le problème, pas forcément d'accord pour le compilo: il existe
des normes dans l'encodage des types binaires (sauf les pointeurs), la
variante principale étant l'endianness. Donc si on prévoit de convertir les
pointeurs, le reste doit être gérable par un compilo différent à la
contrainte suivante près:
- Dans un souci de généricité, le blob doit être composé en respectant les
contraintes d'alignement les plus sévères (dans la limite du raisonnable
comme toujours).

Evidemment c'est plus complexe et moins hi-tech qu'une belle page de XML,
mais c'est techniquement tout à fait possible, et dans un contexte de
communication réseau plus ou moins intensive entre des bécanes qui se
veulent raisonnables, c'est même souhaitable pour les performances (AMHA).

--
Cordialement.
--
/**************************************************
* Patrick BRUNET
* E-mail: lien sur http://zener131.free.fr/ContactMe
**************************************************/

Le 30/09/07 11:38, dans <fdnqqn$rfu$1@shakotay.alphanet.ch>, « Patrick
'Zener' Brunet » <use.link.in.signature@ddress.invalid> a écrit :

Bonjour.

"Eric Levenez" <usenet@levenez.com> a écrit dans le message de news:
C32528A8.B62DF%usenet@levenez.com...

Le 30/09/07 8:01, dans <mn.f1e17d797293df85.51095@x.con>, « ALain

Ca, ca n'est valable qu'entre 2 machines d'architecture identique.
Sinon les petits et les gros endians se bastonnent sérieux ;-)

Il faut aussi des pointeurs de même taille (certains CPU ont plusieurs
modes possibles).

De toute manière, on ne peut pas transmettre des pointeurs, seulement des
offsets dans le blob binaire agrégeant des copies des différentes zones
pointées.
Par contre on peut prévoir des champs capables de contenir un offset et un
pointeur au format le plus gros sur les machines envisagées. Ainsi il peut
être recalculé in situ.

Je ne crois pas que transformer les pointeurs en simples offsets soient une
meilleure solution. Un pointeur est généralement un offset à partir de 0.
Les adresses du chaînage peuvent être très différentes les unes des autres.
Trouver la base d'un offset commun n'est pas évident car au cours de la vie
du programme, les adresses des structures peuvent changer considérablement.
Autant avoir un offset à partir de l'adresse 0, soit avoir directement une
adresse.

Au lieu d'offset, un identificateur type entier incrémenté à partir de 0,
pourrait très bien convenir. Par contre cela annule la demande initiale qui
étaient, en particulier, sur la transmission de pointeurs.

Il faut aussi utiliser le même compilateur avec les mêmes
options et le même système d'exploitation des 2 côtés (en particulier
à cause du padding des structures).

Exact pour le problème, pas forcément d'accord pour le compilo: il existe
des normes dans l'encodage des types binaires (sauf les pointeurs), la

Deux machines données peuvent ne pas utiliser le même encodage binaire. Une
peut utiliser du complément à 2 pour les int, et l'autre du complément à 1.
Le problème est justement qu'il existe non pas une norme, mais des normes.

Il y a aussi la taille des types. Par exemple j'utilise un DSP qui a des
char de 32 bits. Si je fais une structure avec un char et que je la
transmets à une machine type x86, il faudra réécrire la structure cible en
remplaçant les char par des longs.

variante principale étant l'endianness.

C'est juste un des problèmes. Le padding est aussi très piégeux car il
dépend totalement du compilateur et de ses options. Les options par défaut
servent juste à utiliser les bibliothèques du système.

Donc si on prévoit de convertir les
pointeurs,

Si... :-)

le reste doit être gérable par un compilo différent à la
contrainte suivante près:

Oui, tout est gérable si l'on contrôle les 2 côtés de la transmission et que
l'on est prêt à des compromis.

--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.