さて前回は、エラーコード「ERR_TRADE_TIMEOUT/142/143」発生時の制御について検討したところまで書きました。今回は、以前のブログ記事に載せた課題のうち、ＥＣＮ系ＦＸ業者への対応について書いてみたいと思います。
そもそも、ＥＣＮ系ってちゃんと租借しきれてないけど、
以下のＨＰから情報を得てみた。
以下のＨＰから情報を得てみた。
【そもそも「ＥＣＮ」って何？】
－－－－－－－－－－－－－－－－－－－－－－－－
－－－－－－－－－－－－－－－－－－－－－－－－－－
要約すると。
●ＥＣＮとは
電子取引ネットワークのことで、ブローカー同士が、電子ネットワークで繋がって擬似公設市場的な
取引環境を構築しているシステム
●ＥＣＮのメリット
よく噂されるストップ刈りや約定拒否といった不透明さが無くて、顧客の注文を直接ECNに流すので、
透明性がある。
という事らしい。
なかなかいいじゃないですか。。
じゃあ、ＭＴ４ＥＡ開発時に一体何の関係があるのか、という話。
【ＥＣＮの場合のＭＴ４用ＥＡ開発への影響】
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
→この記事は、 ＥＣＮタイプの海外ＦＸ業者ってどこ？という話
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
つまり、ＭＴ４用ＥＡ開発で、OrderSendする時ＳＬ／ＴＰを指定できない。ＳＬ／ＴＰ指定したければ、OrderSend()後にOrderModify()せよ、という事みたい。（成り行き注文の場合のみという記事もあるけど、どこにあったか忘れた。。）。
＃ＥＣＮかどうかが問題なのではなく、使っているブリッジ（トレードサーバの事かなぁ）によるものかもしれない、
という事も上記記事に書いてありました。
という事も上記記事に書いてありました。
ちょっと前までは、上記「１．」の記事を見て、ＥＣＮタイプはマイノリティーなのかなって思っていたけど、どうも風潮的にはそうじゃなさそう。
今口座を開こうと思っているＦＸ業者はＥＣＮタイプじゃないけど、共通部品の汎用性を考えると、ＥＣＮ対応することに。
しかし、透明性が高いトレードができても、
ＥＡ開発者泣かせな仕様だ。。。
【ＥＣＮタイプのＥＡ開発者泣かせなところ】
－－－－－－－－－－－－－－－－－－－－－－－－－
結局一番悩みどころは、OrderSend()成功後のOrderModify()失敗時どうするか、という事。
案１．OrderClose/OrderDeleteする
案２．成功するまで延々とOrderModify()を繰り返す
ちなみに、OrderModify()失敗と言うのは、今まで通りに、エラーコードよってはリトライはするという前提で、リトライアウトした場合の話。次ティックデータ受信を待つ場合は失敗扱い。OrderSend()時も同様。
－－－－－－－－－－－－－－－－－－－－－－－－－
いづれにせよ、StopLossが指定されていないまま、マーケットが閉じてしまって、週を跨って
しまった場合等、ＳＬ指定されていないポジションが無防備なまま放置されてしまう所がイヤ。
しまった場合等、ＳＬ指定されていないポジションが無防備なまま放置されてしまう所がイヤ。
例えば、マーケットが閉じている休日にビッグニュースが起きて、週明けに大きく窓を開けて開始して、スリッページが酷い状態の場合、マーケットが開いてからOrderModifyを継続したり、OrderClose/OrderDeleteに再チャレンジしたところで、前の週にＳＬを指定できた時と比べると不利な気がする。
しかも、上記の様な場合はオーダが集中する事が予想されるので、サーバ側がスローダウンしたり、タイムアウトが発生したりする事も想定される。
でも、しょうがないんだな。。。
いづれにせよ、前述の「案１．」か「案２．」しかない。
【両案の比較検討】
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
今回のケースで、OrderSendに成功してOrderModifyに失敗するケースで、今までの設計を踏襲すると
以下の様になる。
１．サーバ／ネットワーク異常 → 基本的にリトライ
２．価格不一致 → 次のティックデータを待つ
３．プログラムバグ → 新規発注禁止状態にしてあきらめる
ケース毎に比較してみると。
●ケース毎の比較
１．サーバ異常の場合
OrderModifyがリトライアウトしたという事なので、OrderCloseやOrderDeleteも
失敗する可能性が高い。なので、「案１．」でも「案２．」でも大差は無い。
２．価格不一致の場合
次ティックデータを待つ事になるけど、流動性が低く、マーケットが閉じる直前だと、
リスクとしては、「案１．」の方が安全。プログラムもシンプル。
ただし、機会損失というデメリットもある。
＃週を跨いでしまった結果、発注されないケースもあると思うので
３．プログラムバグ
「新規発注禁止状態」にする設計ポリシーだし、例えリトライしても意味が無い
ので、「案１．」しかない。
なので、「機会損失」というデメリットはあるものの、「案１．OrderClose/OrderDeleteする」の方がよさそう。
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
なので、「案１．」という結論にした場合の発注時の処理を整理すると以下。
【ＥＣＮタイプの場合の発注時の処理】
－－－－－－－－－－－－－－－－－－－－－－－－－－
１．OrderSend()失敗時は、次のティックデータ受信まで待つ
２．OrderModify()失敗時
・無条件にOrderClose()/OrderDelete()する
・警告レベルのログ出力と、メール通知。
３．OrderModify()失敗後のOrderClose()成功時
・通常レベルのログ出力と、クローズに成功した旨のメール通知
４．OrderModify()失敗後のOrderClose()失敗時
・警告レベルのログ出力と、メール通知。
・次のティックデータ受信時に再度試みる様にする
ちなみに、ＥＣＮタイプかそうでないかはＭＴ４のＡＰＩからは、わからないので、
プロパティ化して、該当プロパティがTRUEの時のみ上記処理にする。
－－－－－－－－－－－－－－－－－－－－－－－－－－
今まで勘だけで、「案１．OrderClose/OrderDeleteする」にしてたけど、ブログで改めて検討してみて、すっきりした。
それと、過去のブログ記事で書いた「OrderSelect問題」という仮説が発端となったstart()全体で排他制御する仕組みも、このケースでは有利に働く気がする。
つまり、OrderSend()後は速やかにOrderModify()したいけど、１つのＭＴ４で複数ＥＡを走らせていた場合、OrderSend()後に別のＥＡがオーダ関連処理を開始してしまって、OrderModify()がコンテキストビジーでなかなか処理を開始できない状況になる可能性がでてしまう。
でも、start()全体を排他利用する場合は、他に割り込まれる事が無いので、その分OrderModify()が遅延するリスクが減るから。
＃排他制御入れる前は、結構コンテキスト・ビジーが発生していたし
しかし、なんでこんなＭＴ４の仕様にしたのか。。
ＥＣＮが故という背景がよくわからない。
ＦＸ業者側の都合か？
それでもよくわからん。。
あと、指値／逆指値注文だと、この対処が不要という説もあるけど、事実関係は未だ不明。
テスターだと判らないっぽいし、デモ環境でどうなるかは、まだ試していない。
＃某ＦＸ業者のＭＴ４の手動発注画面を見てると、確かに成り行き注文の時だけ、ＳＬ／ＴＰを指定できなかったけど。
そして実際に作って、いつもとは違う、某ＦＸ業者のＭＴ４のテスター上で動かして見ると。
まったく動かん。
トレード回数ゼロ
結局何がおきてたかというと、以前のロット数計算に関する記事で、以下の問題が。
【ロット数計算方法の修正】
－－－－－－－－－－－－－－－－－－－－－－
以前のロット数計算に関する記事で、以下の部分が上手く動いていなかった。
●「１．１トレードあたりの証拠金利用率の局所化」の以下の記述。
・「１ロット当りの必要証拠金」（MODE_MARGINREQUIRED／MODE_MARGININIT
／MODE_MARGINMAINTENANCEのいづれか）を使って、極端なロット数を制限」
・「『「0』以外で、一番高い値を使うという事にしてみた。」その某ＦＸ業者の場合、「MODE_MARGININIT」と「MODE_MARGINMAINTENANCE」が、１０万ＵＳ＄というあり得ない値。さらに別のＦＸ業者のＭＴ４を見てみたら、両方ゼロ。
なので、ＦＸの場合は、「MODE_MARGINREQUIRED」が正解っぽい。
結局、 MarketInfo(Symbol() , MODE_MARGINCALCMODE)がゼロ（ＦＸ）以外の場合は、
クリティカル・エラー扱いにし、「MODE_MARGINREQUIRED」を使う様に修正。
なので、今回の共通部品はＦＸ以外で使えなくなりました。。－－－－－－－－－－－－－－－－－－－－－－
仕様をもっと明確にしてほしい。。
そして、ロジックを考えた事以外は他力本願な内容で、「FXシステムトレード初心者奮闘記」の「ＭＴ４用ＥＡ開発時代」は、新たなバグが出ない限り、「OrderSelect問題」仮説の検証に進むかもしれないのでした。
＃でもその前に前回記事の内容でＥＡ修正しなきゃ。。
0 件のコメント:
コメントを投稿