Socket accept precisions

**pmier** · 20/12/2007, 18h50

Bonjour,
Dans le cours de frederic Lang (que je trouve d'ailleurs très bien et que je tiens à remercier) je lis :

La primitive accept() extrait une demande de connexion de la file d'attente. Lorsque la connexion
est acceptée, le serveur crée une seconde socket sur laquelle se feront les échanges de données.
Lorsque ceux-ci sont terminés, le système détruit cette seconde socket et le serveur peut reprendre
son écoute sur la première socket (ou extraire une autre demande de la file d'attente).

Je comprends en lisant cette dernière phrase que lors de l'échange de données à l'aide de la seconde socket le serveur cesse son écoute et donc qu'une nouvelle connection ne peut être acceptée bien qu'elle puisse etre mise en attente (si le nombre max de connec en attente n'est pas dépassé)

J'ai croisé cette supposition avec d'autres cours mais ce n'est jamais super clair et souvent contradictoire, pouvez vous confirmer ou infirmer mon interprétation?

**ram-0000** · 20/12/2007, 20h54

Si ton appli est mono process/thread, tu as raison

A l'issue d'un accept(), on travaille avec le socket client et il devient impossible de traiter de nouvelles demandes de connexions car l'appli n'est plus dans la fonction accept().

C'est pour cela que l'on fait différemment
un thread gère le socket serveur celui qui fait accept(). Dès qu'une connexion est acceptée, le socket client est donné et géré par un nouveau thread créé en cette occasion.

Attention toutefois à ne pas multiplier les threads car sinon, les performances de la machine vont s'effondrer.

Ce genre de fonctionnement marche parfaitement pour une petite application mais ce n'est certainement pas applicable à un serveur WWW qui doit/peut traiter quelques milliers de connexions simultanées

**Médinoc** · 20/12/2007, 21h34

Perdu.
Le socket est toujours en écoute après un accept() : Il y a une file d'attente.

C'est ce qui permet d'utiliser des fontions comme select(), qui disent plus ou moins "préviens-moi s'il se passe quelque chose sur une de ces sockets, et dis-moi laquelle"...

**ram-0000** · 20/12/2007, 21h44

Exact, le socket est toujours en écoute mais aucune nouvelle connexion ne sera reçue et traitée par le programme si l'on n'est pas dans accept()

**pmier** · 20/12/2007, 22h50

Oui oui ram a bien compris mon interrogation. Effectivement du fait de la file d'attente le socket est toujours à l'écoute (merci pour cette explication complementaire, donc tu veux dire que le socket pdt ce temps peux toujours detecter des connections par exemple ? (meme si le accept vient d'etre fait?)) mais ma question etait plus de savoir si une autre connection pouvait etre traitée durant ce temps (pendant que le 2ème socket est utilisé).

En fait ce qui m'a fait me poser cette question c'est ce code que j'ai trouvé ici : http://beej.us/guide/bgnet/output/ht...l#simpleserver

Il s'agit du code d'un serveur :

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
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
/*
** server.c -- a stream socket server demo
*/

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <errno.h>
#include <string.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <arpa/inet.h>
#include <sys/wait.h>
#include <signal.h>

#define MYPORT 3490    // the port users will be connecting to

#define BACKLOG 10     // how many pending connections queue will hold

void sigchld_handler(int s)
{
    while(waitpid(-1, NULL, WNOHANG) > 0);
}

int main(void)
{
    int sockfd, new_fd;  // listen on sock_fd, new connection on new_fd
    struct sockaddr_in my_addr;    // my address information
    struct sockaddr_in their_addr; // connector's address information
    socklen_t sin_size;
    struct sigaction sa;
    int yes=1;

    if ((sockfd = socket(AF_INET, SOCK_STREAM, 0)) == -1) {
        perror("socket");
        exit(1);
    }

    if (setsockopt(sockfd, SOL_SOCKET, SO_REUSEADDR, &yes, sizeof(int)) == -1) {
        perror("setsockopt");
        exit(1);
    }
    
    my_addr.sin_family = AF_INET;         // host byte order
    my_addr.sin_port = htons(MYPORT);     // short, network byte order
    my_addr.sin_addr.s_addr = INADDR_ANY; // automatically fill with my IP
    memset(my_addr.sin_zero, '\0', sizeof my_addr.sin_zero);

    if (bind(sockfd, (struct sockaddr *)&my_addr, sizeof my_addr) == -1) {
        perror("bind");
        exit(1);
    }

    if (listen(sockfd, BACKLOG) == -1) {
        perror("listen");
        exit(1);
    }

    sa.sa_handler = sigchld_handler; // reap all dead processes
    sigemptyset(&sa.sa_mask);
    sa.sa_flags = SA_RESTART;
    if (sigaction(SIGCHLD, &sa, NULL) == -1) {
        perror("sigaction");
        exit(1);
    }

    while(1) {  // main accept() loop
        sin_size = sizeof their_addr;
        if ((new_fd = accept(sockfd, (struct sockaddr *)&their_addr, \
                &sin_size)) == -1) {
            perror("accept");
            continue;
        }
        printf("server: got connection from %s\n", \
            inet_ntoa(their_addr.sin_addr));
        if (!fork()) { // this is the child process
            close(sockfd); // child doesn't need the listener
            if (send(new_fd, "Hello, world!\n", 14, 0) == -1)
                perror("send");
            close(new_fd);
            exit(0);
        }
        close(new_fd);  // parent doesn't need this
    }

    return 0;
}

En fait j'ai betement cru (je sais pas pourquoi!) que fork testait la presence d'un fils et je captais pas pourquoi il y avait un fils si il y avait blocage. (fin bref quoi!)

Donc si je capte bien dans ce programme fork cree un processus fils.
Dans le fils on envoi un message. Ici ensuite on ferme la socket mais on pourrai tres bien la laisser ouverte sans gener le pere si on voulait continuer le dialogue.

Dans le pere on ferme la socket qui sert au dialogue ce qui a pour effet de pouvoir eventuellement accepter une nouvelle connection. Le père n'est bloqué qu'entre le accept et le moment ou il ferme le socket qui sert au dialogue (new_fd) c'est ca?

**ram-0000** · 21/12/2007, 09h24

Il me plait bien ce bout de code (même si je n'aime pas trop la manière dont il est écrit)

je te le remet en pseudo code

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
22
23
24
25
26
27
28
29
 
while(1)
{
   // attente sur le socket serveur
   socket_client = accept(socket_serveur);
 
   // creation d'un fils
   if(!fork())
   {
      // code du fils
      // fermeture du socket serveur (inutile dans le process du fils)
      close(socket_serveur)
 
      // bla bla sur le socket client
      send(socket_client)
 
      // fermeture du socket client
      close(socket_client)
 
      // mort du fils
      exit()
   }
   else
   {
      // code du pere
      // fermeture du socket client (inutile dans le process du pere)
      close(socket_client)
   }
}

en fait, le pere est bloque sur un accept(), dès qu'une connexion est détectée, elle est acceptée immédiatement, un process fils est crée qui va gérer le nouveau socket client et le père retourne sur son accept() pour attendre de nouvelles connexions

**Médinoc** · 21/12/2007, 09h47

Le serveur-fork est bien si les clients n'ont aucune interaction possible (genre, serveur HTTP basique), mais je ne le recommanderai pas pour un chat par exemple...

De plus, tu ne testes pas si fork() échoue.

**souviron34** · 21/12/2007, 13h48

Envoyé par Médinoc

Le serveur-fork est bien si les clients n'ont aucune interaction possible (genre, serveur HTTP basique), mais je ne le recommanderai pas pour un chat par exemple...

bah en quoi est-ce un problème ???

Dans chaque serveur (père et fils) il suffit d'avoir une liste des connections...

**Médinoc** · 21/12/2007, 14h27

Et donc, si un nouveau client se connecte, il faut prévenir tous les processus fils, ou bien utiliser de la mémoire partagée (auquel cas, à quoi bon avoir séparé le serveur en différents processus)...

**souviron34** · 21/12/2007, 15h40

ben prevenir c'est rien ..

Et pour la mort, c'est pareil..

Et la memoire partagee est trop restrictive (une seule machine)

**pmier** · 21/12/2007, 15h40

Ram : merci de ces precisions ca confirme ce que je pensais

Souviron34 : tu es devin ou quoi ? Ou alors je suis super prévisble

j'avais justement prévu comme étape d'après dans l'apprentissage de faire un tchat !

Medinoc je note qu'il y a plusieurs manières de faire, je ne vois pas encore trop l'autre manière mais je chercherai quand je serai plus avancé dans le cours, je n'ai pas encore vu le select et consoeurs et je sens qu'il y a quelquechose à en faire !