[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
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
A voir également:
- [C] [Socket] Temps limite d'un connect()
- Créer un compte france connect ameli - Guide
- Blocage agriculteur carte en temps réel - Guide
- Renommer plusieurs fichiers en même temps - Guide
- Se connecter à un autre compte facebook - Guide
- Comment connecter un chromecast - Guide
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
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.
A+, bon courage, crabs
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
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
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
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
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
21 oct. 2005 à 12:32
Merci crabs, je regarde tout ça ce soir :-)
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
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.
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.
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
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 :-)
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 :-)