Discussion :

[SeRiALP]

Bonjour je dois faire un programme client/serveur semblable a un irc et je suis limite en fonction pour ce projet...
En gros:
- Le programme doit etre non-bloquant
- utilisation d'un seul select
- Pas de fork

voila en gros si vous avez des astuces et conseils je serai ravi d'en beneficier

cordialement,

[Obsidian]

- Le programme doit etre non-bloquant
- utilisation d'un seul select
- Pas de fork

Voici un cadre qui me plaît fortement ! On a un peu trop tendance à se rabattre sur les threads ces dernières années, même avant le développement massif du multi-core dans le grand public ! :-)

Ou en es-tu actuellement et qu'est-ce qui te bloque ?

[LittleWhite]

Bonjour,

Je crois que les professeurs ont toujours demandé la même chose. Après je ne suis pas complètement sur que l'on peut le faire sans threads, mais je crois que lorsque j'ai fait mon IRC-like, il était sans threads ( sans fork et un select bien sur ).

Mais de toute façon, les threads sous Unix sont facile ( vive posix ).

Les conseils:

- Ecrire du code propre
- Commenter le code ( si possible faire des commentaires compatible doxygen ( se sera surement un plus )
- Valgrind est un outil géniel ; évitons les fautes de mémoire
- gdb est aussi un outil géniel ( évitons les erreurs de segmentation )
- strace est aussi un outil super bien pour tout les appel système que l'on comprend un peu mal ce qui se passe ( marche très bien sur read / write / select )
- Une analyse UML peut être utile
- Ne pas ecrire tout dans un fichier main.c

( Bon j'arrête ici, j'en demande surement un peu de trop :s )

[SeRiALP]

Ou en es-tu actuellement et qu'est-ce qui te bloque ?

Bonjour je suis content que mon sujet intéresse plus d'un, actuellement en faite je suis la conception de mon serveur. (je l'ai commnce qu'aujourd'hui)
Et je crois que pour résoudre le mode NON-BLOQUANT, tout es dans le select,
mais j'ai bien peur de ne pas avoir encore assimiler tous les contours de cette merveilleuse fonction.
Donc je sais si le fait de lui donné simplement un utimeout de 0 résoudra définitivement mon serveur non bloquant. Je continue toujours de parcourir un peu de doc, mais aussi je viens vers vous afin de savoir si je suis sur la bonne voie ou je vais chercher trop loin.

Pour info, la semaine passer je devais réaliser dans un premier un my_ftp avec l'appel système fork(), et donc un programmme bloquant. ce qui a été pas mal comme projet d'ailleurs.

Voila, j'espere que j'ai un on ne peut plus clair sans pour autant m'eloigner du topic principal.

merci d'avance
Cordialement,

[Obsidian]

Donc je sais si le fait de lui donné simplement un utimeout de 0 résoudra définitivement mon serveur non bloquant. Je continue toujours de parcourir un peu de doc, mais aussi je viens vers vous afin de savoir si je suis sur la bonne voie ou je vais chercher trop loin.

Je ne pense pas que ce soit cela que tes profs veuillent que tu fasses. L'idée générale, c'est de se mettre à l'écoute de plusieurs canaux différents simultanément, d'où le select(). Mais si aucun canal n'émet, il faut quand même rester bloqué sur le select(), sinon ce serait une attente active. C'est la raison d'être de cette fonction, et le « nano-IRC » est un exercice assez courant pour s'entraîner.

[SeRiALP]

d'apres ce que j'ai compris du sujet et du role de select c'est qu'il ne reste pas en mode bloquant pour attendre de recevoir des infos puisqu'il devra traiter etre capable de traiter plusieurs client a la fois, donc si un client envoi un message, tous les autres clients doivent recevoir le message. d'ou l'interet de rendre mon programme non bloquant si j'ai bien compris...

[Obsidian]

Non, le rôle de select() est de permettre le monitoring de plusieurs descripteurs à la fois, et de débloquer lorsqu'il se passe quelque chose sur l'un d'eux. C'est exactement ce qu'il te faut pour faire un IRC (ainsi que pas mal d'autres choses :-).

Sans ce mécanisme, tu serais obligé de tourner en boucle sans arrêt et faire du polling sur tes descripteurs en consommant 100% de ton CPU.

[SeRiALP]

ok, ca c'est compris.
Mais en gros:
1- qu'est-ce qui permet de faire un select non-bloquant?
comment faire la difference en le select bloquant et le non-bloquant ?

2) et pour quoi select prend en premier parametre max + 1? tel que select(max + 1, ---, ---, ---); ?
pourquoi le "+1"? c'est vraiment pas explique ca en gros je le fais sans savoir pourquoi c'est pas trop logique pour moi...
merci de m'eclairer sur ces points la.

cordialement,

[SeRiALP]

je crois que pour la reponse a ma 2 question c'est dans la fonction que je vais utiliser pour recuperer le nombre de fd maximal pour un processus.
Cette fonction qui est getdtablesize() retourne le nombre maximal de fichiers qu'un processus puisse ouvrir simultanément, soit un de plus que la plus grande valeur possible pour un descripteur de fichier.

mais je sais si c'est par convetion qu'il faut +1 mais bon je l'utilise comme ca.

au depart j'utilsait getrlimit avec comme flag RLIMIT_NOFILE qui me retourne (2763 + 1) et que me retourne aussi getdtablesize qui est plus pratique je pense.

ps: desole pour le 2 post je voulais que ce soit plus explicite ici

[Obsidian]

1- qu'est-ce qui permet de faire un select non-bloquant?
comment faire la difference en le select bloquant et le non-bloquant ?

Comme tu l'as dit, en faisant pointer utimeout vers sur une structure timeval ne contenant que des zéros. Cela dit, je maintiens que je suis persuadé que ce n'est pas ce que tes profs veulent que tu fasses, malgré l'énoncé (imprécis).

2) et pour quoi select prend en premier parametre max + 1? tel que select(max + 1, ---, ---, ---); ?

Probablement parce que la fonction va directement déclarer un tableau, et va se servir des numéros de descripteurs comme index dans ce tableau. Comme il y a de grandes chances pour que les numéros des descripteurs surveillés ne soient pas consécutifs, ça reste la manière la plus propre de faire.

[SeRiALP]

C Cela dit, je maintiens que je suis persuadé que ce n'est pas ce que tes profs veulent que tu fasses, malgré l'énoncé (imprécis).

Merci, je viens aussi de poser la question a des potes de ma promo, et ca corrobore tes dires:
en fait on a pas le droit aux "Sockets Non-Bloquantes", donc par exple pas la peine de pense utiliser la fonction fcntl en lui passant le socket et la macro O_NONBLOCK (si je me rappel bien de l'ortographe);
A la limite ou s'en fou que select soit bloquant ou pas son role c'est d'attendre qu'un évènement se passe sur l'un des fds pour réagir en conséquence, alors que si j'utilise timeval avec 0 ile ne fera que tourner en boucle et bouffant 100% de mon CPU.

voila je pense que c'est bien ca et c'est bien ce que tu disais et que je pense avoir bien assimiler.

merci d'avance. j'aimerais bien si tu veux t'envoyer l'ébauche de mon serveur pour que tu me dises ce que t'en penses, tes critiques seront les bienvenues.

Ps: pour le code(serveur), je préférai te l'envoyer si tu vois pas d'inconvénient en prive en .tar (pour question d'étique...)

[orfix]

...en fait on a pas le droit aux "Sockets",...

Il y a bien un appel à socket() dans ton programme ?

A la limite ou s'en fou que select soit bloquant ou pas son role c'est d'attendre qu'un évènement se passe sur l'un des fds pour réagir en conséquence, alors que si j'utilise timeval avec 0 ile ne fera que tourner en boucle et bouffant 100% de mon CPU.

1. Si tu mets les deux champs de timeval à 0 select seras non bloquant et retourneras immédiatement, tu seras donc tenté de le mettre dans une boucle et vérifier à chaque tour de boucle si un des descripteurs (ou plusieurs) est prêt pour une opération d'E/S ou non, c'est très gourmand en ressource.
   
2. Si par contre tu passes NULL au lieu d'un pointeur vers une struct timeval ton select seras bloquant et ne retournera que si un des descripteurs (ou plusieurs) est prêt pour une opération d'E/S.
   
3. Le compromis entre les deux est d'initialiser l'argument timeval à une valeur raisonnable, select retournera dès qu'un des descripteurs (ou plusieurs) est prêt pour une opération d'E/S ou que le temps spécifié s'est écoulé.

Je serais toi je choisirais d'abord le select bloquant, si ce n'est pas possible le select pseudo-bloquant (est-ce comme cela que ce mécanisme est appelé ?) et enfin le select non bloquant (avec des appels à sleep de temps à autre).

Bon courage.

[SeRiALP]

Il y a bien un appel à socket() dans ton programme ? .

Haha, j'ai omis un mot tres important, sinon on peut pas faire de reseaux sans sockets ^^. Donc je voulais plutot ditre qu'on a pas droits au "sockets non-bloquantes"

merci pour ta reponse