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.