Bonjour,
 
Je cherche à coder un serveur multi-clients et utiliser poll() pour la gestion des sockets.
 
J'ai fait quelque teste.
 

 
Donc voilà, avec des sockets non bloquant.
 
Mais j'ai quelque problèmes :
- Y'a t'il un autre moyen qu'en whilant ou de verifier dans le while si il y'a eu un event au lieu de while(1).
- Pourquoi les flags de revents ne se mettent pas à jour à chaque boucle (si je recois une donnée, dans toutes les boucles suivante mon file descriptor aura le flag POLLIN.
 
Merci

Est ce que tu as pensé à utiliser des thread ou des processus?

D habitude on utilise plutôt la fonction accept() sur un socket serveur bloquant. (voir man 2 accept, man 2 listen).
Puis quand une connection arrive, on crée une nouvelle thread ou un nouveau processu pour traiter la connexion.
 
poll() est plutôt utilisé sur plusieurs sockets à la fois. Là tu n en a qu une, et pourtant tu fait:
  poll(poll_list, 2, -1);
en est tu sur?
 
Dans ton code la ligne ...accept(listen(...))) n accepte qu une seule connexion client. Tu devrai mettre le listen avant et boucler sur accept. le poll() porte ici sur la socket client.

J'ai juste montrer un exemple, mon serveur est censé accepter 2000 connection et mon listen se situe avant.
 
Je ne vais pas créer un thread pour 2000 connection

Evidemment non, mais il est courant de créer un thread par connexion. C'est fait pour. Il faut de la mémoire, c'est tout.

et le retour de poll, tu t'en fiches ?

 
Meme résultat ((
 
Et pour les thread, je me suis renseigné apparement pour bcp de connection c'est trop lourd (mon serveur est sensez pouvoir recevoir 2000 connection mais par seconde, meme avec un pool thread serait trop lourd.
 
Mais bref ! j'ai toujour problème avec poll().
 
Quelqu'un aurait un tuto avec exemple mise à part le man ?
 
Merci

si c'est -1, c'est sans doute une erreur, pas un cas à ignoré. voir perror()
 
c'est fait exprès les poll et le non-bloquant ? tu t'emmêles pas les pinceaux là ?  
 
et c'est quoi le problème en fait ? si ça reste sur POLLIN, c'est que y a des données, voilà tout, rien de sorcier ...

Quitte à me répéter:
 
> Dans ton code la ligne ...accept(listen(...))) n accepte qu UNE seule connexion client.
 
> le poll() porte ici sur la socket CLIENT.
 

Taz -> Non il n'ya aucune donnée.
nargy -> Je connect 1 seul socket en effet mais c'est pour faire mes teste, j'ai tester avec une 20 aine de connection c'est pareil

Je crois en faite que vous n'avez pas compris mon problème :
 
Pourquoi cela while a l'infinie sur "recu" dès que j'envoi 1 octect !

tant que tu ne lis pas les données que tu as reçues, elles sont toujours disponibles et poll continue à te générer un événement POLLIN

merci beaucoup franceso, je n'y avait pas pensé

Pour savoir,
 
Normalement le flag POLLHUP ou POLLERR est sensé s'ajouter au bitmask quand le client se déco ?
 
Car moi pas du tout Oo
 
Merci

et pourtant ...
 
ça peut varier en fonction de l'OS. si t'as un POLLIN de toutes façons, tu fais ton read, si ça te retourne 0, ben c'est EOF.

Oui je sait bien pour le read mais j'aurait autant aimer exploiter a fond poll.
Pour info je suis sous Debian.
 
Enfin merci ^^

 
Etant donné que mon sock est non bloquant, comment eviter la charge maximum du CPU ?
 
Merci

usleep()

#for (i = 1; i <= maxfd; i++)
 
tu zappe le premier élément et overflow. on fait pas du pascal.
 
# poll(poll_list, maxfd, -1);
avec ça meme avec overflow, tu peux être sur que ton new_fd ne sera jamais traité
 
#if (poll_list[i].fd == -1)
 
je pense qu'avec ça, poll va te renvoyer -1
 
#if (poll_list[i].revents & (POLLERR | POLLHUP) {
# printf("ended\n" );
tu n'écoutes rien. je t'ai dit que s'il y a EOF, tu auras POLLIN
 
#if (recv(poll_list[i].fd, pSock, 512, 0) < 1)  
-1 ou 0 ça fait une sacrée différence.
 
# poll_list[i].fd = -1;
vire plutot ce descripteur de la liste

lire le man de poll

jamais. c'est stupide, c'est juste la meilleure façon de s'assurer que son application va tourner le plus lentement possible.

Taz ma question n'était que sur la charge du CPU, pas sur le reste (le reste n'est pas un code que je vait utiliser, je met des bouts de code pour tester différentes solutions.) enfin merci quand meme et nargy j'ai jamais vu qu'on ralentissait une application pour moins de charge.

usleep(0)
Ça fait pas aller le processus le plus lentement possible, ça oblige l OS à changer changer de contexte quand tu n a plus rien à faire dans ta boucle while(1), et c est tout.
S il ne revient pas de usleep(0), c est qu il y a un autre processus fou qui fait un while(1).

> jamais. c'est stupide, c'est juste la meilleure façon de s'assurer que son application va tourner le plus lentement possible.
 
Quand tu n a rien à faire dans un while(1), la seule chose qui te reste à faire c est tourner le plus lentement possible.
C est pas parce que tu bouffe plus de CPU que les connexions vont arriver!

certes, mais si tu fais un usleep(t), tu traiteras en moyenne tes connexions entrantes avec un retard de t/2.
Si tu fais un usleep(0), tu vas effectivement laisser la main aux autres processus, mais tu vas quand même bouffer toute la puissance restante du processeur.
 
poll() et select() sont justement faits pour éviter ce genre de désagréments et placer ton processus en attente jusqu'au moment où il a quelque chose à faire.

franceso> entièrement d accord
 
J ai récupéré le nombre maximum de processus que préconise le noyau linux 2.4: 4096 (getrlimit)
 
On est donc en dessous avec 2000. Le traitement par thread ou processus reste envisageable.
 
Au delà de cette valeur, il est préférable d avoir un load balancing.
 
Le choix final dépends de la taille des connexions traitées, ``4096`` correspondant sûrement à l ordre de grandeur du kilooctet.
 
Pour des mégaoctets ou des octets il faudrait des tests. C est à Dinan de voir.

Non les thread pour mon projet n'est pas une solution étant donné que les connections par clients seront toute les 2sec environs. De toute facon je n'est aucunement donné un avis sur la facon dont je traiterait mes clients.
Poll reste la meilleur solution d'après nombre d'avis.
 
Enfin, merci, je vait chercher pour la charge de Poll.
 
Merci fransesco

c'est pas seulement ça qui est important ; c'est aussi le temps que tu mets pour servir un client. Si tes connexions arrivent toutes les deux secondes, mais que tu mets 10 minutes à traiter la demande d'un client, tu vas pas t'en sortir avec un seul thread/processus.
 

De rien, mais c'est franceso