Socket, recv et select qui ne marche pas

**Zapan** · 29/06/2006, 09h31

Bonjour,

Je réalise une fonction (sous linux) pour améliorer la fonction recv, notamment en gérant les paquet coupé en ethernet et un timeout :

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
int recvPaquet(int sock, char *paquet, int longueur)
{
  int nbRecu = 0, nbRecu2 = 1;
  int retval;
 
  fd_set readfds;
 
  struct timeval timeout;
 
  FD_ZERO(&readfds);
  FD_SET(sock, &readfds);
 
  timeout.tv_sec = TIMEOUT; 
  timeout.tv_sec = 1; 
  timeout.tv_usec = 0;
 
  retval = select(1, &readfds, NULL, NULL, &timeout);
 
  if (retval) {
 
    nbRecu = recv(sock, paquet, longueur, 0);
 
    // On gère le cas ou tous les caracteres voulu ne sont pas arrivées
 
    nbRecu2= nbRecu;
 
    while ((nbRecu > 0) && (nbRecu != longueur) && (nbRecu2 > 0)) {
 
      paquet += nbRecu2;
 
      nbRecu2 = recv(sock, paquet, longueur - nbRecu, 0);
 
      if (nbRecu2 >= 0) {
	nbRecu += nbRecu2;
      }
      else {
	nbRecu = nbRecu2;
      }
 
    }
    return nbRecu;
  }
  else {
    printf("recvPaquet %d\n",retval);
    return -1;
 
  }
 
}

Seulement retval vaut toujours 0, et la fonction retourne -1. Je ne comprend pas pourquoi.

**Médinoc** · 29/06/2006, 09h39

essaie avec sock+1 en tant que premier paramètre de select()...

**Zapan** · 29/06/2006, 09h45

J'ai essayer avec sock+1, la fonction ne retourne plus systématiquement -1. apparement ca marche, je vais appronfondir les tests.
Merci.

**Zapan** · 29/06/2006, 10h28

J'ai fait la même chose pour la fonction send

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
 
int sendPaquet(int sock, char *paquet, int longueurPaquet)
{
  int nbRecu = 0;
  int retval;
 
  fd_set readfds;
 
  struct timeval timeout;
 
  FD_ZERO(&readfds);
  FD_SET(sock, &readfds);
 
  timeout.tv_sec = TIMEOUT; 
  timeout.tv_sec = 10; 
  timeout.tv_usec = 0;
 
  retval = select(sock+1, &readfds, NULL, NULL, &timeout);
 
  if (retval) {
 
    nbRecu = send(sock, paquet, longueurPaquet, 0);
 
    printf("sendPaquet lg=%d send=%d\n",longueurPaquet,nbRecu);
 
    return nbRecu;
  }
  else {
    printf("sendPaquet ERREUR %d\n",retval);
    return -1;
 
  }
 
}

Les octets sont bien envoyés, mais immédiatement après le serveur coupe la communication. Je ne peux plus envoyer ou recevoir de données au serveur. Je voudrais verifier que la communication avec le serveur n'a pas été coupé avant d'envoyer.
Ceci afin de rendre le send non bloquant.
Est-ce comme celà que je dois proceder ?

**Emmanuel Delahaye** · 29/06/2006, 10h54

Envoyé par Zapan

J'ai fait la même chose pour la fonction recv

Je ne vois pas de recv()...

**Zapan** · 29/06/2006, 10h57

Envoyé par Emmanuel Delahaye

Je ne vois pas de recv()...

J'ai fais une faute. Je voulais dire : send() au lieu de recv()

**Emmanuel Delahaye** · 29/06/2006, 11h53

Envoyé par Zapan

J'ai fais une faute. Je voulais dire : send() au lieu de recv()

Et tu bloques avec select() sur la reception ? Etrange... Pourquoi as-tu besoin de select() pour l'émission ? send() est synchrone, il n'y a rien à faire de particulier. Tu fais send() et c'est tout.

http://emmanuel-delahaye.developpez.com/reseaux.htm

**Zapan** · 29/06/2006, 12h41

Non, maintenant je ne bloque pas sur le select.
J'utilise le select() pour etre sur que le serveur marche. Si il ne marche pas, mon programme essaye d'envoyé des données et reste bloqué.

**Zapan** · 29/06/2006, 15h22

Mon probléme est que le serveur peut planter. Lorsqu'il plante il entraine la fin de mon programme lorsque je fais un send. J'aimerais pourvoir gérer le cas ou le serveur plante.

**Emmanuel Delahaye** · 30/06/2006, 10h47

Envoyé par Zapan

Mon probléme est que le serveur peut planter. Lorsqu'il plante il entraine la fin de mon programme lorsque je fais un send. J'aimerais pourvoir gérer le cas ou le serveur plante.

EDIT Si tu es en mode connecté (TCP/IP), tu dois tester le compte rendu de send().

Si il fait -1, c'est qu'il ya une erreur dans errno. Les valeus possibles :

Envoyé par POSIX.1

ERRORS

The send() function shall fail if:

[EAGAIN] or [EWOULDBLOCK]
The socket's file descriptor is marked O_NONBLOCK and the requested operation would block.
[EBADF]
The socket argument is not a valid file descriptor.
[ECONNRESET]
A connection was forcibly closed by a peer.
[EDESTADDRREQ]
The socket is not connection-mode and no peer address is set.
[EINTR]
A signal interrupted send() before any data was transmitted.
[EMSGSIZE]
The message is too large to be sent all at once, as the socket requires.
[ENOTCONN]
The socket is not connected or otherwise has not had the peer pre-specified.
[ENOTSOCK]
The socket argument does not refer to a socket.
[EOPNOTSUPP]
The socket argument is associated with a socket that does not support one or more of the values set in flags.
[EPIPE]
The socket is shut down for writing, or the socket is connection-mode and is no longer connected. In the latter case, and if the socket is of type SOCK_STREAM, the SIGPIPE signal is generated to the calling thread.

The send() function may fail if:

[EACCES]
The calling process does not have the appropriate privileges.
[EIO]
An I/O error occurred while reading from or writing to the file system.
[ENETDOWN]
The local network interface used to reach the destination is down.
[ENETUNREACH]
No route to the network is present.
[ENOBUFS]
Insufficient resources were available in the system to perform the operation.

**joellel** · 30/06/2006, 10h47

Ben... Teste le code retour de tes fonctions et fais le traitement approprié...
Ton programme ne crashera plus

**Zapan** · 30/06/2006, 10h55

Envoyé par Emmanuel Delahaye

Si tu es en mode connecté (TCP/IP), tu peux surveiller le compte rendu du protocole avec le 4 ème paramètre de select() : exceptfds.

(je me renseigne pour les détails)

Je suis connecter en TCP/IP : sock = socket(AF_INET,SOCK_STREAM, 0);

**Emmanuel Delahaye** · 30/06/2006, 11h00

Envoyé par Zapan

Je suis connecter en TCP/IP : sock = socket(AF_INET,SOCK_STREAM, 0);

OK. J'ai modifié mon post...

**hush** · 30/06/2006, 16h10

Salut,

Essaye de mettre ton socket en mode non bloquant. Et rajoute l'option MSG_NOSIGNAL sur ton send.

Code :

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

1
2
3
4
5
6
 
nbRecu = send(sock, paquet, longueurPaquet, 0);
 
// Devient:
 
nbRecu = send(sock, paquet, longueurPaquet, MSG_NOSIGNAL);

Voici une fonction qui permettra de mettre, proprement, ton socket en mode non bloquant:

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
 
void set_nonblock(int sock) {
 
	int opts;
 
	if ((opts = fcntl(sock, F_GETFL)) < 0) {
		perror("fcntl(F_GETFL)");
	}
 
	opts = (opts | O_NONBLOCK);
 
	if (fcntl(sock, F_SETFL, opts) < 0) {
		perror("fcntl(F_SETFL)");
	}
}

Utilise cette fonction hors de tes fonctions d'envoi et de réception, par exemple après l'appel à connect() ou accept, bind, etc...

Pour ce qui est du test d'interruption de la connexion avec le serveur, tu peux faire une boucle infinie dans laquelle le select vérifie qu'il y a des données sur la socket en attente. Si il y en a, alors tu les récupères avec un recv() et s'il retourne -1 c'est que la connexion est rompue. Voilà j'espère que ça t'aidera, je n'ai pas fait de C depuis plus d'un an donc... à confirmer ;)

EDIT: Trois topics pour un même problème, tu abuses un peu quand même...

**Médinoc** · 30/06/2006, 16h42

MSG_NOSIGNAL ?
C'est un breaking change, de réclamer ce flag pour ne pas faire de crash!
Comment ont-il OSÉ ?

**hush** · 30/06/2006, 17h06

Propose une solution alors, et ne commente pas une seule partie du post, quit à critiquer fais le intelligemment et jusqu'au bout.
En général quand je critique c'est que je peux faire mieux... sinon je m'abstiens.

**Médinoc** · 30/06/2006, 17h09

Oh, mais ce n'est pas toi que je critique : Ce sont les développeurs de cette API.

Les serveurs UNIX sur lesquels je compilais autrement, ainsi Windows, ignorent jusqu'à l'existence de ce flag et retournent sagement -1...
(d'où mon post "mais ce n'est pas un crash, ça, c'est un échec et ça se traite gentiment" : j'ignorait également l'existence d'une telle connerie qui nie tout ce que j'aime dans le langage C et sa bibliothèque standard)

La fonction pourrait même retourner systématiquement -1 avec EINVAL si on met ce flag sur un système qui ne le connait pas...

Ce sont tous les nouveaux systèmes unixoïdes qui génèrent cette monstruosité par défaut en cas d'échec ?

**hush** · 30/06/2006, 17h48

Ok autant pour moi..

Si on utilise ce flag sur un système qui ne le connait pas, alors le programme ne se compilera pas, à moins qu'un header définisse la même constante quelque part, ce qui est peu probable.
Mais pour ce qui est de la portabilité, il y a de fortes chances pour que ce flag soit restreint aux systèmes UNIX like et *BSD (et encore). Une solution plus portable serait peut-être d'intercepter le signal SIGPIPE pour traiter le comportement du programme différemment.

**Emmanuel Delahaye** · 30/06/2006, 20h19

Envoyé par hush

EDIT: Trois topics pour un même problème, tu abuses un peu quand même...

Et dans plusieurs forums...

Socket, recv et select qui ne marche pas

Réseau C

Discussions similaires

Partager

Partager