さて前回は、エラーコード「ERR_TRADE_TIMEOUT/142/143」発生時の制御について検討したところまで書きました。今回は、以前のブログ記事に載せた課題のうち、ECN系FX業者への対応について書いてみたいと思います。


そもそも、ECN系ってちゃんと租借しきれてないけど、
以下のHPから情報を得てみた。

【そもそも「ECN」って何?】
------------------------
--------------------------

要約すると。

●ECNとは
 電子取引ネットワークのことで、ブローカー同士が、電子ネットワークで繋がって擬似公設市場的な
 取引環境を構築しているシステム
●ECNのメリット
 よく噂されるストップ刈りや約定拒否といった不透明さが無くて、顧客の注文を直接ECNに流すので、
 透明性がある。

という事らしい。

なかなかいいじゃないですか。。

じゃあ、MT4EA開発時に一体何の関係があるのか、という話。

【ECNの場合のMT4用EA開発への影響】
-----------------------------
  →この記事は、 ECNタイプの海外FX業者ってどこ?という話
-----------------------------

つまり、MT4用EA開発で、OrderSendする時SL/TPを指定できない。SL/TP指定したければ、OrderSend()後にOrderModify()せよ、という事みたい。(成り行き注文の場合のみという記事もあるけど、どこにあったか忘れた。。)。
#ECNかどうかが問題なのではなく、使っているブリッジ(トレードサーバの事かなぁ)によるものかもしれない、
 という事も上記記事に書いてありました。

ちょっと前までは、上記「1.」の記事を見て、ECNタイプはマイノリティーなのかなって思っていたけど、どうも風潮的にはそうじゃなさそう。
今口座を開こうと思っているFX業者はECNタイプじゃないけど、共通部品の汎用性を考えると、ECN対応することに。






しかし、透明性が高いトレードができても、

EA開発者泣かせな仕様だ。。。


【ECNタイプのEA開発者泣かせなところ】
-------------------------
結局一番悩みどころは、OrderSend()成功後のOrderModify()失敗時どうするか、という事。

案1.OrderClose/OrderDeleteする
案2.成功するまで延々とOrderModify()を繰り返す

ちなみに、OrderModify()失敗と言うのは、今まで通りに、エラーコードよってはリトライはするという前提で、リトライアウトした場合の話。次ティックデータ受信を待つ場合は失敗扱い。OrderSend()時も同様。
-------------------------

いづれにせよ、StopLossが指定されていないまま、マーケットが閉じてしまって、週を跨って
しまった
場合等、SL指定されていないポジションが無防備なまま放置されてしまう所がイヤ。

例えば、マーケットが閉じている休日にビッグニュースが起きて、週明けに大きく窓を開けて開始して、スリッページが酷い状態の場合、マーケットが開いてからOrderModifyを継続したり、OrderClose/OrderDeleteに再チャレンジしたところで、前の週にSLを指定できた時と比べると不利な気がする。

しかも、上記の様な場合はオーダが集中する事が予想されるので、サーバ側がスローダウンしたり、タイムアウトが発生したりする事も想定される。







でも、しょうがないんだな。。。



いづれにせよ、前述の「案1.」か「案2.」しかない。


【両案の比較検討】
-----------------------------
今回のケースで、OrderSendに成功してOrderModifyに失敗するケースで、今までの設計を踏襲すると
以下の様になる。

1.サーバ/ネットワーク異常 →  基本的にリトライ
2.価格不一致  → 次のティックデータを待つ
3.プログラムバグ → 新規発注禁止状態にしてあきらめる

ケース毎に比較してみると。

●ケース毎の比較
 1.サーバ異常の場合
   OrderModifyがリトライアウトしたという事なので、OrderCloseやOrderDeleteも
   失敗する可能性が高い。なので、「案1.」でも「案2.」でも大差は無い。
 2.価格不一致の場合
   次ティックデータを待つ事になるけど、流動性が低く、マーケットが閉じる直前だと、
   リスクとしては、「案1.」の方が安全。プログラムもシンプル。
   ただし、機会損失というデメリットもある。
   #週を跨いでしまった結果、発注されないケースもあると思うので
 3.プログラムバグ
   「新規発注禁止状態」にする設計ポリシーだし、例えリトライしても意味が無い
   ので、「案1.」しかない。

なので、「機会損失」というデメリットはあるものの、「案1.OrderClose/OrderDeleteする」の方がよさそう。
----------------------------------------

なので、「案1.」という結論にした場合の発注時の処理を整理すると以下。

【ECNタイプの場合の発注時の処理】
--------------------------
1.OrderSend()失敗時は、次のティックデータ受信まで待つ
2.OrderModify()失敗時
  ・無条件にOrderClose()/OrderDelete()する
  ・警告レベルのログ出力と、メール通知。
3.OrderModify()失敗後のOrderClose()成功時
  ・通常レベルのログ出力と、クローズに成功した旨のメール通知
4.OrderModify()失敗後のOrderClose()失敗時
  ・警告レベルのログ出力と、メール通知。
  ・次のティックデータ受信時に再度試みる様にする

ちなみに、ECNタイプかそうでないかはMT4のAPIからは、わからないので、
プロパティ化して、該当プロパティがTRUEの時のみ上記処理にする。
--------------------------

今まで勘だけで、「案1.OrderClose/OrderDeleteする」にしてたけど、ブログで改めて検討してみて、すっきりした。

それと、過去のブログ記事で書いた「OrderSelect問題」という仮説が発端となったstart()全体で排他制御する仕組みも、このケースでは有利に働く気がする。

つまり、OrderSend()後は速やかにOrderModify()したいけど、1つのMT4で複数EAを走らせていた場合、OrderSend()後に別のEAがオーダ関連処理を開始してしまって、OrderModify()がコンテキストビジーでなかなか処理を開始できない状況になる可能性がでてしまう。
でも、start()全体を排他利用する場合は、他に割り込まれる事が無いので、その分OrderModify()が遅延するリスクが減るから。
#排他制御入れる前は、結構コンテキスト・ビジーが発生していたし




しかし、なんでこんなMT4の仕様にしたのか。。
ECNが故という背景がよくわからない。
 
FX業者側の都合か?
それでもよくわからん。。


あと、指値/逆指値注文だと、この対処が不要という説もあるけど、事実関係は未だ不明。
テスターだと判らないっぽいし、デモ環境でどうなるかは、まだ試していない。
#某FX業者のMT4の手動発注画面を見てると、確かに成り行き注文の時だけ、SL/TPを指定できなかったけど。


そして実際に作って、いつもとは違う、某FX業者のMT4のテスター上で動かして見ると。






まったく動かん。

トレード回数ゼロ


結局何がおきてたかというと、以前のロット数計算に関する記事で、以下の問題が。


【ロット数計算方法の修正】
----------------------
以前のロット数計算に関する記事で、以下の部分が上手く動いていなかった。

●「1.1トレードあたりの証拠金利用率の局所化」の以下の記述。
 ・
「1ロット当りの必要証拠金」(MODE_MARGINREQUIRED/MODE_MARGININIT
   /MODE_MARGINMAINTENANCEのいづれか)を使って、極端なロット数を制限」
 ・「『「0以外で、一番高い値を使うという事にしてみた。」

その某FX業者の場合、MODE_MARGININIT」と「MODE_MARGINMAINTENANCE」が、
10万US$
というあり得ない値。さらに別のFX業者のMT4を見てみたら、両方ゼロ。
なので、FXの場合は、「MODE_MARGINREQUIRED」が正解っぽい。

結局、 MarketInfo(Symbol() , MODE_MARGINCALCMODE)がゼロ(FX)以外の場合は
クリティカル・エラー扱いにし、MODE_MARGINREQUIRED」を使う様に修正。

なので、今回の共通部品はFX以外で使えなくなりました。。
----------------------




仕様をもっと明確にしてほしい。。





そして、ロジックを考えた事以外は他力本願な内容で、「FXシステムトレード初心者奮闘記」の「MT4用EA開発時代」は、新たなバグが出ない限り、「OrderSelect問題」仮説の検証に進むかもしれないのでした。
#でもその前に前回記事の内容でEA修正しなきゃ。。


【Ads by Google】