voila j'ai un appli en C qui envoie une requete udp en broadcast, jusque la pas de probleme. mais pour la reception je bloque un peu. c'est presque + de l'algo qu'autre chose mais jy connais rien en prog rezo
 
donc pour la reception le probleme c'est que je peux tres bien avoir entre 0 et xxx réponses. j'envoie ma requete udp et tout les postes succeptible d'y repondre le font. donc j'ai vraiment aucun moyen de savoir combien de reponse je vais avoir.
Alors je bloque sur le fait que des que je lis sur le socket pour voir si jai une reponse, ça bloque tout. si jai qqchose ça passe tout de suite c'est bon, mais sinon je dois attendre un timeout. si je me 2s pour le timeout c'est sympa, mais 2s par lecture du socket ça devient vite lent.
alors ya tils une methode genre non bloquante pour les sockets udp? dois-je forcement utiliser un thread ou un fork pour ecouter en permanance?
juste histoire d'avoir vos avis  
 
c'est pour un soft qui detecte les serveurs de jeux en lan, genre counter etc pour leur faire la peau

Multithreade et rend tes sockets non bloquants avec FD_SET

il peut aussi utiliser select() ?

ok pour le multithread, qqun aurait de la bonne doc? le fork ça serait pas une bonne alternative? ça a lair plus simple
 
ensuite pour select() jy ai jamais rien compris c pas en gros pour savoir si qqchose est arrivé parmis plusieurs socket? la jen ai qu'une seul et en udp alors jsais pas. jveu bien essayer mais la je patoge

ba le fork ca te donne tu multithread vu que tu ajoutes un process pour coordiner l'action de ton process père...
 
genre tu fork et le process fils recoit les réponses udp et les communiques au process père par des signaux

ouai jvais voir en forkant
mais c'est que je minteressais au thread un peu (pthread etc) mais jmen vraiment de doc genre comment communiquer entre les threads etc

La différence entre processus (fork) et threads (pthread_machin) :

• si tu fais un fork, les seuls moyens de communiquer entre les 2 processus sont les trucs classiques style pipes, système de fichier en général, IPC systemV (qui passent aussi par le système de fichier d'ailleur) et sockets (unix plutôt que réseau dans ce cas là). Faire une interraction d'un processus à l'autre, c'est changer de contexte, c'est lourd.

• si tu fais des threads, ils restent dans le même espace mémoire, chacun ayant sa petite pile d'appel (les variables globales de la libc étant alors au fond de la pile, de façon à ne pas foutre le bordel entre les threads). Tu peux donc partager directement de la mémoire, toute l'infrastructure pour protéger les accès concurrents est fournie par des pthread_machin. Faire une interraction entre threads c'est léger, on est entre gens de la même famille, pas de chichis.

Si tu n'as pas envie de te prendre la tête et que tu n'as pas de grosse concurrence intrinsèque, le select() avec une seule tâche, c'est le mieux, car rentrer dans la concurrence, c'est rentrer dans le merveilleux monde des bugs de synchronisation.