Bonjour,
 
J'utilise Dev-C++ 4.9.9.2 sous Windows XP, le compilateur est MinGW.
 
Mon but est d'utiliser poll() pour appliquer un timeout à une commande recvfrom().
 
 
 
D'après mes recherches, il existe select() à laquelle je ne comprends
rien, et poll() qui semble plus simple surtout avec des exemples.
 
 
 
(je me base sur http://hyatus.newffr.com/TAZ/Reseaux/prog_reseau1.html pour l'utilisation de poll() )
 
 
Et donc voici mon code :
 

 
Mon problème est qu'à la compilation, j'ai l'erreur suivante :
 
 
  [Linker error] undefined reference to `poll'
 
 
Bigre.
 
J'ai déjà du récupérer manuellement un poll.h qui n'était pas fourni avec Dev-C++, mais visiblement il lui manque encore un truc. (ou peut être que le poll.h récupéré n'est pas le bon pour MinGW).
 
Est-ce que poll() est implémentée dans mon environnement ?
 
Sinon, au pire, quelqu'un aurait-il un exemple clair et simple de la fonction select() si je suis obligé de passer par ça ?
 
Merci d'avance,
 
Arnaud

D'après cette page :
http://www.schweikhardt.net/identifiers.html
 
La fonction poll() est POSIX.2, ce qui signifie que tu la trouveras dans tous les unixoïdes récents, mais pas obligatoirement sur d'autres systèmes d'exploitation.
Windows a bien avancé la compatibilité avec POSIX.1, je ne sais pas où ils en sont de POSIX.2
 
Pour une bonne documentation sur les fonctions C, quel que soit l'OS sur lequel on est, une astuce connue est d'effectuer une recherche sur "man fonction_à_chercher" dans ton moteur de recherche préféré.
 
Ainsi :
 
select() = http://www.hmug.org/man/2/select.php
et
poll() = http://www.hmug.org/man/2/poll.php
 

Merci Elmoricq,
 
J'avais déjà trouvé les pages de man que tu me proposes, mais celle de select() est vraiment trop gratinée pour mon niveau de débutant total en C.
 
C'est dommage, le poll() me convenait parfaitement.
 
Bon, je vais essayer d'y comprendre quelque chose à select()... mais si de bonnes âmes ont pitié, elles sont les bienvenues !

 
Bah c'est pas en récupérant un fichier d'en-tête que ça va marcher. Il faut que la fonction soit définie dans un fichier .c ou une bibliothèque (style libc). Le fichier d'en-tête déclare juste la fonction.

Merci Karlkox,
 
Par contre il ne connait pas STDIN, qu'est ce qui me manque ?

Je pense qu'il s'agit de STDIN_FILENO, définit dans unistd.h

... marche pô    
 
en fait il n'attend pas le timeout et me rend la main aussitôt en affichant le msg d'erreur.
 
Pourtant je suis sûr qu'un datagramme UDP arrive puisque je l'émets, et je le vois en sniffant la carte.
 
Si j'affiche rc, il est égal à 1.
 
 
 

STDIN_FILENO
 
Sous Windows, select() ne fonctionne que sur le sockets. (Voir WaitForMultipleObjects() ou un bazar comme ça...)

 
Ca tombe bien, c'est justement les sockets que j'utilise !    
 
C'est vrai que STDIN_FILENO me surprenait un peu, mais dans mon désarroi j'ai essayé quand même...
 
Marche toujours pô  

Tu as inclu unistd.h ?

 
Oui, je l'ai inclus, mais apparement ça se réfère à une entrée fichier, moi je suis sur une socket réseau.
 
J'ai trouvé ce truc :

 
que je vais tester de ce pas...

Ah, je pensais que par "ça marche po", tu voulais dire que ça ne compilait pas.
Il faut être plus précis.

... et qui marche pas non plus.
 
C'est quand même bizarre tout ça.

 
Oui excuse-moi, ça se compile, mais ça ne fait pas ce que je veux...
 
Le principe :
 
1. Emetteur -message-> recepteur
 
2. Emetteur passe en écoute avec mon select() et un rcvfrom()
 
3. Recepteur -accuséReception-> emetteur
 
-> mais mon emetteur ne capte jamais mon accusé de réception (une bête chaîne "ok" que je vois passer en sniff).
 
(note : par contre systématiquement mon emetteur envoie une réponse ICMP "host unreachable" après l'arrivée de l'accusé de réception, mais apparement c'est un bug windows connu, et ça ne devrait pas empêcher la récupération de l'accusé)

Ha, je viens de découvrir un truc :
 
Si mon récepteur et mon emetteur tournent sur la meme machine, et que j'envoie sur 127.0.0.1, ça fonctionne.
 
Par contre, si j'envoie sur l'adresse ip réelle de la machine (toujours dans le cas ou emetteur et recepteur sont sur la même), ça ne marche plus.
 
Ca vous met sur une piste ?

Bon, vous pouvez laisser tomber, je m'aperçois que le fonctionnement en loopback est aléatoire, mon truc est donc complètement foireux, je vais revoir ça à tête reposée.
 
Merci à ceux qui m'ont répondu.

La nuit porte conseil... en voici la preuve :
 
Hier j'étais persuadé que mon récepteur ne captait pas ou ne traitait pas le message de mon emetteur.
 
Finalement, ce matin je me suis aperçu que le message de l'emetteur arrivait avant que mon recepteur n'ait eu le temps de se mettre en écoute !
 
Donc, voilà, une ptite tempo à coup de Sleep, et c'est réglé !
 
Merci !