Discussion :

[Sékiltoyai]

Bonjour,

Je suis en train de réaliser un serveur en C pour un projet. Pour information je suis sous environnement UNIX (darwin). Je me suis un peu documenté, c'est un peu compliqué sachant que les mans peuvent être quelquefois très mal faits.

Bref, j'ai regardé quelques exemples et tous, après le accept, utilisent un fork() pour régler le problème des sockets bloquantes. Pour ma part, je ne suis pas particulièrement fan de cette solution, et je me demandais si c'était la meilleure.

Ainsi, j'ai plutôt imaginé la structure de mon système ainsi :
- Le serveur, lancé par launchd, fait un unique fork (ou bien lance directement un binaire différent) pour lancer le démon de traitement, les deux sont reliés par deux pipes. Il s'occupe de l'interface avec le réseau, connecte et déconnecte les clients, parse les requètes (en XML), et les transmet au démon de traitement.
- Le démon de traitement reçoit les données de tous ses clients par une seule pipe, les traite, et en envoie au serveur par la seconde pipe, lequel dispatche aux clients.

Ainsi, le serveur ressemblerait à cela :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
exec('démon de traitement');
   => pipe('to démon de traitement');
   => pipe('from démon de traitement');
 
socket/bind('connexion extérieure'); => fcntl('non bloquante');
 
while(1)
{
 
    accept('eventuel client'); => fcntl('non bloquante');
 
    if(select('lecture pipe et connexions'))
    {
        recv('pipe from'); => send('client');
        for('chaque client')
        {
            recv('client'); => send('pipe to');
        }
    }
 
}

Et le démon de traitement :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
while(1)
{
 
    if(select('lecture pipe'))
    {
        recv('pipe to'); => traitement(); => send('pipe from');
    }
 
}

Ainsi, amha, il n'y aurait pas besoin pour le démon de traitement de s'occuper de toute la gestion réseau et cela règlerait énormément de problème. Seulement, je n'ai jamais fait de programmation sockets auparavant et je voudrais valider ma méthodologie :
- Est-ce une façon viable de faire ? Y a-t-il des importants points de blocage que je n'aurais pas vu ?
- Est ce que j'aurais besoin de mettre un test en écriture vers les sockets dans le select du serveur ou bien est ce que le tampon du système est assez grand pour ne jamais être overflowé ?
- Du coup, est ce que j'aurais besoin de tampons au niveau du serveur pour transmettre les données des connexions à la pipe et vice versa ?

Merci de vos réponses et éclaircissements, si vous avez des remarques supplémentaires, n'hésitez pas.

[granquet]

quel usine a gaz

pourquoi ne pas utiliser select tout seul? sans fork et autres pipes?

[Sékiltoyai]

Parce que j'ai envie d'avoir une partie de traitement complètement indépendante du réseau. Genre que le traitement puisse tourner alors que le serveur ne transmet rien, ou l'inverse. Et que cela me semble peut être plus simple à mettre en œuvre.
Mais je suis ouvert à d'autres possibilités, tu as quelquechose à me proposer pour fusionner les deux ?

[millie]

Pourquoi pas des threads ? (même si je suis souvent de l'avis qu'il vaut mieux utiliser des select au lieu de faire intervenir des threads ou processus supplémentaire).

La création de thread mettent en général 15 fois moins de temps qu'une duplication de processus avec fork et permet d'éviter de bouffer de la mémoire pour rien (puisque seul une nouvelle pile est crée)

[Sékiltoyai]

Pourquoi pas des threads ? Réponse simple : trop galère.
Je suis conscient que ce serait une des meilleures solutions. Cependant c'est un petit projet pour lequel je n'aurais pas le temps d'apprendre la mise en œuvre et surtout de maîtriser l'utilisation des threads. Je dois par ailleurs avouer que j'avais dès le début complètement exclu cette option. A moins que l'on me fasse mentir, les threads sont tout de même (de l'aveu de certains de mes amis) assez complexes à intégrer. Par ailleurs, j'ai déjà les problèmes de socket à régler, je n'ai pas envie de devoir gérer en plus ceux que j'aurais avec les threads.

Pour le coup, deux processus distincts seraient beaucoup plus simples à coder. Après, serait-ce une solution viable ? Quelle serait ses limites fasse à une solution select ou bien une solution threads ? Y aurait-il quelqu'un pour une comparaison/explication des 3 options ?

[millie]

Effectivement, les threads, c'est galère. C'est difficile à débugguer, c'est difficile à coder proprement. C'est pourquoi on utilise souvent (en C) des solutions à base de select jusqu'à ce que l'intervention des threads soient nécessaires (ou rende le code plus simple)

Par ailleurs, j'ai déjà les problèmes de socket à régler, je n'ai pas envie de devoir gérer en plus ceux que j'aurais avec les threads.

Dans ce cas, évite absolument les threads et concentre toi uniquement sur les sockets. Il est possible de faire à peu près tout rien qu'avec des select. Mais si tu penses que la solution avec fork te parait plus simple, fait comme tu le sens.