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'en étais à penser qu'il fallait que j'utilise bind sur l'émetteur... Visiblement ce n'est donc pas le cas.
On peut éventuelement mettre bind sur l'emeteur. Celà determinera l'adresse et le port source.
Nicolas George
Thomas Nemeth wrote in message <d8ukmp$kcc$:
J'en étais à penser qu'il fallait que j'utilise bind sur l'émetteur... Visiblement ce n'est donc pas le cas.
Ça dépend. bind sur une socket émettrice peut avoir du sens :
- si la machine a plusieurs adresses IP, et qu'on veut choisir celle qui apparaît comme source ;
- si on souhaite choisir un port particulier pour la source, comme un port provilégié.
Dans le cas qui nous intéresse ici, ça peut être une bonne chose, justement, de choisir un port particulier, et de vérifier dans les récepteurs que c'est bien le bon port, pour éviter qu'un autre processus puisse falsifier les informations envoyées. Ce n'est pas absolument fiable, comme sécurité, mais ça évite les attaques les plus élémentaires.
Thomas Nemeth wrote in message <d8ukmp$kcc$1@s1.news.oleane.net>:
J'en étais à penser qu'il fallait que j'utilise bind sur
l'émetteur... Visiblement ce n'est donc pas le cas.
Ça dépend. bind sur une socket émettrice peut avoir du sens :
- si la machine a plusieurs adresses IP, et qu'on veut choisir celle qui
apparaît comme source ;
- si on souhaite choisir un port particulier pour la source, comme un port
provilégié.
Dans le cas qui nous intéresse ici, ça peut être une bonne chose, justement,
de choisir un port particulier, et de vérifier dans les récepteurs que c'est
bien le bon port, pour éviter qu'un autre processus puisse falsifier les
informations envoyées. Ce n'est pas absolument fiable, comme sécurité, mais
ça évite les attaques les plus élémentaires.
J'en étais à penser qu'il fallait que j'utilise bind sur l'émetteur... Visiblement ce n'est donc pas le cas.
Ça dépend. bind sur une socket émettrice peut avoir du sens :
- si la machine a plusieurs adresses IP, et qu'on veut choisir celle qui apparaît comme source ;
- si on souhaite choisir un port particulier pour la source, comme un port provilégié.
Dans le cas qui nous intéresse ici, ça peut être une bonne chose, justement, de choisir un port particulier, et de vérifier dans les récepteurs que c'est bien le bon port, pour éviter qu'un autre processus puisse falsifier les informations envoyées. Ce n'est pas absolument fiable, comme sécurité, mais ça évite les attaques les plus élémentaires.
Nicolas George
DINH Viêt Hoà wrote in message :
que se passe-t-il d'ailleurs si tu ne bindes pas le socket ?
Le noyau fait un bind implicite avant le premier usage de la socket.
DINH Viêt Hoà wrote in message <etPan.42b2d423.1befc7b0.1362@utopia>:
que se passe-t-il d'ailleurs si tu ne bindes pas le socket ?
Le noyau fait un bind implicite avant le premier usage de la socket.
que se passe-t-il d'ailleurs si tu ne bindes pas le socket ?
Le noyau fait un bind implicite avant le premier usage de la socket.
Thomas Nemeth
Laurent Wacrenier a tapoté :
Thomas Nemeth écrit:
J'en étais à penser qu'il fallait que j'utilise bind sur l'émetteur... Visiblement ce n'est donc pas le cas.
On peut éventuelement mettre bind sur l'emeteur. Celà determinera l'adresse et le port source.
Dans ce cas, comment dois-je configurer mes bind() en tant qu'émetteur et en tant que récepteur ? Sur l'émetteur, l'adresse et le port local sont-ils les adresse et port de broadcast ? Idem sur le récepteur ?
Visiblement je ne reçois pas (ou n'émet pas) les paquets de données, devrais-je utiliser connect() sur le récepteur au lieu de simplement bind() ?
Thomas.
Laurent Wacrenier a tapoté :
Thomas Nemeth <thomas.nemeth@betatech.invalid> écrit:
J'en étais à penser qu'il fallait que j'utilise bind sur
l'émetteur... Visiblement ce n'est donc pas le cas.
On peut éventuelement mettre bind sur l'emeteur.
Celà determinera l'adresse et le port source.
Dans ce cas, comment dois-je configurer mes bind() en tant
qu'émetteur et en tant que récepteur ?
Sur l'émetteur, l'adresse et le port local sont-ils les adresse et
port de broadcast ?
Idem sur le récepteur ?
Visiblement je ne reçois pas (ou n'émet pas) les paquets de données,
devrais-je utiliser connect() sur le récepteur au lieu de simplement
bind() ?
J'en étais à penser qu'il fallait que j'utilise bind sur l'émetteur... Visiblement ce n'est donc pas le cas.
On peut éventuelement mettre bind sur l'emeteur. Celà determinera l'adresse et le port source.
Dans ce cas, comment dois-je configurer mes bind() en tant qu'émetteur et en tant que récepteur ? Sur l'émetteur, l'adresse et le port local sont-ils les adresse et port de broadcast ? Idem sur le récepteur ?
Visiblement je ne reçois pas (ou n'émet pas) les paquets de données, devrais-je utiliser connect() sur le récepteur au lieu de simplement bind() ?
Thomas.
Thomas Nemeth
Nicolas George a tapoté :
Thomas Nemeth wrote in message <d8ukmp$kcc$:
J'en étais à penser qu'il fallait que j'utilise bind sur l'émetteur... Visiblement ce n'est donc pas le cas.
Ça dépend. bind sur une socket émettrice peut avoir du sens :
Sur tcp c'est ce que je faisais jusque là...
- si la machine a plusieurs adresses IP, et qu'on veut choisir celle qui apparaît comme source ;
Effectivement.
- si on souhaite choisir un port particulier pour la source, comme un port provilégié.
Ce n'est pas un port privilégié mais c'est un port particulier...
Dans le cas qui nous intéresse ici, ça peut être une bonne chose, justement, de choisir un port particulier, et de vérifier dans les récepteurs que c'est bien le bon port, pour éviter qu'un autre processus puisse falsifier les informations envoyées. Ce n'est pas absolument fiable, comme sécurité, mais ça évite les attaques les plus élémentaires.
Oui. Ceci dit c'est fait pour tourner sur un LAN non connecté et non accessible par les non-autorisés :) Donc niveau sécurité, c'est pas un souci...
M'enfin bon, cela voudrait-il dire que pour balancer en permanence des données sur le port X en broadcast (192.168.0.255), il faille que je bind() la socket sur une adresse locale autre que celle du broadcast ? Genre :
memset(&sa, 0, sizeof(struct sockaddr_in)); /* clear our address */ gethostname(myname, MAXHOSTNAME); /* who are we? */ hp= gethostbyname(myname); /* get our address info */ if (hp == NULL) /* we don't exist !? */ return(-1); sa.sin_family= hp->h_addrtype; /* this is our host address */ sa.sin_port= htons(portnum); /* this is our port number */
Thomas.
Nicolas George a tapoté :
Thomas Nemeth wrote in message <d8ukmp$kcc$1@s1.news.oleane.net>:
J'en étais à penser qu'il fallait que j'utilise bind sur
l'émetteur... Visiblement ce n'est donc pas le cas.
Ça dépend. bind sur une socket émettrice peut avoir du sens :
Sur tcp c'est ce que je faisais jusque là...
- si la machine a plusieurs adresses IP, et qu'on veut choisir celle qui
apparaît comme source ;
Effectivement.
- si on souhaite choisir un port particulier pour la source, comme un port
provilégié.
Ce n'est pas un port privilégié mais c'est un port particulier...
Dans le cas qui nous intéresse ici, ça peut être une bonne chose,
justement, de choisir un port particulier, et de vérifier dans les
récepteurs que c'est bien le bon port, pour éviter qu'un autre processus
puisse falsifier les informations envoyées. Ce n'est pas absolument
fiable, comme sécurité, mais ça évite les attaques les plus élémentaires.
Oui. Ceci dit c'est fait pour tourner sur un LAN non connecté et non
accessible par les non-autorisés :) Donc niveau sécurité, c'est pas
un souci...
M'enfin bon, cela voudrait-il dire que pour balancer en permanence des
données sur le port X en broadcast (192.168.0.255), il faille que je
bind() la socket sur une adresse locale autre que celle du broadcast ?
Genre :
memset(&sa, 0, sizeof(struct sockaddr_in)); /* clear our address */
gethostname(myname, MAXHOSTNAME); /* who are we? */
hp= gethostbyname(myname); /* get our address info */
if (hp == NULL) /* we don't exist !? */
return(-1);
sa.sin_family= hp->h_addrtype; /* this is our host address */
sa.sin_port= htons(portnum); /* this is our port number */
J'en étais à penser qu'il fallait que j'utilise bind sur l'émetteur... Visiblement ce n'est donc pas le cas.
Ça dépend. bind sur une socket émettrice peut avoir du sens :
Sur tcp c'est ce que je faisais jusque là...
- si la machine a plusieurs adresses IP, et qu'on veut choisir celle qui apparaît comme source ;
Effectivement.
- si on souhaite choisir un port particulier pour la source, comme un port provilégié.
Ce n'est pas un port privilégié mais c'est un port particulier...
Dans le cas qui nous intéresse ici, ça peut être une bonne chose, justement, de choisir un port particulier, et de vérifier dans les récepteurs que c'est bien le bon port, pour éviter qu'un autre processus puisse falsifier les informations envoyées. Ce n'est pas absolument fiable, comme sécurité, mais ça évite les attaques les plus élémentaires.
Oui. Ceci dit c'est fait pour tourner sur un LAN non connecté et non accessible par les non-autorisés :) Donc niveau sécurité, c'est pas un souci...
M'enfin bon, cela voudrait-il dire que pour balancer en permanence des données sur le port X en broadcast (192.168.0.255), il faille que je bind() la socket sur une adresse locale autre que celle du broadcast ? Genre :
memset(&sa, 0, sizeof(struct sockaddr_in)); /* clear our address */ gethostname(myname, MAXHOSTNAME); /* who are we? */ hp= gethostbyname(myname); /* get our address info */ if (hp == NULL) /* we don't exist !? */ return(-1); sa.sin_family= hp->h_addrtype; /* this is our host address */ sa.sin_port= htons(portnum); /* this is our port number */
Thomas.
Laurent Wacrenier
Thomas Nemeth écrit:
Visiblement je ne reçois pas (ou n'émet pas) les paquets de données, devrais-je utiliser connect() sur le récepteur au lieu de simplement bind() ?
Utilise tcpdump pour voir ce qui circule sur le réseau et analyse les code de retour des fonctions (if (sendto() == -1) { perror("sendto");}, etc.)
Thomas Nemeth <thomas.nemeth@betatech.invalid> écrit:
Visiblement je ne reçois pas (ou n'émet pas) les paquets de données,
devrais-je utiliser connect() sur le récepteur au lieu de simplement
bind() ?
Utilise tcpdump pour voir ce qui circule sur le réseau et analyse les
code de retour des fonctions (if (sendto() == -1) { perror("sendto");},
etc.)
Oui. Ceci dit c'est fait pour tourner sur un LAN non connecté et non accessible par les non-autorisés :) Donc niveau sécurité, c'est pas un souci...
La sécurité n'est pas uniquement contre les mailveillances, mais aussi contre les machines folles.
M'enfin bon, cela voudrait-il dire que pour balancer en permanence des données sur le port X en broadcast (192.168.0.255), il faille que je
Utiliser 255.255.255.255 comme adresse broadcast x.sin_addr.s_addr = htonl(INADDR_BROADCAST);
bind() la socket sur une adresse locale autre que celle du broadcast ? Genre :
memset(&sa, 0, sizeof(struct sockaddr_in)); /* clear our address */ gethostname(myname, MAXHOSTNAME); /* who are we? */ hp= gethostbyname(myname); /* get our address info */ if (hp == NULL) /* we don't exist !? */ return(-1);
Pourquoi interroger le DNS ?
Nicolas George
Thomas Nemeth wrote in message <d8um07$kcc$:
Oui. Ceci dit c'est fait pour tourner sur un LAN non connecté et non accessible par les non-autorisés :) Donc niveau sécurité, c'est pas un souci...
Ne jamais négliger les petites améliorations de sécurité sous ce prétexte.
M'enfin bon, cela voudrait-il dire que pour balancer en permanence des données sur le port X en broadcast (192.168.0.255), il faille que je bind() la socket sur une adresse locale autre que celle du broadcast ?
Bon, apparemment, tu as des lacunes en réseau, on va reprendre doucement.
D'abord, en Unicast connecté, le plus simple : une socket A communique avec une socket B. Les paquets envoyés par A sont marqués avec IPa comme adresse source, Pa comme port source, IPb comme adresse destination, Pb comme port destination. Le choix d'IPa et de Pa a été fait soit par un bind explicite, soit par le noyau au premier usage de la socket A (au moment du connect par exemple) ; le choix d'IPb et de Pb a été fait soit par un bind explicite, soit par le noyau au premier usage de la socket B. En mode connecté, au moins l'une des deux socket, A ou B, a dû faire un bind explicite ; mais il faut bien comprendre qu'une fois la connexion établie, les rôles de A et B sont parfaitement symétriques.
Ensuite, l'unicast non connecté. S'il y a bien deux sockets qui se voient, c'est exactement la même disposition. Les différences sont :
- C'est un « hasard », si les ports et les adresses se correspondent, rien dans les protocoles réseau obligent les sockets à bien se situer en face l'une de l'autre, et A pourrait envoyer des paquets complètement dans le vide. C'est à un autre niveau, soit au niveau de la configuration du serveur, soit d'un protocole de plus haut niveau, qu'on s'assure que les paquets arrivent bien à quelqu'un.
- L'adresse source, IPa ou IPb, quand elle n'est pas choisie par un bind explicite, est choisie à chaque envoi de paquet, pour correspondre à la route directe.
Enfin, en broadcast (non connecté, forcément) : ici, on a une seule socket A, mais plusieurs socket B1, B2, etc.. Les paquets envoyés par A ont toujours pour source IPa et Pa, ça ne change pas. Ils ont également toujours pour destination le port Pb, qui doit être le même pour toutes les sockets B (et donc, forcément, choisi explicitement par bind). Mais l'adresse destination est une adresse de broadcast, qui regroupe tous les IPb1, IPb2, etc.
Si B42 souhaite répondre, il va normalement répondre à (IPa, Pa), avec comme source (IPb, Pb), c'est du pur unicast.
Une alternative serait d'avoir Pa=Pb, que A soit l'un des Bx, et qu'on ait un groupe de sockets qui discutent ensemble en broadcast.
En pratique, ça donne ça. Côté A :
- création de la socket ; - bind sur un port bien connu pour un rudiment d'authentification ; - autorisation du broadcast ; - sendto vers l'adresse de broadcast et le port où les gens sont censés écouter.
Côté B :
- création de la socket ; - bind sur le port où les gens sont censés écouter ; - recvfrom ; - vérification que l'adresse source est bien celle du serveur autorisé, et que le port source est le port bien connu du serveur.
Si tout ceci ne suffit pas, je pense que quelques heures de lecture d'_Unix Network Programming_ s'imposent.
gethostname(myname, MAXHOSTNAME); /* who are we? */ hp= gethostbyname(myname); /* get our address info */ if (hp == NULL) /* we don't exist !? */ return(-1); sa.sin_family= hp->h_addrtype; /* this is our host address */
Beurk. gethostbyname est essentiellement obsolète.
Thomas Nemeth wrote in message <d8um07$kcc$3@s1.news.oleane.net>:
Oui. Ceci dit c'est fait pour tourner sur un LAN non connecté et non
accessible par les non-autorisés :) Donc niveau sécurité, c'est pas
un souci...
Ne jamais négliger les petites améliorations de sécurité sous ce prétexte.
M'enfin bon, cela voudrait-il dire que pour balancer en permanence des
données sur le port X en broadcast (192.168.0.255), il faille que je
bind() la socket sur une adresse locale autre que celle du broadcast ?
Bon, apparemment, tu as des lacunes en réseau, on va reprendre doucement.
D'abord, en Unicast connecté, le plus simple : une socket A communique avec
une socket B. Les paquets envoyés par A sont marqués avec IPa comme adresse
source, Pa comme port source, IPb comme adresse destination, Pb comme port
destination. Le choix d'IPa et de Pa a été fait soit par un bind explicite,
soit par le noyau au premier usage de la socket A (au moment du connect par
exemple) ; le choix d'IPb et de Pb a été fait soit par un bind explicite,
soit par le noyau au premier usage de la socket B. En mode connecté, au
moins l'une des deux socket, A ou B, a dû faire un bind explicite ; mais il
faut bien comprendre qu'une fois la connexion établie, les rôles de A et B
sont parfaitement symétriques.
Ensuite, l'unicast non connecté. S'il y a bien deux sockets qui se voient,
c'est exactement la même disposition. Les différences sont :
- C'est un « hasard », si les ports et les adresses se correspondent, rien
dans les protocoles réseau obligent les sockets à bien se situer en face
l'une de l'autre, et A pourrait envoyer des paquets complètement dans le
vide. C'est à un autre niveau, soit au niveau de la configuration du
serveur, soit d'un protocole de plus haut niveau, qu'on s'assure que les
paquets arrivent bien à quelqu'un.
- L'adresse source, IPa ou IPb, quand elle n'est pas choisie par un bind
explicite, est choisie à chaque envoi de paquet, pour correspondre à la
route directe.
Enfin, en broadcast (non connecté, forcément) : ici, on a une seule socket
A, mais plusieurs socket B1, B2, etc.. Les paquets envoyés par A ont
toujours pour source IPa et Pa, ça ne change pas. Ils ont également toujours
pour destination le port Pb, qui doit être le même pour toutes les sockets B
(et donc, forcément, choisi explicitement par bind). Mais l'adresse
destination est une adresse de broadcast, qui regroupe tous les IPb1, IPb2,
etc.
Si B42 souhaite répondre, il va normalement répondre à (IPa, Pa), avec comme
source (IPb, Pb), c'est du pur unicast.
Une alternative serait d'avoir Pa=Pb, que A soit l'un des Bx, et qu'on ait
un groupe de sockets qui discutent ensemble en broadcast.
En pratique, ça donne ça. Côté A :
- création de la socket ;
- bind sur un port bien connu pour un rudiment d'authentification ;
- autorisation du broadcast ;
- sendto vers l'adresse de broadcast et le port où les gens sont censés
écouter.
Côté B :
- création de la socket ;
- bind sur le port où les gens sont censés écouter ;
- recvfrom ;
- vérification que l'adresse source est bien celle du serveur autorisé, et
que le port source est le port bien connu du serveur.
Si tout ceci ne suffit pas, je pense que quelques heures de lecture d'_Unix
Network Programming_ s'imposent.
gethostname(myname, MAXHOSTNAME); /* who are we? */
hp= gethostbyname(myname); /* get our address info */
if (hp == NULL) /* we don't exist !? */
return(-1);
sa.sin_family= hp->h_addrtype; /* this is our host address */
Beurk. gethostbyname est essentiellement obsolète.
Oui. Ceci dit c'est fait pour tourner sur un LAN non connecté et non accessible par les non-autorisés :) Donc niveau sécurité, c'est pas un souci...
Ne jamais négliger les petites améliorations de sécurité sous ce prétexte.
M'enfin bon, cela voudrait-il dire que pour balancer en permanence des données sur le port X en broadcast (192.168.0.255), il faille que je bind() la socket sur une adresse locale autre que celle du broadcast ?
Bon, apparemment, tu as des lacunes en réseau, on va reprendre doucement.
D'abord, en Unicast connecté, le plus simple : une socket A communique avec une socket B. Les paquets envoyés par A sont marqués avec IPa comme adresse source, Pa comme port source, IPb comme adresse destination, Pb comme port destination. Le choix d'IPa et de Pa a été fait soit par un bind explicite, soit par le noyau au premier usage de la socket A (au moment du connect par exemple) ; le choix d'IPb et de Pb a été fait soit par un bind explicite, soit par le noyau au premier usage de la socket B. En mode connecté, au moins l'une des deux socket, A ou B, a dû faire un bind explicite ; mais il faut bien comprendre qu'une fois la connexion établie, les rôles de A et B sont parfaitement symétriques.
Ensuite, l'unicast non connecté. S'il y a bien deux sockets qui se voient, c'est exactement la même disposition. Les différences sont :
- C'est un « hasard », si les ports et les adresses se correspondent, rien dans les protocoles réseau obligent les sockets à bien se situer en face l'une de l'autre, et A pourrait envoyer des paquets complètement dans le vide. C'est à un autre niveau, soit au niveau de la configuration du serveur, soit d'un protocole de plus haut niveau, qu'on s'assure que les paquets arrivent bien à quelqu'un.
- L'adresse source, IPa ou IPb, quand elle n'est pas choisie par un bind explicite, est choisie à chaque envoi de paquet, pour correspondre à la route directe.
Enfin, en broadcast (non connecté, forcément) : ici, on a une seule socket A, mais plusieurs socket B1, B2, etc.. Les paquets envoyés par A ont toujours pour source IPa et Pa, ça ne change pas. Ils ont également toujours pour destination le port Pb, qui doit être le même pour toutes les sockets B (et donc, forcément, choisi explicitement par bind). Mais l'adresse destination est une adresse de broadcast, qui regroupe tous les IPb1, IPb2, etc.
Si B42 souhaite répondre, il va normalement répondre à (IPa, Pa), avec comme source (IPb, Pb), c'est du pur unicast.
Une alternative serait d'avoir Pa=Pb, que A soit l'un des Bx, et qu'on ait un groupe de sockets qui discutent ensemble en broadcast.
En pratique, ça donne ça. Côté A :
- création de la socket ; - bind sur un port bien connu pour un rudiment d'authentification ; - autorisation du broadcast ; - sendto vers l'adresse de broadcast et le port où les gens sont censés écouter.
Côté B :
- création de la socket ; - bind sur le port où les gens sont censés écouter ; - recvfrom ; - vérification que l'adresse source est bien celle du serveur autorisé, et que le port source est le port bien connu du serveur.
Si tout ceci ne suffit pas, je pense que quelques heures de lecture d'_Unix Network Programming_ s'imposent.
gethostname(myname, MAXHOSTNAME); /* who are we? */ hp= gethostbyname(myname); /* get our address info */ if (hp == NULL) /* we don't exist !? */ return(-1); sa.sin_family= hp->h_addrtype; /* this is our host address */
Beurk. gethostbyname est essentiellement obsolète.
Thomas Nemeth
Laurent Wacrenier a tapoté :
Thomas Nemeth écrit:
Oui. Ceci dit c'est fait pour tourner sur un LAN non connecté et non accessible par les non-autorisés :) Donc niveau sécurité, c'est pas un souci...
La sécurité n'est pas uniquement contre les mailveillances, mais aussi contre les machines folles.
Oui, mais pour l'instant je ne dois faire qu'un programme de démo.
M'enfin bon, cela voudrait-il dire que pour balancer en permanence des données sur le port X en broadcast (192.168.0.255), il faille que je
Utiliser 255.255.255.255 comme adresse broadcast x.sin_addr.s_addr = htonl(INADDR_BROADCAST);
255.255.255.255 ?
bind() la socket sur une adresse locale autre que celle du broadcast ? Genre :
memset(&sa, 0, sizeof(struct sockaddr_in)); /* clear our address */ gethostname(myname, MAXHOSTNAME); /* who are we? */ hp= gethostbyname(myname); /* get our address info */ if (hp == NULL) /* we don't exist !? */ return(-1);
Pourquoi interroger le DNS ?
Parceque c'est la seule manière que je connaisse de récupérer l'adresse IP de la machine pour le moment (sans réfléchir ni chercher) :)
Thomas.
Laurent Wacrenier a tapoté :
Thomas Nemeth <thomas.nemeth@betatech.invalid> écrit:
Oui. Ceci dit c'est fait pour tourner sur un LAN non connecté et non
accessible par les non-autorisés :) Donc niveau sécurité, c'est pas
un souci...
La sécurité n'est pas uniquement contre les mailveillances, mais aussi
contre les machines folles.
Oui, mais pour l'instant je ne dois faire qu'un programme de démo.
M'enfin bon, cela voudrait-il dire que pour balancer en permanence
des données sur le port X en broadcast (192.168.0.255), il faille que
je
Utiliser 255.255.255.255 comme adresse broadcast
x.sin_addr.s_addr = htonl(INADDR_BROADCAST);
255.255.255.255 ?
bind() la socket sur une adresse locale autre que celle du broadcast
? Genre :
memset(&sa, 0, sizeof(struct sockaddr_in)); /* clear our address */
gethostname(myname, MAXHOSTNAME); /* who are we? */
hp= gethostbyname(myname); /* get our address info */
if (hp == NULL) /* we don't exist !? */
return(-1);
Pourquoi interroger le DNS ?
Parceque c'est la seule manière que je connaisse de récupérer l'adresse
IP de la machine pour le moment (sans réfléchir ni chercher) :)
