Je cherche à émettre des données (une chaîne de 30 caractères) en
broadcast UDP. Si je sais me débrouiller pour les socket TCP (et encore
je n'ai pas tenté le broadcast), pour les sockets UDP j'ai du mal à voir
comment configurer la socket afin de pouvoir écrire à partir d'une
machine et lire à partir de plusieurs autres.
Jusque-là, pour mes serveurs, je faisais la recette habituelle :
- pour les serveurs :
socket()
setsockopt() pour REUSEADDR et LINGER
bind()
listen()
- pour les clients :
socket()
setsockopt() (idem)
bind()
connect()
Or pour les sockets UDP en broadcast, je ne vois pas trop comment
faire. Pour l'instant (ce qui ne marche pas) :
socket()
setsockopt() pour REUSEADDR et BROADCAST
connect()
Puis write() ou send() pour écrire et read() ou recv() pour lire.
Quelqu'un a-t-il une idée sur la méthode à appliquer ?
Merci d'avance.
Je cherche à émettre des données (une chaîne de 30 caractères) en broadcast UDP. Si je sais me débrouiller pour les socket TCP (et encore je n'ai pas tenté le broadcast),
Euh... TCP en broadcast ?
pour les sockets UDP j'ai du mal à voir comment configurer la socket afin de pouvoir écrire à partir d'une machine et lire à partir de plusieurs autres.
Pour le client socket() setsocktopt() avec SO_BROADCAST sendto()
Pour le serveur socket() bind() recvfrom()
Or pour les sockets UDP en broadcast, je ne vois pas trop comment faire. Pour l'instant (ce qui ne marche pas) : socket() setsockopt() pour REUSEADDR et BROADCAST connect()
C'est un mode non connecté, donc pas de connect().
Thomas Nemeth <thomas.nemeth@betatech.invalid> écrit:
Je cherche à émettre des données (une chaîne de 30 caractères) en
broadcast UDP. Si je sais me débrouiller pour les socket TCP (et encore
je n'ai pas tenté le broadcast),
Euh... TCP en broadcast ?
pour les sockets UDP j'ai du mal à voir
comment configurer la socket afin de pouvoir écrire à partir d'une
machine et lire à partir de plusieurs autres.
Pour le client
socket()
setsocktopt() avec SO_BROADCAST
sendto()
Pour le serveur
socket()
bind()
recvfrom()
Or pour les sockets UDP en broadcast, je ne vois pas trop comment
faire. Pour l'instant (ce qui ne marche pas) :
socket()
setsockopt() pour REUSEADDR et BROADCAST
connect()
C'est un mode non connecté, donc pas de connect().
Je cherche à émettre des données (une chaîne de 30 caractères) en broadcast UDP. Si je sais me débrouiller pour les socket TCP (et encore je n'ai pas tenté le broadcast),
Euh... TCP en broadcast ?
pour les sockets UDP j'ai du mal à voir comment configurer la socket afin de pouvoir écrire à partir d'une machine et lire à partir de plusieurs autres.
Pour le client socket() setsocktopt() avec SO_BROADCAST sendto()
Pour le serveur socket() bind() recvfrom()
Or pour les sockets UDP en broadcast, je ne vois pas trop comment faire. Pour l'instant (ce qui ne marche pas) : socket() setsockopt() pour REUSEADDR et BROADCAST connect()
C'est un mode non connecté, donc pas de connect().
Thomas Nemeth
Laurent Wacrenier a tapoté :
Thomas Nemeth écrit:
Je cherche à émettre des données (une chaîne de 30 caractères) en broadcast UDP. Si je sais me débrouiller pour les socket TCP (et encore je n'ai pas tenté le broadcast),
Euh... TCP en broadcast ?
Pourquoi pas ? Ça ne se fait pas du broadcast en TCP ?
pour les sockets UDP j'ai du mal à voir comment configurer la socket afin de pouvoir écrire à partir d'une machine et lire à partir de plusieurs autres.
Pour le client socket() setsocktopt() avec SO_BROADCAST sendto()
recvfrom() plutôt alors, non ? Cependant comment fait-on lorsqu'on ne connaît pas l'adresse IP / le nom du serveur ?
Pour le serveur socket() bind() recvfrom()
sendto() alors. Idem ci-dessus.
À moins que tu ne sous-entendes que serveur = écouter et client = émettre.
De toutes façons, dans les 2 cas, les pages de man l'indiquent, il faut connaître les adresses des machines qui communiquent. Or il se peut que les machines en écoute puisse connaître à la rigueur la machine qui émet, mais le contraire n'est pas souhaitable (on peut ainsi modifier le nombre de machine en écoute en rajoutant/enlevant des machines sans avoir à se soucier de la configuration de celle qui émet).
Or pour les sockets UDP en broadcast, je ne vois pas trop comment faire. Pour l'instant (ce qui ne marche pas) : socket() setsockopt() pour REUSEADDR et BROADCAST connect()
C'est un mode non connecté, donc pas de connect().
Ok. Ce qui m'a enduit d'erreur est la page man de connect :
DESCRIPTION Le paramètre sockfd est une socket. Si la socket est du type SOCK_DGRAM, alors serv_adr est l'adresse à laquelle les datagrammes seront envoyés par défaut, et la seule adresse depuis laquelle ils seront reçus.
Merci pour ton aide.
Thomas.
Laurent Wacrenier a tapoté :
Thomas Nemeth <thomas.nemeth@betatech.invalid> écrit:
Je cherche à émettre des données (une chaîne de 30 caractères) en
broadcast UDP. Si je sais me débrouiller pour les socket TCP (et
encore je n'ai pas tenté le broadcast),
Euh... TCP en broadcast ?
Pourquoi pas ? Ça ne se fait pas du broadcast en TCP ?
pour les sockets UDP j'ai du mal à voir
comment configurer la socket afin de pouvoir écrire à partir d'une
machine et lire à partir de plusieurs autres.
Pour le client
socket()
setsocktopt() avec SO_BROADCAST
sendto()
recvfrom() plutôt alors, non ? Cependant comment fait-on lorsqu'on
ne connaît pas l'adresse IP / le nom du serveur ?
Pour le serveur
socket()
bind()
recvfrom()
sendto() alors. Idem ci-dessus.
À moins que tu ne sous-entendes que serveur = écouter et
client = émettre.
De toutes façons, dans les 2 cas, les pages de man l'indiquent, il
faut connaître les adresses des machines qui communiquent. Or il se
peut que les machines en écoute puisse connaître à la rigueur la
machine qui émet, mais le contraire n'est pas souhaitable (on peut
ainsi modifier le nombre de machine en écoute en rajoutant/enlevant
des machines sans avoir à se soucier de la configuration de celle
qui émet).
Or pour les sockets UDP en broadcast, je ne vois pas trop comment
faire. Pour l'instant (ce qui ne marche pas) :
socket()
setsockopt() pour REUSEADDR et BROADCAST
connect()
C'est un mode non connecté, donc pas de connect().
Ok. Ce qui m'a enduit d'erreur est la page man de connect :
DESCRIPTION
Le paramètre sockfd est une socket. Si la socket est du
type SOCK_DGRAM, alors serv_adr est l'adresse à laquelle les
datagrammes seront envoyés par défaut, et la seule adresse
depuis laquelle ils seront reçus.
Je cherche à émettre des données (une chaîne de 30 caractères) en broadcast UDP. Si je sais me débrouiller pour les socket TCP (et encore je n'ai pas tenté le broadcast),
Euh... TCP en broadcast ?
Pourquoi pas ? Ça ne se fait pas du broadcast en TCP ?
pour les sockets UDP j'ai du mal à voir comment configurer la socket afin de pouvoir écrire à partir d'une machine et lire à partir de plusieurs autres.
Pour le client socket() setsocktopt() avec SO_BROADCAST sendto()
recvfrom() plutôt alors, non ? Cependant comment fait-on lorsqu'on ne connaît pas l'adresse IP / le nom du serveur ?
Pour le serveur socket() bind() recvfrom()
sendto() alors. Idem ci-dessus.
À moins que tu ne sous-entendes que serveur = écouter et client = émettre.
De toutes façons, dans les 2 cas, les pages de man l'indiquent, il faut connaître les adresses des machines qui communiquent. Or il se peut que les machines en écoute puisse connaître à la rigueur la machine qui émet, mais le contraire n'est pas souhaitable (on peut ainsi modifier le nombre de machine en écoute en rajoutant/enlevant des machines sans avoir à se soucier de la configuration de celle qui émet).
Or pour les sockets UDP en broadcast, je ne vois pas trop comment faire. Pour l'instant (ce qui ne marche pas) : socket() setsockopt() pour REUSEADDR et BROADCAST connect()
C'est un mode non connecté, donc pas de connect().
Ok. Ce qui m'a enduit d'erreur est la page man de connect :
DESCRIPTION Le paramètre sockfd est une socket. Si la socket est du type SOCK_DGRAM, alors serv_adr est l'adresse à laquelle les datagrammes seront envoyés par défaut, et la seule adresse depuis laquelle ils seront reçus.
Merci pour ton aide.
Thomas.
Eric Masson
Thomas Nemeth writes:
Pourquoi pas ? Ça ne se fait pas du broadcast en TCP ?
Quel sens cela pourrait-il avoir ?
Un broadcast est par définition sans connection, non ?
Éric Masson
--
Tu peux être plus claire ? il veut te sauter patate !
-+-in: GNU - Les patates se sautent, les téléphones sans fils -+-
Thomas Nemeth <thomas.nemeth@betatech.invalid> writes:
Pourquoi pas ? Ça ne se fait pas du broadcast en TCP ?
Quel sens cela pourrait-il avoir ?
Un broadcast est par définition sans connection, non ?
Éric Masson
--
Tu peux être plus claire ?
il veut te sauter patate !
-+-in: GNU - Les patates se sautent, les téléphones sans fils -+-
Pourquoi pas ? Ça ne se fait pas du broadcast en TCP ?
Quel sens cela pourrait-il avoir ?
Un broadcast est par définition sans connection, non ?
Éric Masson
--
Tu peux être plus claire ? il veut te sauter patate !
-+-in: GNU - Les patates se sautent, les téléphones sans fils -+-
DINH Viêt Hoà
Pourquoi pas ? Ça ne se fait pas du broadcast en TCP ?
Quel sens cela pourrait-il avoir ?
Un broadcast est par définition sans connection, non ?
J'imagine très bien la définition d'un protocole du même genre que TCP avec du broadcast. Mais cela n'existe pas aujourd'hui et c'est bien dommage d'ailleurs.
-- DINH V. Hoa,
"Tu as lu combien de bandes dessinées ce mois-ci ? 13 Go"
Pourquoi pas ? Ça ne se fait pas du broadcast en TCP ?
Quel sens cela pourrait-il avoir ?
Un broadcast est par définition sans connection, non ?
J'imagine très bien la définition d'un protocole du même genre que TCP
avec du broadcast. Mais cela n'existe pas aujourd'hui et c'est bien
dommage d'ailleurs.
--
DINH V. Hoa,
"Tu as lu combien de bandes dessinées ce mois-ci ? 13 Go"
Pourquoi pas ? Ça ne se fait pas du broadcast en TCP ?
Quel sens cela pourrait-il avoir ?
Un broadcast est par définition sans connection, non ?
J'imagine très bien la définition d'un protocole du même genre que TCP avec du broadcast. Mais cela n'existe pas aujourd'hui et c'est bien dommage d'ailleurs.
-- DINH V. Hoa,
"Tu as lu combien de bandes dessinées ce mois-ci ? 13 Go"
Thomas Nemeth
Eric Masson a tapoté :
Thomas Nemeth writes:
Pourquoi pas ? Ça ne se fait pas du broadcast en TCP ?
Quel sens cela pourrait-il avoir ?
Un broadcast est par définition sans connection, non ?
Effectivement. Je m'achète un cerveau et je reviens.
Thomas.
Eric Masson a tapoté :
Thomas Nemeth <thomas.nemeth@betatech.invalid> writes:
Pourquoi pas ? Ça ne se fait pas du broadcast en TCP ?
Quel sens cela pourrait-il avoir ?
Un broadcast est par définition sans connection, non ?
Effectivement. Je m'achète un cerveau et je reviens.
Pour le client socket() setsocktopt() avec SO_BROADCAST sendto()
recvfrom() plutôt alors, non ?
En général, le client s'annonce avant de faire quoi que ce soit.
Cependant comment fait-on lorsqu'on ne connaît pas l'adresse IP / le nom du serveur ?
Ben, là on envoie sur une adresse broadcast (ex: 255.255.255.255) Ceci dit, ça serait peut être mieux en multicast.
À moins que tu ne sous-entendes que serveur = écouter et client = émettre.
Le serveur c'est celui qui attend les demandes des clients et y répond.
Là, le client demande en broadcast "Y'a quelqu'un peut me dire si ...?" Un des serveurs prend la demande et répond directement au client.
Tu pensais peut être à un autre modèle que client/serveur ?
Croco
Le 16-06-2005, DINH Viêt Hoà a écrit :
Pourquoi pas ? Ça ne se fait pas du broadcast en TCP ?
Quel sens cela pourrait-il avoir ?
Un broadcast est par définition sans connection, non ?
J'imagine très bien la définition d'un protocole du même genre que TCP avec du broadcast. Mais cela n'existe pas aujourd'hui et c'est bien dommage d'ailleurs.
Du multicast sans que le client ait le choix de s'y connecter ou pas, en sorte... J'ai une petite idée du genre d'attaques que l'on peut faire avec, mais je vois pas trop à quoi cela pourrait vraiment être utile...
Croco
Le 16-06-2005, DINH Viêt Hoà <dinh.viet.hoa@free.fr> a écrit :
Pourquoi pas ? Ça ne se fait pas du broadcast en TCP ?
Quel sens cela pourrait-il avoir ?
Un broadcast est par définition sans connection, non ?
J'imagine très bien la définition d'un protocole du même genre que TCP
avec du broadcast. Mais cela n'existe pas aujourd'hui et c'est bien
dommage d'ailleurs.
Du multicast sans que le client ait le choix de s'y connecter ou pas, en
sorte...
J'ai une petite idée du genre d'attaques que l'on peut faire avec, mais
je vois pas trop à quoi cela pourrait vraiment être utile...
Pourquoi pas ? Ça ne se fait pas du broadcast en TCP ?
Quel sens cela pourrait-il avoir ?
Un broadcast est par définition sans connection, non ?
J'imagine très bien la définition d'un protocole du même genre que TCP avec du broadcast. Mais cela n'existe pas aujourd'hui et c'est bien dommage d'ailleurs.
Du multicast sans que le client ait le choix de s'y connecter ou pas, en sorte... J'ai une petite idée du genre d'attaques que l'on peut faire avec, mais je vois pas trop à quoi cela pourrait vraiment être utile...
Croco
DINH Viêt Hoà
J'imagine très bien la définition d'un protocole du même genre que TCP avec du broadcast. Mais cela n'existe pas aujourd'hui et c'est bien dommage d'ailleurs.
Du multicast sans que le client ait le choix de s'y connecter ou pas, en sorte... J'ai une petite idée du genre d'attaques que l'on peut faire avec, mais je vois pas trop à quoi cela pourrait vraiment être utile...
du dialogue à plusieurs ?
par exemple, les 'chat room' msn ou autre à plusieurs.
-- DINH V. Hoa,
"Tu as lu combien de bandes dessinées ce mois-ci ? 13 Go"
J'imagine très bien la définition d'un protocole du même genre que TCP
avec du broadcast. Mais cela n'existe pas aujourd'hui et c'est bien
dommage d'ailleurs.
Du multicast sans que le client ait le choix de s'y connecter ou pas, en
sorte...
J'ai une petite idée du genre d'attaques que l'on peut faire avec, mais
je vois pas trop à quoi cela pourrait vraiment être utile...
du dialogue à plusieurs ?
par exemple, les 'chat room' msn ou autre à plusieurs.
--
DINH V. Hoa,
"Tu as lu combien de bandes dessinées ce mois-ci ? 13 Go"
J'imagine très bien la définition d'un protocole du même genre que TCP avec du broadcast. Mais cela n'existe pas aujourd'hui et c'est bien dommage d'ailleurs.
Du multicast sans que le client ait le choix de s'y connecter ou pas, en sorte... J'ai une petite idée du genre d'attaques que l'on peut faire avec, mais je vois pas trop à quoi cela pourrait vraiment être utile...
du dialogue à plusieurs ?
par exemple, les 'chat room' msn ou autre à plusieurs.
-- DINH V. Hoa,
"Tu as lu combien de bandes dessinées ce mois-ci ? 13 Go"
Laurent Wacrenier
DINH Viêt Hoà écrit:
J'imagine très bien la définition d'un protocole du même genre que TCP avec du broadcast.
Qu'est ce à dire ? Une connexion unidirectionnelle vers on ne sait où ?
DINH Viêt Hoà <dinh.viet.hoa@free.fr> écrit:
J'imagine très bien la définition d'un protocole du même genre que TCP
avec du broadcast.
Qu'est ce à dire ? Une connexion unidirectionnelle vers on ne sait où ?
J'imagine très bien la définition d'un protocole du même genre que TCP avec du broadcast.
Qu'est ce à dire ? Une connexion unidirectionnelle vers on ne sait où ?
Thomas Nemeth
Laurent Wacrenier a tapoté :
Thomas Nemeth écrit:
Pour le client socket() setsocktopt() avec SO_BROADCAST sendto()
recvfrom() plutôt alors, non ?
En général, le client s'annonce avant de faire quoi que ce soit.
Oui, mais là, pas besoin.
Cependant comment fait-on lorsqu'on ne connaît pas l'adresse IP / le nom du serveur ?
Ben, là on envoie sur une adresse broadcast (ex: 255.255.255.255) Ceci dit, ça serait peut être mieux en multicast.
Oui, c'était une option prévue au départ mais ça a été décommandé.
À moins que tu ne sous-entendes que serveur = écouter et client = émettre.
Le serveur c'est celui qui attend les demandes des clients et y répond.
Là, le client demande en broadcast "Y'a quelqu'un peut me dire si ...?" Un des serveurs prend la demande et répond directement au client.
Tu pensais peut être à un autre modèle que client/serveur ?
Voilà :) En fait, j'ai une machine avec un nunux dedans (embarqué) qui surveille du matos spécifique. Cette machine balance donc régulièrement sur UDP en broadcast des messages (30 cars.) et les autres machines du LAN sont en écoute et agissent en fonction des données reçues.
Dans ce cas ÀMHA, le serveur est celui qui émet en continu, et les clients sont ceux qui écoutent.
Maintenant il faudrait que j'étudie la possibilité de faire en sorte que l'un des clients puisse contacter le serveur afin de le faire changer de mode de fonctionnement. Je pense qu'un select dans un autre thread permettrait de se mettre en attente de lecture...
Thomas.
Laurent Wacrenier a tapoté :
Thomas Nemeth <thomas.nemeth@betatech.invalid> écrit:
Pour le client
socket()
setsocktopt() avec SO_BROADCAST
sendto()
recvfrom() plutôt alors, non ?
En général, le client s'annonce avant de faire quoi que ce soit.
Oui, mais là, pas besoin.
Cependant comment fait-on lorsqu'on
ne connaît pas l'adresse IP / le nom du serveur ?
Ben, là on envoie sur une adresse broadcast (ex: 255.255.255.255)
Ceci dit, ça serait peut être mieux en multicast.
Oui, c'était une option prévue au départ mais ça a été décommandé.
À moins que tu ne sous-entendes que serveur = écouter et
client = émettre.
Le serveur c'est celui qui attend les demandes des clients et y
répond.
Là, le client demande en broadcast "Y'a quelqu'un peut me dire si
...?" Un des serveurs prend la demande et répond directement au
client.
Tu pensais peut être à un autre modèle que client/serveur ?
Voilà :)
En fait, j'ai une machine avec un nunux dedans (embarqué) qui
surveille du matos spécifique. Cette machine balance donc
régulièrement sur UDP en broadcast des messages (30 cars.) et
les autres machines du LAN sont en écoute et agissent en fonction
des données reçues.
Dans ce cas ÀMHA, le serveur est celui qui émet en continu, et les
clients sont ceux qui écoutent.
Maintenant il faudrait que j'étudie la possibilité de faire en sorte
que l'un des clients puisse contacter le serveur afin de le faire
changer de mode de fonctionnement. Je pense qu'un select dans un
autre thread permettrait de se mettre en attente de lecture...
Pour le client socket() setsocktopt() avec SO_BROADCAST sendto()
recvfrom() plutôt alors, non ?
En général, le client s'annonce avant de faire quoi que ce soit.
Oui, mais là, pas besoin.
Cependant comment fait-on lorsqu'on ne connaît pas l'adresse IP / le nom du serveur ?
Ben, là on envoie sur une adresse broadcast (ex: 255.255.255.255) Ceci dit, ça serait peut être mieux en multicast.
Oui, c'était une option prévue au départ mais ça a été décommandé.
À moins que tu ne sous-entendes que serveur = écouter et client = émettre.
Le serveur c'est celui qui attend les demandes des clients et y répond.
Là, le client demande en broadcast "Y'a quelqu'un peut me dire si ...?" Un des serveurs prend la demande et répond directement au client.
Tu pensais peut être à un autre modèle que client/serveur ?
Voilà :) En fait, j'ai une machine avec un nunux dedans (embarqué) qui surveille du matos spécifique. Cette machine balance donc régulièrement sur UDP en broadcast des messages (30 cars.) et les autres machines du LAN sont en écoute et agissent en fonction des données reçues.
Dans ce cas ÀMHA, le serveur est celui qui émet en continu, et les clients sont ceux qui écoutent.
Maintenant il faudrait que j'étudie la possibilité de faire en sorte que l'un des clients puisse contacter le serveur afin de le faire changer de mode de fonctionnement. Je pense qu'un select dans un autre thread permettrait de se mettre en attente de lecture...
