[C] [Socket] Temps limite d'un connect()

Résolu/Fermé
kilian Messages postés 8731 Date d'inscription vendredi 19 septembre 2003 Statut Modérateur Dernière intervention 20 août 2016 - 21 oct. 2005 à 02:16
kilian Messages postés 8731 Date d'inscription vendredi 19 septembre 2003 Statut Modérateur Dernière intervention 20 août 2016 - 22 oct. 2005 à 04:50
Bonsoir,

Alors voilà mon soucis,
J'ai un socket qui se connecte en tcp sur une machine distante mais au moment où la fonction connect() s'execute, le programme est en attente et la suite ne s'execute pas avant quelques minutes.

Mais tout ce que j'aimerais faire c'est lancer une tentative de connexion. Que ça réussise ou non, ça importe peu. Donc est ce qu'il est possible de fixer un temps limite pour la connexion?

J'ai pensé à lancer le connect() dans un thread mais il y a peut être d'autres solutions moins lourdes....

5 réponses

crabs Messages postés 908 Date d'inscription lundi 18 avril 2005 Statut Membre Dernière intervention 3 août 2008 506
21 oct. 2005 à 08:38
Salut,
Tu peux passer par via la gestion signal alarm et l'utilisation de setjmp/longjmp
Si la résolution de ton timeout est la seconde regardes du coté de alarm,
si tu cherches la milliseconde, regarde du coté de setitimer.
Le problème de connect c'est qu'il est 'restartable' dans la reception des
signaux, donc il faut utiliser setjmp/longjump.
Je te files un code C qui permettait de faire ce genre de truc.
#include <sys/types.h>
#include <sys/socket.h>
#include <netdb.h>
#include <netinet/in.h>
#include <errno.h>
#include <stdio.h>
#include <string.h>
#include <unistd.h>
#include <signal.h>
#include <setjmp.h>

jmp_buf timeout_jump ;
void timeout(int sig)
    {
    printf( "signal %d occurs\n", sig ) ;
    longjmp( timeout_jump, 1 ) ;
    }
/***
**** timeout serveur port timeout
**** Attention pas de verification de la ligne de commande
**** le process retourne :
****   - 0 : tout est ok
****   - 1 : erreur systeme
****   - 2 : timeout
***/
int main( int argc, char** argv )
    {
    int fd, ret ;
    struct sockaddr_in sin ;
    struct hostent* host ;
    struct servent* sp  ;

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

    host = gethostbyname( argv[1] ) ;
    if ( !host ) { perror( "gethostbyname" ) ; return 1 ; }

    sp = getservbyname( argv[2], "tcp" ) ;
    if ( !sp ) { perror( "getservbyname" ) ; return 1 ; }

    sin.sin_port = sp->s_port ;
    memcpy( &(sin.sin_addr.s_addr), (char *)host->h_addr, host->h_length ) ;
    sin.sin_family = AF_INET ;

    // on arme le timeout
    signal( SIGALRM, timeout ) ;
    alarm( atoi(argv[3] ) ;
    if ( setjmp( timeout_jump ) == 1 ) // c'est un timeout
        {
        printf( "C'est un timeout\n" ) ;
        close(fd) ;
        return 2 ;
        }
    else
        {
        ret = connect(fd,(struct sockaddr *)&sin,sizeof(struct sockaddr_in)) ;
        if ( ret == -1 )
            {
            perror( "connect()" ) ;
            alarm(0) ;
            close(fd) ;
            return 1 ;
            }
        }
    alarm(0) ;
    close( fd ) ;
    return 0 ;
    }


A+, bon courage, crabs
4
crabs Messages postés 908 Date d'inscription lundi 18 avril 2005 Statut Membre Dernière intervention 3 août 2008 506
21 oct. 2005 à 21:24
Salut,

Etat SYN_SENT : la demande de connection est partie, le socket est
alors en attente de réponse (ACK).
Il peut y avoir 4 raisons :
- le système ne sait pas atteindre la machine distante, ça arrive souvent quand
on demande une adresse privé en s'adressant à une passerelle publique sans
tunneling
- le système ne sait pas répondre au serveur : il ne connait pas la route pour
assurer le retour de la réponse, ça arrive souvent si la machine locale à une
adresse privée et qu'elle n'est pas derrière une masquarade, ou alors la
machine distante est mal configurée pour le routage.
- le système distant fait un DROP du paquet ou tout dispositif de type firewall
entre la machine locale et la machine distante.
- la machine locale fait un DROP sur la réponse ou tout dispositif de type
firewall entre la machine distante et la machine locale permettant d'assurer
le retour de la réponse

Des outils de types ethereal ou iptraf peuvent te donner plus d'info sur la
raison de la non-réponse.
A+, crabs
1
kilian Messages postés 8731 Date d'inscription vendredi 19 septembre 2003 Statut Modérateur Dernière intervention 20 août 2016 1 527
21 oct. 2005 à 12:32
Merci crabs, je regarde tout ça ce soir :-)
0
kilian Messages postés 8731 Date d'inscription vendredi 19 septembre 2003 Statut Modérateur Dernière intervention 20 août 2016 1 527
21 oct. 2005 à 21:05
Ok j'ai enfin compris le système des setjmp et longjmp combinés avec alarm.

Merci beaucoup pour le code :-)
Au fait c'est normal que lorsque mon socket se connecte à un port sur une adresse (avec connect() ), l'application reste en attente comme ça?
Ca me fait ça que le port soit masqué ou en écoute.....

Avec netstat j'ai ce statut affiché: SYN_SENT
Et ça n'évolue pas.
En gros je n'ai pas de réponse de l'application serveur (testé avec postfix et vsftpd).... Et ce n'est pas un soucis de Firewall...

C'est la première fois que j'utilise les sockets.
0

Vous n’avez pas trouvé la réponse que vous recherchez ?

Posez votre question
kilian Messages postés 8731 Date d'inscription vendredi 19 septembre 2003 Statut Modérateur Dernière intervention 20 août 2016 1 527
22 oct. 2005 à 04:50
Ok je crois avoir trouvé finalement.

J'étais sûr de mes règles de firewall mais en fait....tu as raison mon firewall fait un DROP.
En fait j'essayais de me connecter depuis mon adresse publique sur mon adresse publique (même source et destination).
Je ne sais pas pourquoi mais mon firewall n'accepte probablement pas la réponse (ou la demande...).

Bon ben c'est réglé... Merci pour tout :-)
0