probleme socket C [deconnect-reconnect]

salut a tous , je vous expose mon problème donc
:cry:
j'ai connecté mon socket .

Code:

---

1 2 3 4 5

.... monsock = socket(AF_INET,SOCK_STREAM,0);   connect(monsock , (SOCKADDR*)&configsock, sizeof(configsock)); .....

---

et dans un while(1) ; beaucoup de commandes et des threads sont mises en place . dont =

Code:

---

1 2 3

..... while( recv(monsock ,bufferirc , sizeof(bufferirc),0 ) < 0 ) .....

---

qui me sert a voir quand le SOCKET est déconnecté mais il bug beaucoup et fonctionne pas correctement car il pose problème au 1er while .

Mes questions =
- y'a t'il un moyen autre de vérifier la déconnection d'un socket ? si oui lequel?
- y'a t-il en C socket une fonction qui le gere automatiquement genre ( disconnectsocket() ) ? si oui syntaxe sil vous plait
- autre méthode /organisation de mon code ?


Ps : quand je dit deconnection + reconnection , c'est si la connection est rompu , le socket après un Sleep se reconnect automatiquement bien sure ( closesocket(); socket(); connect() ; ... ec etc )

merci

Regarde du côté de la fonction select, ça va beaucoup t'aider. Et ça t'évitera d'avoir plein de threads dans ton programme. Sache toutefois que sous Windows, select ne peut être utilisée qu'avec des sockets et seulement des sockets. Sous Linux elle peut-être utilisée avec des fichiers aussi.

ok merci mais quand j'utilise le select() sa sera sur la condition de deconnection ou sur le sock qui recv() < 0; ??
je sélectionne quoi ?
( pas compris le principe désolé )

Bonjour,

De mémoire le select est bloquant est regroupe les différentes socket sur lequel nous pouvons lire, dans un petit tableau.
Lorsque le select est débloqué, c'est qu'il y a eu de l'activité sur un des sockets que l'on surveille.

De mémoire, lorsqu'une socket est deconnecté, on reçoit un 0 dessus ... donc le select va l'indiquer, car il va être débloqué puis va recevoir le 0 avec recv ... et donc on sait qu'il y a un problème.

c est toujours autant bloqué avec select()

Code:

---

1 2 3 4

if( select(monsock + 1, NULL, NULL, &exceptfds, NULL) == 0 ) { if( recv(monsock ,bufferirc , sizeof(bufferirc),0 ) < 0 ) { .....

---

avec un exceptfds bloquante mon rcv() , un readfds

me donne le meme probleme comme si j'avais pas utilisé de select() :s:s:s

select est toujours bloquant.
Pour le débloquer, il faut recevoir des données sur les sockets.

De plus, j'oserais dire que vous l'utilisez mal, car vous devriez passer des valeurs en 2ième argument ... enfin je pense.

Citation:

---

Envoyé par LittleWhite

select est toujours bloquant.

---

:nono:, on peut spécifier un timeout : man select

Citation:

---

Envoyé par ram-0000

:nono:, on peut spécifier un timeout : man select

---

Oui :oops::oops:

Mais de la cas de l'utilisateur actuel, il n'a pas mis de timeout (j'essaie de me rattraper :aie:)

merci de vos réponses , mais elle ne sont que théoriques ( concerne la fonction selection et non mon probleme ) :(

Pratiquement, gérer l'ensemble des cas est relativement complexe (le socket peut être gelé, le client (ou le serveur) peut être interrompu, etc etc)..

En pratique, ce que je fait est (mais moi j'utilise des sockets asynchrones) :

• utiliser un "poll" (sous unixoides, un WSApoll sous Windows) pour savoir si le socket est toujours "vvant" avant de faire une lecture ou écriture
  
  
• utliser le signal handler pour gérer les signaux "généraux" (SIGTERM, SIGHUP, SIGQUIT, SIGKILL, SIGINT..)
  
  
• utiliser un timer et aller vérifier toutes les X secondes l'état (via le poll) de "vie"..

Maintenant, avec un socket bloquant, la question du timer disparait.

Par contre, avant toute écriture ou lecture les "polls" doivent être effectués (car ils ne crashent pas alors que recv ou send crashent)


Il y a une fonction shutdown..

Pour info, sous unixoide ma routine de vérifcation est la suivante :

Code:

---

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

/*  * C h e c k s _ C o m m u n i c a t i o n  *  */ static int Checks_Communication ( void ) { int s, ncar_a_lire, ss ; struct pollfd fds[2] ;   fds[0].events = POLLOUT ; fds[1].events = POLLIN ;   /* --- Assigns the values for the server to be checked */ fds[0].fd = Canal_Out ; fds[1].fd = Canal_In ;   /* --- Checks the state of the connection */ s = poll (fds, 2, 200 );   /* --- Either if failed (busy, frozen, error, or client hangup) */ if ( (s <= 0) || (fds[0].revents & POLLERR) || (fds[1].revents & POLLERR) ) { if ( s <= 0 ) s = INFO ; else s = WARNING ; } else if ( (fds[1].revents & POLLHUP)|| (fds[0].revents & POLLHUP) || (fds[1].revents & POLLNVAL)|| (fds[0].revents & POLLNVAL) ) s = ERROR ; else { /* Otherwise it is ok to try and write on it */   ss = ioctl(fds[1].fd, FIONREAD, &ncar_a_lire); if ( (ncar_a_lire == 0) && (ss >= 0) && (s == 2) && (fds[1].revents & POLLIN) ) s = ERROR ; else s = SUCCESS ; }   return (s); }

---

et je m'en sers comme :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13

if ( (i = Checks_Communication ()) == SUCCESS ) { s = send.... (..); } else { if ( (i == ERROR) || (i == WARNING) ) { fprintf (stderr, "\nCLIENT SHUTDOWN THE COMM. SO COULD NOT WRITE !!!");   End_Of_Session(2) ; } }

---

Maintenant, pour les signaux, je fais :

Code:

---

1 2 3 4 5 6

signal(SIGKILL,(void (*)())End_Of_Session); signal(SIGTERM,(void (*)())End_Of_Session); signal(SIGQUIT,(void (*)())End_Of_Session); signal(SIGPIPE,(void (*)())End_Of_Session); signal(SIGSTOP,(void (*)())End_Of_Session); signal(SIGHUP,(void (*)())End_Of_Session);

---

et

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

static void End_Of_Session ( int sig ) { char Cmd[40] ; int pid, i, s ;     /* --- Disconnect the sockets */ shutdown(Canal_In ,2); close(Canal_In); shutdown(Canal_Out ,2); close(Canal_Out);   /* --- Kills and deconnect actual server */ pid = getpid(); sprintf ( Cmd, "kill -9 %d",pid); pid = system(Cmd); exit(0); }

---

merci pour l'aide , ta méthode à est bien complexe je vais l'étudier au moins pour utiliser le poll() déjà car je pense qu'elle pourra résoudre mon soucis .


Il y a une fonction shutdown.. = c'est a dire ? je sais qu'elle est utiliser pour déconnecté une socket mais dans ton sens , vous voulez dire quoi ?

Citation:

---

Envoyé par Shark9

merci pour l'aide , ta méthode à est bien complexe

---

J'ai bien précisé au début qu'avoir des tests propres et complets des cas de déconnexion n'était pas simple...

Citation:

---

Envoyé par Shark9

Il y a une fonction shutdown.. = c'est a dire ? je sais qu'elle est utiliser pour déconnecté une socket mais dans ton sens , vous voulez dire quoi ?

---

http://man.developpez.com/man2/shutdown.2.php

ok donc le tout est de d'abord définir l'état du socket avant de faire quoi que se soit ok pour moi c est WSAPOLL vue que c est sur win que je code.

Bonjour,

@souviron34: A quoi correspondent les constantes INFO, WARNING, ... ?

Merci :)

Citation:

---

Envoyé par Gaspoute

@souviron34: A quoi correspondent les constantes INFO, WARNING, ... ?

---

bah, juste à donner des indications pour les messages - et/ou les logfile et/ou le type de fenêtre de messages - à afficher en fonction de la gravité :

• gravité nulle : c'est une info, un message sans aucune conséquence, juste par exemple sur l'avancement d'une tâche, ..
• gravité un peu plus forte : warning : quelque chose s'est mal passé, mais le soft peut continuer. Mais on peut vouloir le signaler.
• gravité plus lourde : error : quelque chose s'est très mal passé, n'empêche pas le fonctionnnement de l'ensemble du sof, mais empêche le fonctionnement de cette fonctionalité. Il faut le signaler.
• gravité encore plus lourde : fatal error : quelque chose s'est très très mal passé et empêche le soft dans son ensemble de fonctionner.

Normalement, aucun cas de fatal error ne doit jamais pouvoir être mis.. Donc normalement FATAL_ERROR ne doit jamais figurer dans le code, uniquement dans les définitions.

Un système sûr se doit de pouvoir récupérer sans planter, quiitte à ne pas disposer (même si c'est temporairement) de toutes les fonctionalités.

donc par exemple :

Code:

---

1 2 3 4 5

#define SUCCESS 1 #define INFO 0 #define WARNING -1 #define ERROR -2 #define FATAL_ERROR -2

---

On chosiit en général SUCCESS comme 1 pour faciliter les tests par analogie avec les booléens (et être commun avec le mécansisme de retour de main):

Code:

---

if ( Fonction(..) == SUCCESS )

---

qu'on pourrait (mais ce n'est pas le cas parce que c'est un int) écrire

Code:

---

if ( Fonction(..) )

---

Après ça dépend, on peut faire le contraire :

Code:

---

1 2 3 4 5

#define SUCCESS 0 #define INFO 1 #define WARNING 2 #define ERROR 3 #define FATAL_ERROR 4

---

mais à ce compte-là il faut systématiquement tester et ne jamais penser à l'analogie booléenne..

Sinon on peut aussi catégoriser juste succès et erreur, et voir les autres comme des sous-catégories de ERROR :

Code:

---

1 2 3 4 5 6

#define SUCCESS 0 #define ERROR 1 #define INFO 2 #define WARNING 3 #define NORMAL_ERROR 4 #define FATAL_ERROR 5

---