il faut attendre quelques temps avant que tcp détecte la déconnexion je crois que c'est du genre 2 mins sous windows.
mais effectivement, si on patiente, la fonction retourne bien en erreur.
"Vincent" a écrit dans le message de news:cftm5m$r3i$
Attention en TCP, il peut y avoir des timeouts assez long de détection de déconnexion (j'ai déjàconstaté, pas défaut, plusieurs minutes sur
certains
OS)
"David MAREC" wrote in message news:4122315f$0$22039$ > D'après Manuel Leclerc: > > >> Dans un fil d'exécution, j'utilise la fonction bloquante > >> de winsock : recv() en mode STREAM, TCP. > >> > >> iInCount = recv(skSensor, (char FAR *)inBuffSensor,wNb, 0); > >> > >> Or, si l'appareil distant tombe, (i.e débranché), cette fonction > >> reste bloquée. > > > Il y a une bug quelque part. En TCP, je crois que recv doit > > retourner si l'autre extrémité n'est plus là. > > C'est ce que je crains, si je traduis bien la doc de «recv()» il devrait > sortir avec une erreur, ce que j'ai prévu, sans jamais le voir. > Sauf quand je débranche le cable Ethernet du coté de mon application. > > A moins que le fait d'avoir plusieur fils similaires sur des «socket» > différentes (même port, mais IP différente) soit pénalisant ? > > > C'est du Windows > > à l'autre bout aussi ? > > Beh non. C'est un appareil de mesure. >
je confirme ce que tu dis.
il faut attendre quelques temps avant que tcp détecte la déconnexion
je crois que c'est du genre 2 mins sous windows.
mais effectivement, si on patiente, la fonction retourne bien en erreur.
"Vincent" <NS_vincent.alex@9online.fr> a écrit dans le message de
news:cftm5m$r3i$1@apollon.grec.isp.9tel.net...
Attention en TCP, il peut y avoir des timeouts assez long de détection de
déconnexion (j'ai déjàconstaté, pas défaut, plusieurs minutes sur
certains
OS)
"David MAREC" <dmarec.spam@spambox.invalid> wrote in message
news:4122315f$0$22039$626a14ce@news.free.fr...
> D'après Manuel Leclerc:
>
> >> Dans un fil d'exécution, j'utilise la fonction bloquante
> >> de winsock : recv() en mode STREAM, TCP.
> >>
> >> iInCount = recv(skSensor, (char FAR *)inBuffSensor,wNb, 0);
> >>
> >> Or, si l'appareil distant tombe, (i.e débranché), cette fonction
> >> reste bloquée.
>
> > Il y a une bug quelque part. En TCP, je crois que recv doit
> > retourner si l'autre extrémité n'est plus là.
>
> C'est ce que je crains, si je traduis bien la doc de «recv()» il devrait
> sortir avec une erreur, ce que j'ai prévu, sans jamais le voir.
> Sauf quand je débranche le cable Ethernet du coté de mon application.
>
> A moins que le fait d'avoir plusieur fils similaires sur des «socket»
> différentes (même port, mais IP différente) soit pénalisant ?
>
> > C'est du Windows
> > à l'autre bout aussi ?
>
> Beh non. C'est un appareil de mesure.
>
il faut attendre quelques temps avant que tcp détecte la déconnexion je crois que c'est du genre 2 mins sous windows.
mais effectivement, si on patiente, la fonction retourne bien en erreur.
"Vincent" a écrit dans le message de news:cftm5m$r3i$
Attention en TCP, il peut y avoir des timeouts assez long de détection de déconnexion (j'ai déjàconstaté, pas défaut, plusieurs minutes sur
certains
OS)
"David MAREC" wrote in message news:4122315f$0$22039$ > D'après Manuel Leclerc: > > >> Dans un fil d'exécution, j'utilise la fonction bloquante > >> de winsock : recv() en mode STREAM, TCP. > >> > >> iInCount = recv(skSensor, (char FAR *)inBuffSensor,wNb, 0); > >> > >> Or, si l'appareil distant tombe, (i.e débranché), cette fonction > >> reste bloquée. > > > Il y a une bug quelque part. En TCP, je crois que recv doit > > retourner si l'autre extrémité n'est plus là. > > C'est ce que je crains, si je traduis bien la doc de «recv()» il devrait > sortir avec une erreur, ce que j'ai prévu, sans jamais le voir. > Sauf quand je débranche le cable Ethernet du coté de mon application. > > A moins que le fait d'avoir plusieur fils similaires sur des «socket» > différentes (même port, mais IP différente) soit pénalisant ? > > > C'est du Windows > > à l'autre bout aussi ? > > Beh non. C'est un appareil de mesure. >
David MAREC
D'après Manuel Leclerc:
[Pas de détection de deconnexion d'un appareil distant] Je viens de lire les autres réponses qu'on t'a faites. Il semble qu'il y ait un possible problème de time-out quand divers équipement séparent les deux cartes réseaux, mais je trouve ça surprenant qu'on puisse se retrouver bloqué "indéfiniment"... Si quelqu'un connait une URL expliquant comment une extrémité TCP est "prévenue" qu'il n'y a plus personne à l'autre bout, ça m'intéresse.
Itou. Je fais donc suivre sur le forum idoine.
D'après Manuel Leclerc:
[Pas de détection de deconnexion d'un appareil distant]
Je viens de lire les autres réponses qu'on t'a faites. Il
semble qu'il y ait un possible problème de time-out quand
divers équipement séparent les deux cartes réseaux, mais je
trouve ça surprenant qu'on puisse se retrouver bloqué
"indéfiniment"... Si quelqu'un connait une URL expliquant
comment une extrémité TCP est "prévenue" qu'il n'y a plus
personne à l'autre bout, ça m'intéresse.
[Pas de détection de deconnexion d'un appareil distant] Je viens de lire les autres réponses qu'on t'a faites. Il semble qu'il y ait un possible problème de time-out quand divers équipement séparent les deux cartes réseaux, mais je trouve ça surprenant qu'on puisse se retrouver bloqué "indéfiniment"... Si quelqu'un connait une URL expliquant comment une extrémité TCP est "prévenue" qu'il n'y a plus personne à l'autre bout, ça m'intéresse.
