- un programme en C++ qui fait office de socket d'ecoute.
- un programme Java qui se connecte a la socket du programme C++.
Jusqu'ici la connexion fonctionne bien. Une fois la connexion creee, le
programme Java demande au programme C++ de lui transmettre une structure qui
est la suivante:
--------------------------------------------
typedef struct
{
CONFIG_TRACE trace;
CONFIG_COM config_com;
WORD PORT_ECOUTE;
WORD PORT_ECOUTE_ADMIN;
WORD modbus_timeout;
WORD modbus_turnaround;
} CONFIG;
--------------------------------------------
Mais le programme Java ne recoit pas correctement cette structure (a
l'affichage ca me donne "_CONFIG") car la socket Java place le contenu de
son entree (in = socket.getInputStream()) dans une variable de type String
(inString = monProg.in.readLine()) .
Ma question est la suivante : est-ce que je dois creer une structure du cote
Java qui soit identique a la structure du cote C++ pour pouvoir la recuperer
correctement ? Ou est-ce que je peux recuperer cette structure dans un
tableau ?
Par exemple : structureJava = monProg.in.readLine()
tableauJava = monProg.in.readLine()
Je precise que la structure emise par le programme C++ est essentiellement
constituee de variable de type WORD (16 bits - short) et DWORD (32 bits -
int) .
[explication intéressante des conversions signés vers non-signés coupée]
et on utilise les fonctions htons, htonl, ntohs et ntohl pour passer de la convention locale à la machine à la convention Internet et vice-versa.
Fonctions qui ne sont pas présentes sur toutes les implémentations C++.
Bof. S'il s'occupe de transmissions réseaux ...
Je ne sais pas. Est-ce qu'elles sont présentent sous Windows ? Est-ce qu'elles sont même présentes sur tous les Unix -- je ne les trouve pas dans la norme Posix ?
Elles font partie de « The Single UNIX Specification, Version 2 », au moins :
mais je n'ai jamais vraiement compris exactement quelles étaient les différentes normes Unix.
Mais je voualis dire que l'argument comme quoi elles « ne sont pas présentes sur toutes les implémentations C++ » ne tient pas vraiment la route dans ce contexte. Il s'occupe de transimissions réseaux. S'il doit utiliser ces fonctions, je ne vois pas le problème. Mais je ne dit absolument pas qu'il le doit, je te fait confiance sur ce point.
PS: fu2 f.c.l.c++
--drkm, en recherche d'un stage : http://www.fgeorges.org/ipl/stage.html
kanze@gabi-soft.fr writes:
drkm <usenet.fclcxx@fgeorges.org> wrote in message
news:<wk657ir7wv.fsf@fgeorges.org>...
kanze@gabi-soft.fr writes:
[explication intéressante des conversions signés vers non-signés
coupée]
et on utilise les fonctions htons, htonl, ntohs et ntohl pour
passer de la convention locale à la machine à la convention
Internet et vice-versa.
Fonctions qui ne sont pas présentes sur toutes les
implémentations C++.
Bof. S'il s'occupe de transmissions réseaux ...
Je ne sais pas. Est-ce qu'elles sont présentent sous Windows ? Est-ce
qu'elles sont même présentes sur tous les Unix -- je ne les trouve pas
dans la norme Posix ?
Elles font partie de « The Single UNIX Specification, Version 2 »,
au moins :
mais je n'ai jamais vraiement compris exactement quelles étaient les
différentes normes Unix.
Mais je voualis dire que l'argument comme quoi elles « ne sont pas
présentes sur toutes les implémentations C++ » ne tient pas vraiment
la route dans ce contexte. Il s'occupe de transimissions réseaux.
S'il doit utiliser ces fonctions, je ne vois pas le problème. Mais je
ne dit absolument pas qu'il le doit, je te fait confiance sur ce
point.
PS: fu2 f.c.l.c++
--drkm, en recherche d'un stage : http://www.fgeorges.org/ipl/stage.html
[explication intéressante des conversions signés vers non-signés coupée]
et on utilise les fonctions htons, htonl, ntohs et ntohl pour passer de la convention locale à la machine à la convention Internet et vice-versa.
Fonctions qui ne sont pas présentes sur toutes les implémentations C++.
Bof. S'il s'occupe de transmissions réseaux ...
Je ne sais pas. Est-ce qu'elles sont présentent sous Windows ? Est-ce qu'elles sont même présentes sur tous les Unix -- je ne les trouve pas dans la norme Posix ?
Elles font partie de « The Single UNIX Specification, Version 2 », au moins :
mais je n'ai jamais vraiement compris exactement quelles étaient les différentes normes Unix.
Mais je voualis dire que l'argument comme quoi elles « ne sont pas présentes sur toutes les implémentations C++ » ne tient pas vraiment la route dans ce contexte. Il s'occupe de transimissions réseaux. S'il doit utiliser ces fonctions, je ne vois pas le problème. Mais je ne dit absolument pas qu'il le doit, je te fait confiance sur ce point.
PS: fu2 f.c.l.c++
--drkm, en recherche d'un stage : http://www.fgeorges.org/ipl/stage.html
kanze
drkm wrote in message news:...
writes:
drkm wrote in message news:...
writes:
[explication intéressante des conversions signés vers non-signés coupée]
et on utilise les fonctions htons, htonl, ntohs et ntohl pour passer de la convention locale à la machine à la convention Internet et vice-versa.
Fonctions qui ne sont pas présentes sur toutes les implémentations C++.
Bof. S'il s'occupe de transmissions réseaux ...
Je ne sais pas. Est-ce qu'elles sont présentent sous Windows ? Est-ce qu'elles sont même présentes sur tous les Unix -- je ne les trouve pas dans la norme Posix ?
Elles font partie de « The Single UNIX Specification, Version 2 », au moins :
mais je n'ai jamais vraiement compris exactement quelles étaient les différentes normes Unix.
En effet. Je ne sais pas ce que j'ai cherché pour ne pas les trouver.
En ce qui concerne les normes diverses, c'est effectivement un peu compliqué ; « The Single UNIX Specification » est le document normatif pour deux normes, Posix (IEEE) et Unix (Open Group) -- en plus, les deux ont beaucoup de parties optionnelles. Mais pour les fonctions en question, il n'y a pas de « Margin Code Notation », ce qui implique qu'elles font partie du noyau obligatoire des deux normes.
Mais je voualis dire que l'argument comme quoi elles « ne sont pas présentes sur toutes les implémentations C++ » ne tient pas vraiment la route dans ce contexte.
Je le conviens. Bien que... Il arrive de plus en plus de faire du reseau sur des systèmes embarqués. Je ne connais pas trop ce qu'offre l'environement dans de tels systèmes -- je doute fort qu'ils soient Unix, ni même Unix-like.
Il s'occupe de transimissions réseaux. S'il doit utiliser ces fonctions, je ne vois pas le problème. Mais je ne dit absolument pas qu'il le doit, je te fait confiance sur ce point.
Il n'y a pas que moi:-). Dans la section « Application Usage » de la spécification Posix/Unix de ces fonctions : « These functions are most often used in conjunction with IPv4 addresses and ports as returned by gethostent() and getservent(). » J'avoue que même dans ce cas-là, je n'en vois pas l'intérêt : les adresses IP dans le hostent dont se servent gethostent() et getservent() sont stocké en forme de char[]. Il faut donc les convertir en uint32_t (p.e. pour appliquer la masque du reseau, voire simplement pour les copier plus facilement). Or, pour la conversion, la solution que j'ai posté ailleurs marche très bien, sans s'occuper de l'ordre des octets. (En revanche, je comprends bien qu'on pourrait s'intéresser un peu dans l'ordre des octets ici, dans la mésure que selon la représentation, on les traite parfois comme un entier de 32 bits, parfois comme une suite de quatre octets.)
-- James Kanze GABI Software http://www.gabi-soft.fr 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
drkm <usenet.fclcxx@fgeorges.org> wrote in message
news:<wkvffhfk1b.fsf@fgeorges.org>...
kanze@gabi-soft.fr writes:
drkm <usenet.fclcxx@fgeorges.org> wrote in message
news:<wk657ir7wv.fsf@fgeorges.org>...
kanze@gabi-soft.fr writes:
[explication intéressante des conversions signés vers non-signés
coupée]
et on utilise les fonctions htons, htonl, ntohs et ntohl pour
passer de la convention locale à la machine à la convention
Internet et vice-versa.
Fonctions qui ne sont pas présentes sur toutes les
implémentations C++.
Bof. S'il s'occupe de transmissions réseaux ...
Je ne sais pas. Est-ce qu'elles sont présentent sous Windows ?
Est-ce qu'elles sont même présentes sur tous les Unix -- je ne les
trouve pas dans la norme Posix ?
Elles font partie de « The Single UNIX Specification, Version 2 »,
au moins :
mais je n'ai jamais vraiement compris exactement quelles étaient les
différentes normes Unix.
En effet. Je ne sais pas ce que j'ai cherché pour ne pas les trouver.
En ce qui concerne les normes diverses, c'est effectivement un peu
compliqué ; « The Single UNIX Specification » est le document normatif
pour deux normes, Posix (IEEE) et Unix (Open Group) -- en plus, les deux
ont beaucoup de parties optionnelles. Mais pour les fonctions en
question, il n'y a pas de « Margin Code Notation », ce qui implique
qu'elles font partie du noyau obligatoire des deux normes.
Mais je voualis dire que l'argument comme quoi elles « ne sont pas
présentes sur toutes les implémentations C++ » ne tient pas vraiment
la route dans ce contexte.
Je le conviens. Bien que... Il arrive de plus en plus de faire du reseau
sur des systèmes embarqués. Je ne connais pas trop ce qu'offre
l'environement dans de tels systèmes -- je doute fort qu'ils soient
Unix, ni même Unix-like.
Il s'occupe de transimissions réseaux. S'il doit utiliser ces
fonctions, je ne vois pas le problème. Mais je ne dit absolument pas
qu'il le doit, je te fait confiance sur ce point.
Il n'y a pas que moi:-). Dans la section « Application Usage » de la
spécification Posix/Unix de ces fonctions : « These functions are most
often used in conjunction with IPv4 addresses and ports as returned by
gethostent() and getservent(). » J'avoue que même dans ce cas-là, je
n'en vois pas l'intérêt : les adresses IP dans le hostent dont se
servent gethostent() et getservent() sont stocké en forme de char[]. Il
faut donc les convertir en uint32_t (p.e. pour appliquer la masque du
reseau, voire simplement pour les copier plus facilement). Or, pour la
conversion, la solution que j'ai posté ailleurs marche très bien, sans
s'occuper de l'ordre des octets. (En revanche, je comprends bien qu'on
pourrait s'intéresser un peu dans l'ordre des octets ici, dans la mésure
que selon la représentation, on les traite parfois comme un entier de 32
bits, parfois comme une suite de quatre octets.)
--
James Kanze GABI Software http://www.gabi-soft.fr
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
[explication intéressante des conversions signés vers non-signés coupée]
et on utilise les fonctions htons, htonl, ntohs et ntohl pour passer de la convention locale à la machine à la convention Internet et vice-versa.
Fonctions qui ne sont pas présentes sur toutes les implémentations C++.
Bof. S'il s'occupe de transmissions réseaux ...
Je ne sais pas. Est-ce qu'elles sont présentent sous Windows ? Est-ce qu'elles sont même présentes sur tous les Unix -- je ne les trouve pas dans la norme Posix ?
Elles font partie de « The Single UNIX Specification, Version 2 », au moins :
mais je n'ai jamais vraiement compris exactement quelles étaient les différentes normes Unix.
En effet. Je ne sais pas ce que j'ai cherché pour ne pas les trouver.
En ce qui concerne les normes diverses, c'est effectivement un peu compliqué ; « The Single UNIX Specification » est le document normatif pour deux normes, Posix (IEEE) et Unix (Open Group) -- en plus, les deux ont beaucoup de parties optionnelles. Mais pour les fonctions en question, il n'y a pas de « Margin Code Notation », ce qui implique qu'elles font partie du noyau obligatoire des deux normes.
Mais je voualis dire que l'argument comme quoi elles « ne sont pas présentes sur toutes les implémentations C++ » ne tient pas vraiment la route dans ce contexte.
Je le conviens. Bien que... Il arrive de plus en plus de faire du reseau sur des systèmes embarqués. Je ne connais pas trop ce qu'offre l'environement dans de tels systèmes -- je doute fort qu'ils soient Unix, ni même Unix-like.
Il s'occupe de transimissions réseaux. S'il doit utiliser ces fonctions, je ne vois pas le problème. Mais je ne dit absolument pas qu'il le doit, je te fait confiance sur ce point.
Il n'y a pas que moi:-). Dans la section « Application Usage » de la spécification Posix/Unix de ces fonctions : « These functions are most often used in conjunction with IPv4 addresses and ports as returned by gethostent() and getservent(). » J'avoue que même dans ce cas-là, je n'en vois pas l'intérêt : les adresses IP dans le hostent dont se servent gethostent() et getservent() sont stocké en forme de char[]. Il faut donc les convertir en uint32_t (p.e. pour appliquer la masque du reseau, voire simplement pour les copier plus facilement). Or, pour la conversion, la solution que j'ai posté ailleurs marche très bien, sans s'occuper de l'ordre des octets. (En revanche, je comprends bien qu'on pourrait s'intéresser un peu dans l'ordre des octets ici, dans la mésure que selon la représentation, on les traite parfois comme un entier de 32 bits, parfois comme une suite de quatre octets.)
-- James Kanze GABI Software http://www.gabi-soft.fr 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
