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.
Comment la terminer (avec une erreur) ?
Sachant que je n'ai pas de fenêtre associé à ce code, je ne peux donc pas utiliser les sockets asynchrones et le mode "bloqué" m'arrange bien.
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 du Windows à l'autre bout aussi ?
--
> DES FOUS. DES PORCS SAUVAGES FOUS ! Calmévoo.
NON ! ILS M'ONT BOUFFE MES TUYAUX !
David MAREC
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.
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 ?
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.
Vincent
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.
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 ?
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.
Thierry
Bonjour,
David MAREC a écrit :
Or, si l'appareil distant tombe, (i.e débranché), cette fonction reste bloquée.
T'es connecté en direct ou via un hub ? Si tu passes par un hub, c'est normal puisque la carte réseau reste branchée donc pas de detection de deconnexion possible (ou s'il existe un mécanisme de detection via TCP/IP (cf WSAECONNRESET) y'aura toujours un moment de latence (timeout)). Si t'es en direct alors Windows devrait detecter la perte de connexion physique et fermer les sockets et read devrait renvoyer WSAECONNABORTED ou WSAECONNRESET. MAis comme disait Vincent la detection peut être assez longue.
-- « Always look at the bright side of the life... »
Bonjour,
David MAREC a écrit :
Or, si l'appareil distant tombe, (i.e débranché), cette fonction reste
bloquée.
T'es connecté en direct ou via un hub ?
Si tu passes par un hub, c'est normal puisque la carte réseau reste
branchée donc pas de detection de deconnexion possible (ou s'il existe un
mécanisme de detection via TCP/IP (cf WSAECONNRESET) y'aura toujours un
moment de latence (timeout)).
Si t'es en direct alors Windows devrait detecter la perte de connexion
physique et fermer les sockets et read devrait renvoyer WSAECONNABORTED ou
WSAECONNRESET. MAis comme disait Vincent la detection peut être assez
longue.
--
« Always look at the bright side of the life... »
Or, si l'appareil distant tombe, (i.e débranché), cette fonction reste bloquée.
T'es connecté en direct ou via un hub ? Si tu passes par un hub, c'est normal puisque la carte réseau reste branchée donc pas de detection de deconnexion possible (ou s'il existe un mécanisme de detection via TCP/IP (cf WSAECONNRESET) y'aura toujours un moment de latence (timeout)). Si t'es en direct alors Windows devrait detecter la perte de connexion physique et fermer les sockets et read devrait renvoyer WSAECONNABORTED ou WSAECONNRESET. MAis comme disait Vincent la detection peut être assez longue.
-- « Always look at the bright side of the life... »
Manuel Leclerc
David MAREC a écrit :
D'après Manuel Leclerc:
> 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.
recv peux aussi retourner 0. C'est prévu dans ton programme ?
A moins que le fait d'avoir plusieurs fils similaires sur des «socket» différentes (même port, mais IP différente) soit pénalisant ?
Ca m'étonnerait. C'est quand même une situation assez banale.
> C'est du Windows à l'autre bout aussi ?
Beh non. C'est un appareil de mesure.
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.
Personellement, quand je n'utilise pas les mécanismes WSA (messages postés), et que la socket est en mode bloquant, je fais toujours un "select" FD_READ avec time-out avant de faire un recv. Mais si le cable est débranché "entre" le moment du select et celui du recv, ma solution est peut être foireuse. Faudrait alors se résoudre à passer en non-bloquant.
-- The C programming language is best described as a hardware-independent assembler language. --Joël Spolsky
David MAREC a écrit :
D'après Manuel Leclerc:
> 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.
recv peux aussi retourner 0. C'est prévu dans ton programme ?
A moins que le fait d'avoir plusieurs fils similaires sur
des «socket» différentes (même port, mais IP différente)
soit pénalisant ?
Ca m'étonnerait. C'est quand même une situation assez banale.
> C'est du Windows à l'autre bout aussi ?
Beh non. C'est un appareil de mesure.
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.
Personellement, quand je n'utilise pas les mécanismes WSA
(messages postés), et que la socket est en mode bloquant,
je fais toujours un "select" FD_READ avec time-out avant de
faire un recv. Mais si le cable est débranché "entre" le moment
du select et celui du recv, ma solution est peut être foireuse.
Faudrait alors se résoudre à passer en non-bloquant.
--
The C programming language is best described as a hardware-independent
assembler language.
--Joël Spolsky
> 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.
recv peux aussi retourner 0. C'est prévu dans ton programme ?
A moins que le fait d'avoir plusieurs fils similaires sur des «socket» différentes (même port, mais IP différente) soit pénalisant ?
Ca m'étonnerait. C'est quand même une situation assez banale.
> C'est du Windows à l'autre bout aussi ?
Beh non. C'est un appareil de mesure.
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.
Personellement, quand je n'utilise pas les mécanismes WSA (messages postés), et que la socket est en mode bloquant, je fais toujours un "select" FD_READ avec time-out avant de faire un recv. Mais si le cable est débranché "entre" le moment du select et celui du recv, ma solution est peut être foireuse. Faudrait alors se résoudre à passer en non-bloquant.
-- The C programming language is best described as a hardware-independent assembler language. --Joël Spolsky
David MAREC
Salut à vous !
Manuel Leclerc disait:
recv peux aussi retourner 0. C'est prévu dans ton programme ?
Oui.
C'est du Windows à l'autre bout aussi ?
Beh non. C'est un appareil de mesure.
Je viens de lire les autres réponses qu'on t'a faites.
...Et pour répondre à Thierry, oui, au minimum, il y a un HUB ou un SWITCH entre le PéCé qui fait l'acquisition et les appareils de mesure.
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"...
Ca m'a surpris aussi, :-).
Personellement, quand je n'utilise pas les mécanismes WSA (messages postés), et que la socket est en mode bloquant, je fais toujours un "select" FD_READ avec time-out avant de faire un recv.
Oui, c'est une solution, déconseillée pourtant par Microsoft, si j'ai bien tout lu, sauf que l'appareil en question n'est pas tenu de me causer à intervalles réguliers.
Salut à vous !
Manuel Leclerc disait:
recv peux aussi retourner 0. C'est prévu dans ton programme ?
Oui.
C'est du Windows à l'autre bout aussi ?
Beh non. C'est un appareil de mesure.
Je viens de lire les autres réponses qu'on t'a faites.
...Et pour répondre à Thierry, oui, au minimum, il y a un HUB ou un
SWITCH entre le PéCé qui fait l'acquisition et les appareils de mesure.
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"...
Ca m'a surpris aussi, :-).
Personellement, quand je n'utilise pas les mécanismes WSA
(messages postés), et que la socket est en mode bloquant,
je fais toujours un "select" FD_READ avec time-out avant de
faire un recv.
Oui, c'est une solution, déconseillée pourtant par Microsoft, si j'ai
bien tout lu, sauf que l'appareil en question n'est pas tenu de me
causer à intervalles réguliers.
recv peux aussi retourner 0. C'est prévu dans ton programme ?
Oui.
C'est du Windows à l'autre bout aussi ?
Beh non. C'est un appareil de mesure.
Je viens de lire les autres réponses qu'on t'a faites.
...Et pour répondre à Thierry, oui, au minimum, il y a un HUB ou un SWITCH entre le PéCé qui fait l'acquisition et les appareils de mesure.
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"...
Ca m'a surpris aussi, :-).
Personellement, quand je n'utilise pas les mécanismes WSA (messages postés), et que la socket est en mode bloquant, je fais toujours un "select" FD_READ avec time-out avant de faire un recv.
Oui, c'est une solution, déconseillée pourtant par Microsoft, si j'ai bien tout lu, sauf que l'appareil en question n'est pas tenu de me causer à intervalles réguliers.
Dominique Vaufreydaz
Bonjour,
Oui, c'est une solution, déconseillée pourtant par Microsoft, si j'ai bien tout lu, sauf que l'appareil en question n'est pas tenu de me causer à intervalles réguliers.
Toi, peux-tu lui causer ? Meme si il n'est pas cense repondre ! La question est : peux-tu lui envoyer des données sans que ca perturbe sont fonctionnement ? Si oui, tu pourrais avoir un interet a envoyer a chaque fois des données pour declencher la detection de perte de connexion...
A voir. Doms. -- Impose ta chance, serre ton bonheur et va vers ton risque. A te regarder, ils s'habitueront. René Char, Les Matinaux. ---- http://Dominique.Vaufreydaz.free.fr/ http://TitchKaRa.free.fr/ http://logiciels.ntfaqfr.com/
Bonjour,
Oui, c'est une solution, déconseillée pourtant par Microsoft, si j'ai
bien tout lu, sauf que l'appareil en question n'est pas tenu de me
causer à intervalles réguliers.
Toi, peux-tu lui causer ? Meme si il n'est pas cense repondre ! La question est : peux-tu lui envoyer des données sans que ca
perturbe sont fonctionnement ? Si oui, tu pourrais avoir un interet a envoyer a chaque fois des données pour declencher la
detection de perte de connexion...
A voir. Doms.
--
Impose ta chance, serre ton bonheur et va vers ton risque.
A te regarder, ils s'habitueront.
René Char, Les Matinaux.
----
http://Dominique.Vaufreydaz.free.fr/
http://TitchKaRa.free.fr/
http://logiciels.ntfaqfr.com/
Oui, c'est une solution, déconseillée pourtant par Microsoft, si j'ai bien tout lu, sauf que l'appareil en question n'est pas tenu de me causer à intervalles réguliers.
Toi, peux-tu lui causer ? Meme si il n'est pas cense repondre ! La question est : peux-tu lui envoyer des données sans que ca perturbe sont fonctionnement ? Si oui, tu pourrais avoir un interet a envoyer a chaque fois des données pour declencher la detection de perte de connexion...
A voir. Doms. -- Impose ta chance, serre ton bonheur et va vers ton risque. A te regarder, ils s'habitueront. René Char, Les Matinaux. ---- http://Dominique.Vaufreydaz.free.fr/ http://TitchKaRa.free.fr/ http://logiciels.ntfaqfr.com/
David MAREC
D'après Dominique Vaufreydaz :
Toi, peux-tu lui causer ? Meme si il n'est pas cense repondre ! La question est : peux-tu lui envoyer des données sans que ca perturbe sont fonctionnement ? Si oui, tu pourrais avoir un interet a envoyer a chaque fois des données pour declencher la detection de perte de connexion...
Ah oui. Tiens. Il faut que j'essaie ça.
D'après Dominique Vaufreydaz :
Toi, peux-tu lui causer ? Meme si il n'est pas cense repondre ! La question est : peux-tu lui envoyer des données sans que ca
perturbe sont fonctionnement ? Si oui, tu pourrais avoir un interet a envoyer a chaque fois des données pour declencher la
detection de perte de connexion...
Toi, peux-tu lui causer ? Meme si il n'est pas cense repondre ! La question est : peux-tu lui envoyer des données sans que ca perturbe sont fonctionnement ? Si oui, tu pourrais avoir un interet a envoyer a chaque fois des données pour declencher la detection de perte de connexion...
Ah oui. Tiens. Il faut que j'essaie ça.
Thierry
Bonjour,
David MAREC a écrit :
Ah oui. Tiens. Il faut que j'essaie ça.
Rien qu'un ping suffit, si le matos en face le supporte.
-- « Always look at the bright side of the life... »
Bonjour,
David MAREC a écrit :
Ah oui. Tiens.
Il faut que j'essaie ça.
Rien qu'un ping suffit, si le matos en face le supporte.
--
« Always look at the bright side of the life... »
Rien qu'un ping suffit, si le matos en face le supporte.
-- « Always look at the bright side of the life... »
Dominique Vaufreydaz
Re,
Rien qu'un ping suffit, si le matos en face le supporte.
ping c'est du ICMP. Donc en ligne de commande, oui, mais la dans son programme, je sais pas si un ping (interne ou externe) aurait le meme effet. C'est toujours testable.
Doms.
-- Impose ta chance, serre ton bonheur et va vers ton risque. A te regarder, ils s'habitueront. René Char, Les Matinaux. ---- http://Dominique.Vaufreydaz.free.fr/ http://TitchKaRa.free.fr/ http://logiciels.ntfaqfr.com/
Re,
Rien qu'un ping suffit, si le matos en face le supporte.
ping c'est du ICMP. Donc en ligne de commande, oui, mais la dans son
programme, je sais pas si un ping (interne ou externe) aurait le meme
effet. C'est toujours testable.
Doms.
--
Impose ta chance, serre ton bonheur et va vers ton risque.
A te regarder, ils s'habitueront.
René Char, Les Matinaux.
----
http://Dominique.Vaufreydaz.free.fr/
http://TitchKaRa.free.fr/
http://logiciels.ntfaqfr.com/
Rien qu'un ping suffit, si le matos en face le supporte.
ping c'est du ICMP. Donc en ligne de commande, oui, mais la dans son programme, je sais pas si un ping (interne ou externe) aurait le meme effet. C'est toujours testable.
Doms.
-- Impose ta chance, serre ton bonheur et va vers ton risque. A te regarder, ils s'habitueront. René Char, Les Matinaux. ---- http://Dominique.Vaufreydaz.free.fr/ http://TitchKaRa.free.fr/ http://logiciels.ntfaqfr.com/
