OnBookEventのサブスクリプションが落ちることがあるのですが、そのようなことはあるのでしょうか？ - ページ 2

[A100]

Stanislav Korotky:

"一人の専門家が配信を停止すれば、他の専門家も配信を停止する"？

それは間違いない

[Sergey Savinkin]

Stanislav Korotky:

価値があるかどうかはあくまで推測ですが、「あるEAがイベントの受信を停止するだけで、他のEAもすべて受信を停止する」ということを続けている例で言うと？そんなのありえないと思う、バグでしょう（笑）。

ひとつは、チェックが簡単なこと。自分でやりたいのですが、FORTSのアカウントしか持っていないので、週末はお休みなんです。

しかし、もしそうなら、その状況は面白いことになる。Expert Advisor とインジケータを有効にすると、サブスクリプションがトリガーされました。Expert AdvisorやIndicatorを無効にすると、サブスクリプションがクラッシュしたと既に書かれています。これは、放送が逆方向にも作用していることを示唆している。ここで、何かが変わったとします（例えば、履歴が変わり、インジケータが再計算された）。しかし、OnInitとOnDeinitはランダムに呼び出せることが分かっています。正しい場合もあれば、その逆の場合もあります。チャートが新しいバージョンのインジケータを最初に呼び出し、その後、古いインジケータをアンインストールした場合、どうなりますか？加入が落ちます。それこそ「静かに落ちていく」ような感じでしょうか。株価が来なくなったときのために、OnInitとOnDeinitにプリンターを入れて、キューとメッセージをチェックすることをお勧めします。もしかしたら、問題がクリアになるかもしれません。

[A100]

Sergey Savinkin:

まず、確認が簡単なこと。自分でやりたいのですが、FORTSにしかアカウントを持っていないので、週末はお休みです。

CHARTEVENT_OBJECT_CREATE を使わなくても、スコアの確認は全く問題ありません。

[Алексей Тарабанов]

https://yandex.ru/images/search?source=wiz&text=два%20выключателя%20на%20одну%20лампочку&img_url=https%3A%2F%2Frepair-need.ru%2Fuploads%2Fdico-kebfbf.jpg&pos=3&rpt=simage&lr=213

[TheXpert]

A100:
当たり前のことなのですが

よくわからないけど、いつでもリンクカウンターをつけられるように

[A100]

TheXpert:

よくわからないけど、いつでもリンクカウンターをつけられるように

カウンターはありません。そして、もしあれば、その存在とAddReleaseペアの呼び出しの可否について、ドキュメントに明示されるでしょう。

そして、リファレンスカウンターが必要だと言うのなら...。それならいっそのこと、放送を全廃してしまえばいい。

[TheXpert]

A100:

カウンターはありません。また、もしあったとしても、それが存在し、Add/Releaseのペアコールだけが許されることがドキュメントに明記されているはずです。そうでなければ、カウンターは失われ、その存在意義が失われることになります

で、今は誰でも退会できるというロジックがナンセンスなので、リリース機能は無意味です。

[Ilya Baranov]

単純にMarketBookRelease 関数を使わないという提案もあります。

理論的には、端末やサーバーのリソースの一部を無駄にすることになります。

しかし、実際には...これによって、何か実際の結果が出るのでしょうか？

[A100]

TheXpert:

誰でも退会できるというロジックはナンセンスなロジックなので、リリース機能の意味がない。

たとえカウンターがあったとしても、誰でも 何 度でもリリースに 電話すれば退会できます。ほとんどの場合、カウンターは余分な電話を検出できず、現在の問題はカウンターの誤動作の問題に変わって しまうでしょう。また、スマートカウンターが使えるようになれば、そのような放送を廃止することも可能です。

[Stanislav Korotky]

ハリネズミのために説明しても無意味なので、他の人のために書きます ;-)。

イベントブロードキャストの概念と、イベントに対するsubscribeとunsubscribeの関数をペアコールする原理は別物である。これらは意味的に独立した技術であり、互いに影響しあう必要はなく、理想的には影響しあうべきではありません。イベントをブロードキャストさせる（これは効率化のために行われたのだろうが、非常に議論があり、実装を誤ると今回のような問題を引き起こす可能性がある）。つまり、一人が申し込むだけで、全員がイベントを受け取ることができるのです。しかし、逆に言えば、一人が退会すると全員がダメになる、それはもうある種のナローキャスティングなのです。

ドキュメントにある契約者数のカウンターについては、非常に重要であるにもかかわらず、言及されていません（また、放送に関するフレーズは、上記の理由による説明ではありません）。ブロードキャストは理想的には購読者数が0になるまで続くべきです。 そうでなければ、（異なる開発者のものも含めて）MQLプログラムが互いの仕事に害を与えないように、何らかの形で通信しなければならないのは明らかですが、これはナンセンスです。このような形でサブスクリプションが実装されたソフトウェア（MTやWindowsなどに限らない広義の）の例を、私はひとつも知りません。

MarketBookReleaseについて、こんな一節がある。

Обычно эта функция должна вызываться из функции OnDeinit() в том случае, если в функции OnInit() была вызвана соответствующая функция MarketBookAdd().

また、曖昧な表現になってしまいます。加入者数をコントロールしていると解釈することもできる。でも、このソフトは私的な解釈を許さないんです。

結論から言うと、IMHOは、実装はレーキ（MQLレベルで検証とオーバーサブスクリプションが必要）、ドキュメントは濁り。悪意のある、あるいは明らかに悪いコードは、カウンターを使用しても他人の購読を停止させることができるという主張は、実際には関係ないものです。そのようなスクリプトはすべて、ターミナルの他の多くの場所で害を及ぼす可能性があります（例えば、他の人のオブジェクトを削除する、他の人の位置のストップを殺すなど、これまでに100万回起こったことがあります）。このようなあからさまなピギーバックの発現については、ユーザーの規律、他のユーザーのコードの校正（もしあれば）、デモでのチェック以外では防ぐことができませんので、お話する意味がありません。今問題になっているのは、きちんと書かれたコードがまともに動かないことです。

この仕組みをきちんとやるなら、もちろん--パブリッシャー／サブスクライバーのパターンが廃止されたわけではありません。確かに効率には影響しないでしょう。