[C] [Socket] Temps limite d'un connect()
Résolu/Fermé
kilian
kilian
- Messages postés
- 8731
- Date d'inscription
- vendredi 19 septembre 2003
- Statut
- Modérateur
- Dernière intervention
- 20 août 2016
kilian
- Messages postés
- 8731
- Date d'inscription
- vendredi 19 septembre 2003
- Statut
- Modérateur
- Dernière intervention
- 20 août 2016
A voir également:
- [C] [Socket] Temps limite d'un connect()
- [C] [Socket] Temps limite d'un connect() ✓ - Forum - C
- Thunderbird temps limite de connexion au serveur dépassé ✓ - Forum - Gestion du temps
- Temps limite de connexion au serveur imap.sfr.fr dépassé ✓ - Forum - Thunderbird
- Temps de connexion dépassé sur Thunderbird - Forum - Thunderbird
- Temps limite de connexion au serveur dépassé thunderbird ✓ - Forum - Thunderbird
5 réponses
crabs
21 oct. 2005 à 08:38
- Messages postés
- 908
- Date d'inscription
- lundi 18 avril 2005
- Statut
- Membre
- Dernière intervention
- 3 août 2008
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
21 oct. 2005 à 21:24
- Messages postés
- 908
- Date d'inscription
- lundi 18 avril 2005
- Statut
- Membre
- Dernière intervention
- 3 août 2008
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
21 oct. 2005 à 12:32
- Messages postés
- 8731
- Date d'inscription
- vendredi 19 septembre 2003
- Statut
- Modérateur
- Dernière intervention
- 20 août 2016
21 oct. 2005 à 12:32
Merci crabs, je regarde tout ça ce soir :-)
kilian
21 oct. 2005 à 21:05
- Messages postés
- 8731
- Date d'inscription
- vendredi 19 septembre 2003
- Statut
- Modérateur
- Dernière intervention
- 20 août 2016
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
22 oct. 2005 à 04:50
- 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
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 :-)