Transmissions réseau

Bloutiouf wrote:

Je ne sais pas si je suis sur le bon groupe, mais je n'en
trouve pas de plus adaptés que celui-ci. Je développe une
petite application réseau (un serveur, chaque client se
connecte dessus) mais j'ai un doute.

Globalement, ce sont des chaines qui sont envoyées par socket
et mises dans un buffer. Ces chaines contiennent logiquement
une commande et tous les paramètres. J'ai fait un premier jet
de mon travail, en séparant les commandes par Â, les
paramètres par Ê, etc. m'étant dit qu'en langue, on ne met pas
d'accent sur des majuscules

En quelle langue. En français, il est généralement considéré
préférable de les mettre -- on pourrait même dire que ne pas les
mettre est une faute d'orthographe.

donc qu'on utiliserait pas ces caractères, au passage que
j'interdis (je les transforme en A, E, etc). Ca marche bien,
les commandes sont donc du genre "loginÊmyloginÊmypasswordÂ"
(le  est à la fin pour vérifier qu'on a bien dans le buffer
la totalité de la commande).

Seulement, je me dis que c'est pas très professionnel, et
qu'il devrait bien exister des solutions (quant à ces  et
tout). Les recherches sur google ne sont capables que de me
dire comment sont connectés les clients...

En gros, il faut que tu définisses un protocol. Qui peut être
basé sur texte, ou binaire. Les protocols basés sur texte sont
les plus facile à debogguer -- un tel protocol est, grosso modo,
un petit langage. Si on se base sur Internet ASCII, par exemple,
chaque message commencera par un en-tête, suivi éventuellement
d'un bloc de données. Voir SMTP, par exemple, ou HTTP -- ton
protocol pourrait très bien se modéler sur HTTP, j'imagine --
pour la commande LOGIN, par exemple, on aurait :
LOGIN
user: toto
password: titi
...
le tout qui se termine par une ligne vide.

Les protocols binaires sont nettement plus difficile à mettre au
point. A priori, j'imagine qu'il y aurait une en-tête de block
commune à toutes les commands, avec entre autres informations la
commande même (encodée sur un entier, avec des valeurs
enumérées). Ensuite, les données propre à la commande, avec une
structure propre pour chaque commande.

La façon « classique » d'encoder une chaîne dans un protocol
binaire, c'est d'en envoyer la longueur sur un entier, suivi des
caractères. Suivi éventuellement des caractères de rembourrage
pour assurer l'alignement des données suivantes. (Pour des
raisons historiques, beaucoup de protocols binaires démandent
que tous les champs commencent à un offset multiple de quatre.)
Donc, XDR envoie le nombre de caractères sur quatres octets,
octet de poid fort d'abord, suivi des n caractères, suivi de 0 à
3 octets à 0, de façon à ce que le nombre total d'octets envoyé
soit un multiple de 4. BER enverra un 0x14 pour dire qu'il
s'agit d'une chaîne de caractères à huit bits, suivi de la
longueur de la chaîne sur un octet, si c'est moins de 128, ou
sur 2 à 128 octets, si c'est plus longue, suivi des caractères
même.

Je m'adresse à toute personne ayant déjà fait une telle
application, évidemment celles qui ont des idées aussi :p ,
pour me dire comment elles ont fait / auraient fait. Merci
beaucoup.

Il n'y a pas de règle générale -- tout dépend de ce que fait le
serveur, les données à transférer, etc.

Dans le cas des protocols binaires un peu complexe, il est usual
d'utiliser des générateurs de code pour les données qui
transitent sur le liaison.

--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

BOUCNIAUX Benjamin wrote:

Je ne sais pas si je suis sur le bon groupe, mais je n'en
trouve pas de plus adaptés que celui-ci. Je développe une
petite application réseau (un serveur, chaque client se
connecte dessus) mais j'ai un doute.

Globalement, ce sont des chaines qui sont envoyées par
socket et mises dans un buffer. Ces chaines contiennent
logiquement une commande et tous les paramètres. J'ai fait
un premier jet de mon travail, en séparant les commandes par
Â, les paramètres par Ê, etc. m'étant dit qu'en langue, on
ne met pas d'accent sur des majuscules donc qu'on
utiliserait pas ces caractères, au passage que j'interdis
(je les transforme en A, E, etc). Ca marche bien, les
commandes sont donc du genre "loginÊmyloginÊmypasswordÂ" (le
 est à la fin pour vérifier qu'on a bien dans le buffer la
totalité de la commande).

Seulement, je me dis que c'est pas très professionnel, et
qu'il devrait bien exister des solutions (quant à ces  et
tout). Les recherches sur google ne sont capables que de me
dire comment sont connectés les clients...

Je m'adresse à toute personne ayant déjà fait une telle
application, évidemment celles qui ont des idées aussi :p ,
pour me dire comment elles ont fait / auraient fait. Merci
beaucoup.

Je vais dire ca comme ca, mais ne pourrais tu pas 'structurer'
tes commandes (en gros définir ce qu'elles vont contenir, de
manière à pouvoir les typer).
Ensuite, tu les envoies sur le réseau, tu les receptionnes
dans un buffer ayant la meme structure, et tu peux ensuite
récupérer les champs nécessaires.

D'accord, mais tu ne dis pas comment, et c'est ça, sa question.
Simplement écrire une struct C/C++ au moyen de ostream::write,
et s'attendre à pouvoir le lire de l'autre bout, ne marche pas.
Alors, qu'en faire.

Cela dit, il faudrait que tu connaisses le format de tes
commandes, le nombre d'arguments à passer, etc etc...

Ça, de toute façon. (Mais j'ai l'impression qu'il en est
conscient, et qu'il a déjà fait cette partie du travail.)

--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

Bloutiouf wrote:

François-Xavier GENDRIN wrote:

Pourquoi ne pas faire du XML ? Quitte à faire du texte ...

Oula ! Surcharge surcharge ;) c'est vrai que ca serait une
bonne solution, s'il ne fallait pas réduire presque au maximum
la taille de la chaine (ca occupe de la bande passante tout
ca).

Réduire au maximum, tu en es sûr ? Vue le coût déjà de IP et de
TCP, je ne crois pas que tu es à un octet près. (Ce qui ne veut
pas dire que XML est forcément un bon choix. Ce n'est pas parce
qu'on n'est pas à un octet près qu'il faut chercher à faire
compliquer quand on peut faire simple.)

--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

Marc Boyer wrote:

Autrement dit, en reprenant l'exemple, la chaine
contiendrait "'login' 'mylogin' 'mypassword'" et le vector
contiendrait les chaines "login", "mylogin" et "mypassword"
? Ca peut être interessant ! Y a t il une fonction déjà
toute faite pour rapidement ajouter des '' ?

Je ne sais pas comment t'arrive les commandes, et je ne sais
pas si tu as autre chose à faire que de les transmettre.

Mais c'était en effet mon idée.

Quand à la 'fonction toute faite', non, je ne sais pas.
Peut-etre un usage détourne de accumulate. Sinon, une bête
boucle, une string et +=.

J'en ai une, ou plutôt une classe (Gabi::ParsableString).
Ajouter, c'est assez simple, mais enlever à la reception, en
traitant tous les cas possible d'erreur, c'est autre chose.
J'accepte ' ou " comme délimiteur (mais les deux doivent être
identique) ; j'accepte aussi toutes les séquences d'échappement
habituelles : "n" pour fin de ligne, etc. Aussi, dans le cas où
la chaîne ne contient que des alphanumériques, je me passe des
separateurs.

De la doc :

A wrapper for strings used for parsing input and formatting
output.

Unlike std::string itself, the output is guaranteed to be in
a format which can be recovered by input.

Like for char const* and std::string, >> inputs words, and
<< outputs words. In this case, however, the definition of
word is more complex; a word is either one or more
characters in the set [[:alnum:]_], or a quoted string,
delimited by either ''' or '"', and terminated by the
corresponding delimiter, an end of line or an end of file.
(Termination by either end of line or end of file is
considered to be a format error.) A quoted sequence may also
contain escaped characters: all of the usual C/C++ escape
sequences are permitted. (In particular, the only way a word
can contain a new line is by means of a 'n', 'u000A', or
-- not officially portable, but generally true -- a 'x0A'
or a '12'.)

Mais je me démande dans quelle mesure c'est nécessaire. Est-ce
qu'il veut réelement permettre des blancs ou d'autres caractères
spéciaux dans le nom de l'utilisateur ou le mot de passe ?

--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

Bonjour,

Je ne sais pas si je suis sur le bon groupe, mais je n'en trouve pas de
plus adaptés que celui-ci. Je développe une petite application réseau
(un serveur, chaque client se connecte dessus) mais j'ai un doute.

Globalement, ce sont des chaines qui sont envoyées par socket et mises
dans un buffer. Ces chaines contiennent logiquement une commande et tous
les paramètres. J'ai fait un premier jet de mon travail, en séparant les
commandes par Â, les paramètres par Ê, etc. m'étant dit qu'en langue, on
ne met pas d'accent sur des majuscules donc qu'on utiliserait pas ces
caractères, au passage que j'interdis (je les transforme en A, E, etc).
Ca marche bien, les commandes sont donc du genre
"loginÊmyloginÊmypasswordÂ" (le  est à la fin pour vérifier qu'on a
bien dans le buffer la totalité de la commande).

Seulement, je me dis que c'est pas très professionnel, et qu'il devrait
bien exister des solutions (quant à ces  et tout). Les recherches sur
google ne sont capables que de me dire comment sont connectés les
clients...

Je m'adresse à toute personne ayant déjà fait une telle application,
évidemment celles qui ont des idées aussi :p , pour me dire comment
elles ont fait / auraient fait. Merci beaucoup.

Cordialement.
Tu peux utiliser des caracteres spéciaux ou non affichables. Il y en a

d'ailleurs fait expres pour ça.
Par exemple t pour separer les champs et n pour separe les lignes...

Pardon du retard,

Marrant, je n'ai pas l'habitude de mettre des accents sur les majuscules !

Je suis finalement resté sur ma solution, qui au fond peut être
assimilée à un protocole texte avec des caractères affichables, que je
pense changer pour mettre n et t. Ellr est beaucoup plus facile à
mettre en place !

Merci beaucoup de vous être donné la peine de me répondre !

kanze wrote:

Bloutiouf wrote:

Je ne sais pas si je suis sur le bon groupe, mais je n'en
trouve pas de plus adaptés que celui-ci. Je développe une
petite application réseau (un serveur, chaque client se
connecte dessus) mais j'ai un doute.

Globalement, ce sont des chaines qui sont envoyées par socket
et mises dans un buffer. Ces chaines contiennent logiquement
une commande et tous les paramètres. J'ai fait un premier jet
de mon travail, en séparant les commandes par Â, les
paramètres par Ê, etc. m'étant dit qu'en langue, on ne met pas
d'accent sur des majuscules

En quelle langue. En français, il est généralement considéré
préférable de les mettre -- on pourrait même dire que ne pas les
mettre est une faute d'orthographe.

donc qu'on utiliserait pas ces caractères, au passage que
j'interdis (je les transforme en A, E, etc). Ca marche bien,
les commandes sont donc du genre "loginÊmyloginÊmypasswordÂ"
(le  est à la fin pour vérifier qu'on a bien dans le buffer
la totalité de la commande).

Seulement, je me dis que c'est pas très professionnel, et
qu'il devrait bien exister des solutions (quant à ces  et
tout). Les recherches sur google ne sont capables que de me
dire comment sont connectés les clients...

En gros, il faut que tu définisses un protocol. Qui peut être
basé sur texte, ou binaire. Les protocols basés sur texte sont
les plus facile à debogguer -- un tel protocol est, grosso modo,
un petit langage. Si on se base sur Internet ASCII, par exemple,
chaque message commencera par un en-tête, suivi éventuellement
d'un bloc de données. Voir SMTP, par exemple, ou HTTP -- ton
protocol pourrait très bien se modéler sur HTTP, j'imagine --
pour la commande LOGIN, par exemple, on aurait :
LOGIN
user: toto
password: titi
...
le tout qui se termine par une ligne vide.

Les protocols binaires sont nettement plus difficile à mettre au
point. A priori, j'imagine qu'il y aurait une en-tête de block
commune à toutes les commands, avec entre autres informations la
commande même (encodée sur un entier, avec des valeurs
enumérées). Ensuite, les données propre à la commande, avec une
structure propre pour chaque commande.

La façon « classique » d'encoder une chaîne dans un protocol
binaire, c'est d'en envoyer la longueur sur un entier, suivi des
caractères. Suivi éventuellement des caractères de rembourrage
pour assurer l'alignement des données suivantes. (Pour des
raisons historiques, beaucoup de protocols binaires démandent
que tous les champs commencent à un offset multiple de quatre.)
Donc, XDR envoie le nombre de caractères sur quatres octets,
octet de poid fort d'abord, suivi des n caractères, suivi de 0 à
3 octets à 0, de façon à ce que le nombre total d'octets envoyé
soit un multiple de 4. BER enverra un 0x14 pour dire qu'il
s'agit d'une chaîne de caractères à huit bits, suivi de la
longueur de la chaîne sur un octet, si c'est moins de 128, ou
sur 2 à 128 octets, si c'est plus longue, suivi des caractères
même.

Je m'adresse à toute personne ayant déjà fait une telle
application, évidemment celles qui ont des idées aussi :p ,
pour me dire comment elles ont fait / auraient fait. Merci
beaucoup.

Il n'y a pas de règle générale -- tout dépend de ce que fait le
serveur, les données à transférer, etc.

Dans le cas des protocols binaires un peu complexe, il est usual
d'utiliser des générateurs de code pour les données qui
transitent sur le liaison.

--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

Bloutiouf wrote:

Marrant, je n'ai pas l'habitude de mettre des accents sur les
majuscules !

C'est sans doute que tu as pris tes habitudes avec une machine à
écrire. Même aujourd'hui, le clavier français habituel le rend
difficile.

Je suis finalement resté sur ma solution, qui au fond peut
être assimilée à un protocole texte avec des caractères
affichables, que je pense changer pour mettre n et t. Ellr
est beaucoup plus facile à mettre en place !

C-à-d qu'en fin de compte, tu n'es pas loins des conventions des
shells d'Unix.

Une chose quand même : ne fait pas une distinction entre t et
des espaces. Tu le regretteras la première fois que tu régardes
tes données dans un éditeur.

--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34