Sockets avec dll ou composant externe

Le
Fredo
Bonjour à tous,

Je communique avec un périphérique par sockets en utilisant les
fonctions sockets standard de Windev (version 16)

Chez quelques clients, je rencontre un problème bizarre. Ma boucle de
lecture ne lit plus rien (sans erreurs) alors qu'en capturant les trames
à l'aide d'un appareil de capture de trames (physique, pas wireshark) je
vois bien que le périphérique émets correctement les trames.

Le fabricant m'indique qu'il n'a pas ce problème avec ses autres
partenaires (qui n'utilisent pas windev)

J'ai donc besoin afin de cibler l'origine du problème de mettre en place
un système de lecture socket alternatif, .net et/ou winsock, opération
que je n'ai jamais faite.

Afin de ne pas ré-inventer la poudre, si une âme généreuse avait un bout
de code ou un lien à me communiquer afin de dégrossir le boulot :)

Merci d'avance,

Fred.
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
MeBehindMyScreen
Le #26299878
Le 01/08/2014 10:23, Fredo a écrit :

Bonjour,

As-tu essayé de désactiver l'optimisation des trames réseau? Certains
automates ne me supportent pas.

Socket.Option = SocketNagleOff

Avec un peu de chance, cela devrait résoudre ton problème.


Bonjour à tous,

Je communique avec un périphérique par sockets en utilisant les
fonctions sockets standard de Windev (version 16)

Chez quelques clients, je rencontre un problème bizarre. Ma boucle de
lecture ne lit plus rien (sans erreurs) alors qu'en capturant les trames
à l'aide d'un appareil de capture de trames (physique, pas wireshark) je
vois bien que le périphérique émets correctement les trames.

Le fabricant m'indique qu'il n'a pas ce problème avec ses autres
partenaires (qui n'utilisent pas windev)

J'ai donc besoin afin de cibler l'origine du problème de mettre en place
un système de lecture socket alternatif, .net et/ou winsock, opération
que je n'ai jamais faite.

Afin de ne pas ré-inventer la poudre, si une âme généreuse avait un bout
de code ou un lien à me communiquer afin de dégrossir le boulot :)

Merci d'avance,

Fred.
Répondre en citant
MeBehindMyScreen
Le #26299877
Re,

Certains automates ne me supportent pas.



C'est pas faux! Mais dans ce cas précis il fallait lire
"ne LE supportent pas" ;-)
Répondre en citant
Fredo
Le #26300064
Le 04/08/2014 06:24, MeBehindMyScreen a écrit :
Re,

Certains automates ne me supportent pas.



C'est pas faux! Mais dans ce cas précis il fallait lire
"ne LE supportent pas" ;-)





Avec et sans, même combat.

Mais merci quand même !!

Fred.
Répondre en citant
PYT
Le #26302690
Le 01/08/2014 10:23, Fredo a écrit :

Bonjour,

Quand je communique avec des automates (via modus TCP)

J'ouvre le socket de cette façon

SI SocketExiste(socket_name) = Faux ALORS
SI SocketConnect(socket_name,port,host,time_out) = Faux ALORS
status = "";
ExceptionDéclenche(err_connection,ErreurInfo(errMessage))
ELSE
status = "Connecté"+RC;
SocketChangeModeTransmission(socket_name,SocketSansMarqueurFin)
FIN
connected = True
RENVOYER Vrai
FIN

Cordialement,

PYT

Bonjour à tous,

Je communique avec un périphérique par sockets en utilisant les
fonctions sockets standard de Windev (version 16)

Chez quelques clients, je rencontre un problème bizarre. Ma boucle de
lecture ne lit plus rien (sans erreurs) alors qu'en capturant les trames
à l'aide d'un appareil de capture de trames (physique, pas wireshark) je
vois bien que le périphérique émets correctement les trames.

Le fabricant m'indique qu'il n'a pas ce problème avec ses autres
partenaires (qui n'utilisent pas windev)

J'ai donc besoin afin de cibler l'origine du problème de mettre en place
un système de lecture socket alternatif, .net et/ou winsock, opération
que je n'ai jamais faite.

Afin de ne pas ré-inventer la poudre, si une âme généreuse avait un bout
de code ou un lien à me communiquer afin de dégrossir le boulot :)

Merci d'avance,

Fred.
Répondre en citant
Pierre BOUSQUET
Le #26335202
PYT a formulé ce lundi :
Le 01/08/2014 10:23, Fredo a écrit :

Bonjour,

Quand je communique avec des automates (via modus TCP)

J'ouvre le socket de cette façon

SI SocketExiste(socket_name) = Faux ALORS
SI SocketConnect(socket_name,port,host,time_out) = Faux ALORS
status = "";
ExceptionDéclenche(err_connection,ErreurInfo(errMessage))
ELSE
status = "Connecté"+RC;
SocketChangeModeTransmission(socket_name,SocketSansMarqueurFin)
FIN
connected = True
RENVOYER Vrai
FIN

Cordialement,

PYT

Bonjour à tous,

Je communique avec un périphérique par sockets en utilisant les
fonctions sockets standard de Windev (version 16)

Chez quelques clients, je rencontre un problème bizarre. Ma boucle de
lecture ne lit plus rien (sans erreurs) alors qu'en capturant les trames
à l'aide d'un appareil de capture de trames (physique, pas wireshark) je
vois bien que le périphérique émets correctement les trames.

Le fabricant m'indique qu'il n'a pas ce problème avec ses autres
partenaires (qui n'utilisent pas windev)

J'ai donc besoin afin de cibler l'origine du problème de mettre en place
un système de lecture socket alternatif, .net et/ou winsock, opération
que je n'ai jamais faite.

Afin de ne pas ré-inventer la poudre, si une âme généreuse avait un bout
de code ou un lien à me communiquer afin de dégrossir le boulot :)

Merci d'avance,

Fred.





Bonjour,

Effectivement ce problème peut arriver quand il y a coupure de liaison,
Windev ne le détecte pas vraiment lorsque l'on fait un SocketExiste()
ou un SocketLit()

J'ai pu constater que quand la connexion était coupée, le temps de
lecture dans la fonction SocketLit() est largement inférieur à celui
demandé, par exemple on demande la lecteure pendant 1s et la fonction
ne met que quelque dixième, j'ai donc créée une fonction :

ChronoDebut(NumChrono)

Buff=SocketLit(ConvoyeurSocket:NomSocket,Faux,ConvoyeurSocket:TpsAttenteSocket)

Tps=ChronoValeur(NumChrono,Faux,-1)

// Erreur de connexion
SI PAS SocketControle(Tps,ConvoyeurSocket:TpsAttenteSocket)
####ERREUR###
FIN




PROCEDURE SocketControle(TempsReel est numérique (7,3),
TempsAttenteSocket)
// Controle le temps de réaction sur la lecture d'une socket
// permet de savoir si la socket a été fermée par l'autre partie
// contrôle du temps par rapport à un temps de référence
// TempsAttenteSocket est en milisecondes : ex 1000
// Temps reel fourni par une fonction chrono ex : 1.000
// Renvoyer vrai = OK

SI 10 * TempsReel < TempsAttenteSocket/1000 ALORS
RENVOYER Faux
SINON
RENVOYER Vrai
FIN
Répondre en citant
Fredo
Le #26335210
Le 22/01/2015 11:24, Pierre BOUSQUET a écrit :
PYT a formulé ce lundi :
Le 01/08/2014 10:23, Fredo a écrit :

Bonjour,

Quand je communique avec des automates (via modus TCP)

J'ouvre le socket de cette façon

SI SocketExiste(socket_name) = Faux ALORS
SI SocketConnect(socket_name,port,host,time_out) = Faux ALORS
status = "";
ExceptionDéclenche(err_connection,ErreurInfo(errMessage))
ELSE
status = "Connecté"+RC;
SocketChangeModeTransmission(socket_name,SocketSansMarqueurFin)
FIN
connected = True
RENVOYER Vrai
FIN

Cordialement,

PYT

Bonjour à tous,

Je communique avec un périphérique par sockets en utilisant les
fonctions sockets standard de Windev (version 16)

Chez quelques clients, je rencontre un problème bizarre. Ma boucle de
lecture ne lit plus rien (sans erreurs) alors qu'en capturant les trames
à l'aide d'un appareil de capture de trames (physique, pas wireshark) je
vois bien que le périphérique émets correctement les trames.

Le fabricant m'indique qu'il n'a pas ce problème avec ses autres
partenaires (qui n'utilisent pas windev)

J'ai donc besoin afin de cibler l'origine du problème de mettre en place
un système de lecture socket alternatif, .net et/ou winsock, opération
que je n'ai jamais faite.

Afin de ne pas ré-inventer la poudre, si une âme généreuse avait un bout
de code ou un lien à me communiquer afin de dégrossir le boulot :)

Merci d'avance,

Fred.





Bonjour,

Effectivement ce problème peut arriver quand il y a coupure de liaison,
Windev ne le détecte pas vraiment lorsque l'on fait un SocketExiste() ou
un SocketLit()

J'ai pu constater que quand la connexion était coupée, le temps de
lecture dans la fonction SocketLit() est largement inférieur à celui
demandé, par exemple on demande la lecteure pendant 1s et la fonction ne
met que quelque dixième, j'ai donc créée une fonction :

ChronoDebut(NumChrono)

Buff=SocketLit(ConvoyeurSocket:NomSocket,Faux,ConvoyeurSocket:TpsAttenteSocket)


Tps=ChronoValeur(NumChrono,Faux,-1)

// Erreur de connexion
SI PAS SocketControle(Tps,ConvoyeurSocket:TpsAttenteSocket)
####ERREUR###
FIN




PROCEDURE SocketControle(TempsReel est numérique (7,3), TempsAttenteSocket)
// Controle le temps de réaction sur la lecture d'une socket
// permet de savoir si la socket a été fermée par l'autre partie
// contrôle du temps par rapport à un temps de référence
// TempsAttenteSocket est en milisecondes : ex 1000
// Temps reel fourni par une fonction chrono ex : 1.000
// Renvoyer vrai = OK

SI 10 * TempsReel < TempsAttenteSocket/1000 ALORS
RENVOYER Faux
SINON
RENVOYER Vrai
FIN




Un post qui date un peu ... mais merci pour cette réponse, je vais
mettre ton code en test immédiatement !!!

Merci merci merci !!

Fred.
Répondre en citant
Free
Le #26341452
Fredo avait écrit le 22/01/2015 :
Le 22/01/2015 11:24, Pierre BOUSQUET a écrit :
PYT a formulé ce lundi :
Le 01/08/2014 10:23, Fredo a écrit :

Bonjour,

Quand je communique avec des automates (via modus TCP)

J'ouvre le socket de cette façon

SI SocketExiste(socket_name) = Faux ALORS
SI SocketConnect(socket_name,port,host,time_out) = Faux ALORS
status = "";
ExceptionDéclenche(err_connection,ErreurInfo(errMessage))
ELSE
status = "Connecté"+RC;
SocketChangeModeTransmission(socket_name,SocketSansMarqueurFin)
FIN
connected = True
RENVOYER Vrai
FIN

Cordialement,

PYT

Bonjour à tous,

Je communique avec un périphérique par sockets en utilisant les
fonctions sockets standard de Windev (version 16)

Chez quelques clients, je rencontre un problème bizarre. Ma boucle de
lecture ne lit plus rien (sans erreurs) alors qu'en capturant les trames
à l'aide d'un appareil de capture de trames (physique, pas wireshark) je
vois bien que le périphérique émets correctement les trames.

Le fabricant m'indique qu'il n'a pas ce problème avec ses autres
partenaires (qui n'utilisent pas windev)

J'ai donc besoin afin de cibler l'origine du problème de mettre en place
un système de lecture socket alternatif, .net et/ou winsock, opération
que je n'ai jamais faite.

Afin de ne pas ré-inventer la poudre, si une âme généreuse avait un bout
de code ou un lien à me communiquer afin de dégrossir le boulot :)

Merci d'avance,

Fred.





Bonjour,

Effectivement ce problème peut arriver quand il y a coupure de liaison,
Windev ne le détecte pas vraiment lorsque l'on fait un SocketExiste() ou
un SocketLit()

J'ai pu constater que quand la connexion était coupée, le temps de
lecture dans la fonction SocketLit() est largement inférieur à celui
demandé, par exemple on demande la lecteure pendant 1s et la fonction ne
met que quelque dixième, j'ai donc créée une fonction :

ChronoDebut(NumChrono)

Buff=SocketLit(ConvoyeurSocket:NomSocket,Faux,ConvoyeurSocket:TpsAttenteSocket)


Tps=ChronoValeur(NumChrono,Faux,-1)

// Erreur de connexion
SI PAS SocketControle(Tps,ConvoyeurSocket:TpsAttenteSocket)
####ERREUR###
FIN




PROCEDURE SocketControle(TempsReel est numérique (7,3), TempsAttenteSocket)
// Controle le temps de réaction sur la lecture d'une socket
// permet de savoir si la socket a été fermée par l'autre partie
// contrôle du temps par rapport à un temps de référence
// TempsAttenteSocket est en milisecondes : ex 1000
// Temps reel fourni par une fonction chrono ex : 1.000
// Renvoyer vrai = OK

SI 10 * TempsReel < TempsAttenteSocket/1000 ALORS
RENVOYER Faux
SINON
RENVOYER Vrai
FIN




Un post qui date un peu ... mais merci pour cette réponse, je vais mettre ton
code en test immédiatement !!!

Merci merci merci !!

Fred.



Bonjour Fred ,

J'ai rencontré les mêmes problèmes avec un périphérique qui communique
par socket.

Pourrais tu me dire si la solution proposée par Pierre fonctionne ?

Merci

JYB

---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast.
http://www.avast.com
Répondre en citant
Fredo
Le #26342121
Le 01/03/2015 14:04, Free a écrit :
Fredo avait écrit le 22/01/2015 :
Le 22/01/2015 11:24, Pierre BOUSQUET a écrit :
PYT a formulé ce lundi :
Le 01/08/2014 10:23, Fredo a écrit :

Bonjour,

Quand je communique avec des automates (via modus TCP)

J'ouvre le socket de cette façon

SI SocketExiste(socket_name) = Faux ALORS
SI SocketConnect(socket_name,port,host,time_out) = Faux ALORS
status = "";
ExceptionDéclenche(err_connection,ErreurInfo(errMessage))
ELSE
status = "Connecté"+RC;
SocketChangeModeTransmission(socket_name,SocketSansMarqueurFin)
FIN
connected = True
RENVOYER Vrai
FIN

Cordialement,

PYT

Bonjour à tous,

Je communique avec un périphérique par sockets en utilisant les
fonctions sockets standard de Windev (version 16)

Chez quelques clients, je rencontre un problème bizarre. Ma boucle de
lecture ne lit plus rien (sans erreurs) alors qu'en capturant les
trames
à l'aide d'un appareil de capture de trames (physique, pas
wireshark) je
vois bien que le périphérique émets correctement les trames.

Le fabricant m'indique qu'il n'a pas ce problème avec ses autres
partenaires (qui n'utilisent pas windev)

J'ai donc besoin afin de cibler l'origine du problème de mettre en
place
un système de lecture socket alternatif, .net et/ou winsock, opération
que je n'ai jamais faite.

Afin de ne pas ré-inventer la poudre, si une âme généreuse avait un
bout
de code ou un lien à me communiquer afin de dégrossir le boulot :)

Merci d'avance,

Fred.





Bonjour,

Effectivement ce problème peut arriver quand il y a coupure de liaison,
Windev ne le détecte pas vraiment lorsque l'on fait un SocketExiste() ou
un SocketLit()

J'ai pu constater que quand la connexion était coupée, le temps de
lecture dans la fonction SocketLit() est largement inférieur à celui
demandé, par exemple on demande la lecteure pendant 1s et la fonction ne
met que quelque dixième, j'ai donc créée une fonction :

ChronoDebut(NumChrono)

Buff=SocketLit(ConvoyeurSocket:NomSocket,Faux,ConvoyeurSocket:TpsAttenteSocket)



Tps=ChronoValeur(NumChrono,Faux,-1)

// Erreur de connexion
SI PAS SocketControle(Tps,ConvoyeurSocket:TpsAttenteSocket)
####ERREUR###
FIN




PROCEDURE SocketControle(TempsReel est numérique (7,3),
TempsAttenteSocket)
// Controle le temps de réaction sur la lecture d'une socket
// permet de savoir si la socket a été fermée par l'autre partie
// contrôle du temps par rapport à un temps de référence
// TempsAttenteSocket est en milisecondes : ex 1000
// Temps reel fourni par une fonction chrono ex : 1.000
// Renvoyer vrai = OK

SI 10 * TempsReel < TempsAttenteSocket/1000 ALORS
RENVOYER Faux
SINON
RENVOYER Vrai
FIN




Un post qui date un peu ... mais merci pour cette réponse, je vais
mettre ton code en test immédiatement !!!

Merci merci merci !!

Fred.



Bonjour Fred ,

J'ai rencontré les mêmes problèmes avec un périphérique qui communique
par socket.

Pourrais tu me dire si la solution proposée par Pierre fonctionne ?

Merci

JYB

---
L'absence de virus dans ce courrier électronique a été vérifiée par le
logiciel antivirus Avast.
http://www.avast.com





Salut,

Malheureusement non.

Fred.
Répondre en citant
Publicité
Poster une réponse
Anonyme