Erreurs, bugs, questions - page 2707

Nouveau commentaire
 
Roman:

Oui, en effet, dans votre code, sur le port 80 l'en-tête est renvoyé, sur le 443 non.
J'ai revu votre code, et je n'ai pas vu la fonction SocketTlsHandshake.
Votre code ne fait pas de poignée de main. C'est peut-être la raison.
Bien que l'aide pour cette fonction indique qu'elle n'est pas nécessaire si vous vous connectez au port 443.

Exactement, ce n'est pas mon code, mais celui de l'exemple des développeurs (les sockets de MQ ont des caractéristiques peu intuitives qui sont parfois comprises sur le forum, donc je me suis tourné vers l'exemple standard). J'ai essayé SocketTlsHandshake - il renvoie toujours false dans toutes les conditions et n'a aucun effet sur la résolution des problèmes. Puisque les données du certificat sont renvoyées, la poignée de main passe. Même l'en-tête, à en juger par sa longueur, arrive mais ne revient pas au code MQL. Le code d'erreur est trop générique et l'erreur elle-même est discutable. Nous avons besoin de l'avis d'un initié.
 
Stanislav Korotky:
Exactement, ce n'est pas mon code, mais celui de l'exemple des développeurs (les sockets de MQ ont des caractéristiques peu intuitives, qui sont parfois expliquées dans le forum, donc je me suis tourné vers l'exemple standard). J'ai essayé SocketTlsHandshake - il renvoie toujours false dans toutes les conditions et n'a aucun effet sur la solution. Puisque les données du certificat sont renvoyées, la poignée de main passe. Même l'en-tête, à en juger par sa longueur, arrive mais ne revient pas au code MQL. Le code d'erreur est trop générique et l'erreur elle-même est discutable. Nous avons besoin de l'avis d'un initié.

Il n'est pas nécessaire d'utiliser la fonction SocketTlsHandshake si la connexion est initialement sécurisée ("https://" ou port 443 ou 465)

La fonction est utilisée dans des cas/protocoles spéciaux

 
Ilyas:

SocketTlsHandshake n'a pas besoin d'être utilisé si la connexion est initialement sécurisée ("https://" ou port 443 ou 465)

La fonction est utilisée dans des cas/protocoles particuliers

Je ne l'utilise pas. Le code permettant de reproduire le problème est joint.

 
Stanislav Korotky:

Je ne l'utilise pas. Le code permettant de reproduire le problème est joint.

Remplacer SocketTlsRead par SocketTlsReadAvailable

 
Ilyas:

Remplacer SocketTlsRead par SocketTlsReadAvailable

Pouvez-vous être plus précis ? Dans la documentation de l'exemple, c'est SocketTlsRead qui est utilisé. Pourquoi n'a-t-on pas utilisé SocketTlsReadAvailable à cet endroit ?

Quand dois-je utiliser une fonction et quand dois-je en utiliser une autre ?

Comment écrire un code universel pour bloquer une lecture à partir d'un socket, adapté aux connexions protégées et non protégées - nous n'avons pas la fonction SocketReadAvailable, n'est-ce pas ?

PS. Modification de la fonction. L'erreur n'a pas disparu. Voici le code mis à jour. GetLastError renvoie 0.

Dossiers :
SocketExample.mq5  4 kb
 

Dans le testeur visuel, l'appel de la fonctionCopyTicksRange depuis l'indicateurse termine par l'erreur 4014 (ERR_FUNCTION_NOT_ALLOWED).

Le même indicateur fonctionne bien en ligne sur le même instrument. Quel est le problème ? Cette fonction est-elle interdite dans le testeur ? Je n'ai trouvé aucune mention de ça dans l'aide.

 
Stanislav Korotky:

Dans le testeur visuel, l'appel de la fonctionCopyTicksRange depuis l'indicateurse termine par l'erreur 4014 (ERR_FUNCTION_NOT_ALLOWED).

Le même indicateur fonctionne bien en ligne sur le même instrument. Quel est le problème ? Cette fonction est-elle interdite dans le testeur ? Je ne l'ai pas trouvé dans l'aide.

Testé par de vraies tiques ?

 
Stanislav Korotky:
Exactement, ce n'est pas mon code, mais celui de l'exemple des développeurs (les sockets de MQ ont quelques fonctionnalités peu intuitives qui sont parfois comprises dans le forum, donc je me suis tourné vers l'exemple standard). J'ai essayé SocketTlsHandshake - il renvoie toujours false dans toutes les conditions et n'a aucun effet sur la résolution du problème. Puisque les données du certificat sont renvoyées, la poignée de main passe. Même l'en-tête, à en juger par sa longueur, arrive, mais ne revient pas au code MQL. Le code d'erreur est trop générique et l'erreur elle-même est discutable. Nous avons besoin de l'avis d'un initié.

Oui, j'ai été surpris aussi que sans SocketTlsHandshake le certificat soit renvoyé.
Mais avec la fonction SocketTlsHandshake, il appelle l'erreur.
Il y a une sorte de logique implicite dans ce comportement.

if(SocketConnect(socket, Address, Port, 5000) && SocketTlsHandshake(socket, Address))
Can't connect to echo.websocket.org:443, error 5274

UPD :
La recommandation d'Ilyas a été vue.
Oui, sans cette fonctionnalité, il n'y a pas de problème de connexion.
Le problème, c'est la lecture.
 
Ilyas:

Remplacer SocketTlsRead par SocketTlsReadAvailable

J'ai essayé le même remplacement avec SocketTlsReadAvailable

int rsp_len; 

if(ExtTLS)
   rsp_len = SocketTlsReadAvailable(socket, rsp, len); 
   //rsp_len = SocketTlsRead(socket, rsp, len);
else
   rsp_len = SocketRead(socket, rsp, len, timeout);

Le comportement est le même que pourSocketTlsRead.

UPD :
Le même problème existe lorsque vous utilisez SocketTlsHandshake sur un port différent.

 

Je suggère d'ajouter des spécificités à la validation automatique des produits sur la place de marché. En plus des erreurs générales signalées par le validateur, le contexte du test effectué et les journaux sont fortement demandés. En particulier, je n'ai pas été en mesure de mettre à jour un indicateur depuis quelques années maintenant à cause de l'erreur "le testeur prend trop de temps". La première version a été téléchargée sous modération "humaine" et n'a fait l'objet d'aucune plainte. Les critères de l'autovalidateur pour émettre cette erreur ne sont absolument pas clairs.

Voici une question spécifique : combien de ticks en combien de temps le produit doit-il fournir sur quel matériel pour que le "testeur prend trop de temps" n'apparaisse pas ?

L'indicateur est destiné à traiter les ticks par l'algorithme MapReduce, des calculs entiers sont utilisés, il n'y a donc rien à compresser, sauf si vous jetez l'algorithme lui-même. Le profileur a été utilisé, un trottage a été ajouté pour recalculer le tableau des nouveaux ticks avec une période donnée. En vain.

Sur mon ordinateur, l'année est testée en quelques minutes. Il est impossible de savoir pour l'instant ce qui se passe réellement dans l'autovalidateur et pourquoi il ralentit.

L'absence d'un support produit adéquat est un problème tant pour les utilisateurs que pour MQ - cela affecte la mise en œuvre.

1...270027012702270327042705270627072708270927102711271227132714...3184
Nouveau commentaire