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.
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.
Pour cela, le multicast actuel est bien mieux puisqu'il limite la diffusion aux seuls clients intéressés... sans sans venir perturber ceux que cela n'intéressent pas.
Croco
Le 16-06-2005, DINH Viêt Hoà <dinh.viet.hoa@free.fr> a écrit :
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.
Pour cela, le multicast actuel est bien mieux puisqu'il limite la
diffusion aux seuls clients intéressés... sans sans venir perturber ceux
que cela n'intéressent pas.
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.
Pour cela, le multicast actuel est bien mieux puisqu'il limite la diffusion aux seuls clients intéressés... sans sans venir perturber ceux que cela n'intéressent pas.
Croco
DINH Viêt Hoà
par exemple, les 'chat room' msn ou autre à plusieurs.
Pour cela, le multicast actuel est bien mieux puisqu'il limite la diffusion aux seuls clients intéressés... sans sans venir perturber ceux que cela n'intéressent pas.
le multicast actuel ne gère pas la fiabilité ni le contrôle de flux.
-- DINH V. Hoa,
"Tu as lu combien de bandes dessinées ce mois-ci ? 13 Go"
par exemple, les 'chat room' msn ou autre à plusieurs.
Pour cela, le multicast actuel est bien mieux puisqu'il limite la
diffusion aux seuls clients intéressés... sans sans venir perturber ceux
que cela n'intéressent pas.
le multicast actuel ne gère pas la fiabilité ni le contrôle de flux.
--
DINH V. Hoa,
"Tu as lu combien de bandes dessinées ce mois-ci ? 13 Go"
par exemple, les 'chat room' msn ou autre à plusieurs.
Pour cela, le multicast actuel est bien mieux puisqu'il limite la diffusion aux seuls clients intéressés... sans sans venir perturber ceux que cela n'intéressent pas.
le multicast actuel ne gère pas la fiabilité ni le contrôle de flux.
-- DINH V. Hoa,
"Tu as lu combien de bandes dessinées ce mois-ci ? 13 Go"
Bob qui Trolle
Thomas Nemeth wrote:
Laurent Wacrenier a tapoté :
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...
Ce que tu décris ressemble beaucoup à SNMP
Thomas Nemeth wrote:
Laurent Wacrenier a tapoté :
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...
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...
Ce que tu décris ressemble beaucoup à SNMP
Thomas Nemeth
Bob qui Trolle a tapoté :
Thomsuffisammenttrote:
Laurent Wacrenier a tapoté :
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.
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...
Ce que tu décris ressemble beaucoup à SNMP
Peut-être. Je ne connais pas suffisamment SNMP. Cependant ce que je dois faire est un truc spécifique.
Thomas.
Bob qui Trolle a tapoté :
Thomsuffisammenttrote:
Laurent Wacrenier a tapoté :
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.
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...
Ce que tu décris ressemble beaucoup à SNMP
Peut-être. Je ne connais pas suffisamment SNMP. Cependant ce que je
dois faire est un truc spécifique.
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.
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...
Ce que tu décris ressemble beaucoup à SNMP
Peut-être. Je ne connais pas suffisamment SNMP. Cependant ce que je dois faire est un truc spécifique.
Thomas.
Marc Boyer
DINH Viêt Hoà a écrit :
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.
Des protocoles multicast fiables à connexion, il y en a plein. Des broadcast, je ne connais pas, et je ne vois même pas trop ce que ça voudrait dire.
Marc Boyer -- À vélo, prendre une rue à contre-sens est moins dangeureux que prendre un boulevard dans le sens légal. À qui la faute ?
DINH Viêt Hoà <dinh.viet.hoa@free.fr> a écrit :
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.
Des protocoles multicast fiables à connexion, il
y en a plein.
Des broadcast, je ne connais pas, et je ne vois
même pas trop ce que ça voudrait dire.
Marc Boyer
--
À vélo, prendre une rue à contre-sens est moins dangeureux
que prendre un boulevard dans le sens légal. À qui la faute ?
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.
Des protocoles multicast fiables à connexion, il y en a plein. Des broadcast, je ne connais pas, et je ne vois même pas trop ce que ça voudrait dire.
Marc Boyer -- À vélo, prendre une rue à contre-sens est moins dangeureux que prendre un boulevard dans le sens légal. À qui la faute ?
DINH Viêt Hoà
par exemple, les 'chat room' msn ou autre à plusieurs.
Des protocoles multicast fiables à connexion, il y en a plein.
je pense qu'il s'agit souvent de bibliothèques et qu'aucun standard n'a été défini pour ça ?
Des broadcast, je ne connais pas, et je ne vois même pas trop ce que ça voudrait dire.
broadcast = multicast sans filtrage ?
-- DINH V. Hoa,
"Je suis une merde" -- jyb
par exemple, les 'chat room' msn ou autre à plusieurs.
Des protocoles multicast fiables à connexion, il
y en a plein.
je pense qu'il s'agit souvent de bibliothèques et qu'aucun standard n'a
été défini pour ça ?
Des broadcast, je ne connais pas, et je ne vois
même pas trop ce que ça voudrait dire.
par exemple, les 'chat room' msn ou autre à plusieurs.
Des protocoles multicast fiables à connexion, il y en a plein.
je pense qu'il s'agit souvent de bibliothèques et qu'aucun standard n'a été défini pour ça ?
Des broadcast, je ne connais pas, et je ne vois même pas trop ce que ça voudrait dire.
broadcast = multicast sans filtrage ?
-- DINH V. Hoa,
"Je suis une merde" -- jyb
Thomas Nemeth
Laurent Wacrenier a tapoté :
Thomas Nemeth écrit:
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()
Après avoir fouillé les différentes pages man j'ai des difficultés à saisir la façon de se servir de bind() et connect(). Pour socket(), accept(), (set|get)sockopt(), send[to](), recv[from](), je vois bien mais l'utilité de bind() et connect() ne me semble pas claire (bien qu'indispensable) et je les utilise donc de façon robotique sans trop comprendre les mécanismes sous-jacents.
Thomas.
Laurent Wacrenier a tapoté :
Thomas Nemeth <thomas.nemeth@betatech.invalid> écrit:
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()
Après avoir fouillé les différentes pages man j'ai des difficultés à
saisir la façon de se servir de bind() et connect(). Pour socket(),
accept(), (set|get)sockopt(), send[to](), recv[from](), je vois bien
mais l'utilité de bind() et connect() ne me semble pas claire (bien
qu'indispensable) et je les utilise donc de façon robotique sans
trop comprendre les mécanismes sous-jacents.
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()
Après avoir fouillé les différentes pages man j'ai des difficultés à saisir la façon de se servir de bind() et connect(). Pour socket(), accept(), (set|get)sockopt(), send[to](), recv[from](), je vois bien mais l'utilité de bind() et connect() ne me semble pas claire (bien qu'indispensable) et je les utilise donc de façon robotique sans trop comprendre les mécanismes sous-jacents.
Thomas.
DINH Viêt Hoà
Après avoir fouillé les différentes pages man j'ai des difficultés à saisir la façon de se servir de bind() et connect(). Pour socket(), accept(), (set|get)sockopt(), send[to](), recv[from](), je vois bien mais l'utilité de bind() et connect() ne me semble pas claire (bien qu'indispensable) et je les utilise donc de façon robotique sans trop comprendre les mécanismes sous-jacents.
socket: tu crées un descripteur de fichier pour ton flux réseau
bind : tu associes les ports/addresses source et destination. pour le port source, 0 permet d'obtenir un numéro de port libre.
connect: établir la connexion
send: envoyer une donnée recv: recevoir une donnée
shutdown: fermer la connexion réseau (et permet de faire des close() non-bloquant)
close: fermer le descripteur de fichier
-- DINH V. Hoa,
"Je suis une merde" -- jyb
Après avoir fouillé les différentes pages man j'ai des difficultés à
saisir la façon de se servir de bind() et connect(). Pour socket(),
accept(), (set|get)sockopt(), send[to](), recv[from](), je vois bien
mais l'utilité de bind() et connect() ne me semble pas claire (bien
qu'indispensable) et je les utilise donc de façon robotique sans
trop comprendre les mécanismes sous-jacents.
socket: tu crées un descripteur de fichier pour ton flux réseau
bind : tu associes les ports/addresses source et destination.
pour le port source, 0 permet d'obtenir un numéro de port libre.
connect: établir la connexion
send: envoyer une donnée
recv: recevoir une donnée
shutdown: fermer la connexion réseau (et permet de faire des close()
non-bloquant)
Après avoir fouillé les différentes pages man j'ai des difficultés à saisir la façon de se servir de bind() et connect(). Pour socket(), accept(), (set|get)sockopt(), send[to](), recv[from](), je vois bien mais l'utilité de bind() et connect() ne me semble pas claire (bien qu'indispensable) et je les utilise donc de façon robotique sans trop comprendre les mécanismes sous-jacents.
socket: tu crées un descripteur de fichier pour ton flux réseau
bind : tu associes les ports/addresses source et destination. pour le port source, 0 permet d'obtenir un numéro de port libre.
connect: établir la connexion
send: envoyer une donnée recv: recevoir une donnée
shutdown: fermer la connexion réseau (et permet de faire des close() non-bloquant)
close: fermer le descripteur de fichier
-- DINH V. Hoa,
"Je suis une merde" -- jyb
Marc Boyer
DINH Viêt Hoà a écrit :
par exemple, les 'chat room' msn ou autre à plusieurs.
Des protocoles multicast fiables à connexion, il y en a plein.
je pense qu'il s'agit souvent de bibliothèques et qu'aucun standard n'a été défini pour ça ?
C'est quoi un standard ? Disons qu'actuellement, plein de monde travaille sur le multicast, et donc sur le multicast fiable. Il y a pas mal de RFC. En cherchant un peu, je viens de voir que PGM (RFC 3208) est implémenté par Window serveur 2003. Est-ce que cela en fait un standard ? Les protocoles de RealNetworks ne sont pas des standards à ma connaissance, et ils existent quand même. Idem pour les protocoles de P2P.
Des broadcast, je ne connais pas, et je ne vois même pas trop ce que ça voudrait dire.
broadcast = multicast sans filtrage ?
broadcast: envois à tous multicast: envois à un groupe
Marc Boyer -- À vélo, prendre une rue à contre-sens est moins dangeureux que prendre un boulevard dans le sens légal. À qui la faute ?
DINH Viêt Hoà <dinh.viet.hoa@free.fr> a écrit :
par exemple, les 'chat room' msn ou autre à plusieurs.
Des protocoles multicast fiables à connexion, il
y en a plein.
je pense qu'il s'agit souvent de bibliothèques et qu'aucun standard n'a
été défini pour ça ?
C'est quoi un standard ?
Disons qu'actuellement, plein de monde travaille sur le multicast,
et donc sur le multicast fiable. Il y a pas mal de RFC. En cherchant
un peu, je viens de voir que PGM (RFC 3208) est implémenté par
Window serveur 2003. Est-ce que cela en fait un standard ?
Les protocoles de RealNetworks ne sont pas des standards à ma
connaissance, et ils existent quand même. Idem pour les
protocoles de P2P.
Des broadcast, je ne connais pas, et je ne vois
même pas trop ce que ça voudrait dire.
broadcast = multicast sans filtrage ?
broadcast: envois à tous
multicast: envois à un groupe
Marc Boyer
--
À vélo, prendre une rue à contre-sens est moins dangeureux
que prendre un boulevard dans le sens légal. À qui la faute ?
par exemple, les 'chat room' msn ou autre à plusieurs.
Des protocoles multicast fiables à connexion, il y en a plein.
je pense qu'il s'agit souvent de bibliothèques et qu'aucun standard n'a été défini pour ça ?
C'est quoi un standard ? Disons qu'actuellement, plein de monde travaille sur le multicast, et donc sur le multicast fiable. Il y a pas mal de RFC. En cherchant un peu, je viens de voir que PGM (RFC 3208) est implémenté par Window serveur 2003. Est-ce que cela en fait un standard ? Les protocoles de RealNetworks ne sont pas des standards à ma connaissance, et ils existent quand même. Idem pour les protocoles de P2P.
Des broadcast, je ne connais pas, et je ne vois même pas trop ce que ça voudrait dire.
broadcast = multicast sans filtrage ?
broadcast: envois à tous multicast: envois à un groupe
Marc Boyer -- À vélo, prendre une rue à contre-sens est moins dangeureux que prendre un boulevard dans le sens légal. À qui la faute ?
DINH Viêt Hoà
par exemple, les 'chat room' msn ou autre à plusieurs.
Des protocoles multicast fiables à connexion, il y en a plein.
je pense qu'il s'agit souvent de bibliothèques et qu'aucun standard n'a été défini pour ça ?
C'est quoi un standard ? Disons qu'actuellement, plein de monde travaille sur le multicast, et donc sur le multicast fiable. Il y a pas mal de RFC. En cherchant un peu, je viens de voir que PGM (RFC 3208) est implémenté par Window serveur 2003. Est-ce que cela en fait un standard ? Les protocoles de RealNetworks ne sont pas des standards à ma connaissance, et ils existent quand même. Idem pour les protocoles de P2P.
RFC 3208 me va bien comme réponse à ma question.
Des broadcast, je ne connais pas, et je ne vois même pas trop ce que ça voudrait dire.
broadcast = multicast sans filtrage ?
broadcast: envois à tous multicast: envois à un groupe
De ce que je connais, le broadcast a l'air d'être souvent employé à la place du multicast pour des émissions vers un groupe. Je connais en fait peu d'utilisation de broadcast licite.
-- DINH V. Hoa,
"Je suis une merde" -- jyb
par exemple, les 'chat room' msn ou autre à plusieurs.
Des protocoles multicast fiables à connexion, il
y en a plein.
je pense qu'il s'agit souvent de bibliothèques et qu'aucun standard n'a
été défini pour ça ?
C'est quoi un standard ?
Disons qu'actuellement, plein de monde travaille sur le multicast,
et donc sur le multicast fiable. Il y a pas mal de RFC. En cherchant
un peu, je viens de voir que PGM (RFC 3208) est implémenté par
Window serveur 2003. Est-ce que cela en fait un standard ?
Les protocoles de RealNetworks ne sont pas des standards à ma
connaissance, et ils existent quand même. Idem pour les
protocoles de P2P.
RFC 3208 me va bien comme réponse à ma question.
Des broadcast, je ne connais pas, et je ne vois
même pas trop ce que ça voudrait dire.
broadcast = multicast sans filtrage ?
broadcast: envois à tous
multicast: envois à un groupe
De ce que je connais, le broadcast a l'air d'être souvent employé à la
place du multicast pour des émissions vers un groupe. Je connais en fait
peu d'utilisation de broadcast licite.
par exemple, les 'chat room' msn ou autre à plusieurs.
Des protocoles multicast fiables à connexion, il y en a plein.
je pense qu'il s'agit souvent de bibliothèques et qu'aucun standard n'a été défini pour ça ?
C'est quoi un standard ? Disons qu'actuellement, plein de monde travaille sur le multicast, et donc sur le multicast fiable. Il y a pas mal de RFC. En cherchant un peu, je viens de voir que PGM (RFC 3208) est implémenté par Window serveur 2003. Est-ce que cela en fait un standard ? Les protocoles de RealNetworks ne sont pas des standards à ma connaissance, et ils existent quand même. Idem pour les protocoles de P2P.
RFC 3208 me va bien comme réponse à ma question.
Des broadcast, je ne connais pas, et je ne vois même pas trop ce que ça voudrait dire.
broadcast = multicast sans filtrage ?
broadcast: envois à tous multicast: envois à un groupe
De ce que je connais, le broadcast a l'air d'être souvent employé à la place du multicast pour des émissions vers un groupe. Je connais en fait peu d'utilisation de broadcast licite.
