OrderSendAsync() işlevi - sayfa 5

[Denis Kirichenko]

Urain :

Teklifiniz yalnızca mevcut işlevi tamamlayacaksa, o zaman hiçbir şey olmaz, aksi takdirde basit MqlPacketTradeRequest yapısının nasıl olduğu açık değildir ...

... farklı siparişler için istek gönderebilecek, ancak MqlPacketTradeRequest yapısı dinamik bir MqlTradeRequest yapıları dizisinin yapısıysa, bu, basit istek yapıları için tasarlanmış sunucunun tüm mantığını bozabilir.

başka bir deyişle, uçbirim düzeyinde, bu paketin ayrı isteklere bölünmesi gerekecektir, bu da bu aşırı yüklenmenin tüm amacını geçersiz kılar.

Eşzamansızlık nedeniyle bu seçenek üzerinde "anlaştık" gibi görünüyor:

 bool   OrderSendAsync(
   MqlPacketTradeRequest &  packet_request,       // пакетная структура запроса
   );

nerede,

package_request, diğer şeylerin yanı sıra, bir dizi MqlTradeRequest yapısını içerecektir ...

O zaman tüm bu düşünceler tartışma için hammaddedir :-)

[Yedelkin]

Urain :

IMHO, aynı uygulamalar paketi sadece gösteri için gereklidir, farklı semboller için uygulamalar, farklı hacimlerde ve elbette, iş için farklı yönler kullanılacaktır. Ve bu nedenle, her talebin ayrı ayrı kontrol edilmesi gerekecek, bu yüzden onları bir paket halinde göndermenin bir anlamı yok .

Pekala, burada seçmeniz gerekiyor: ya bir kerede 10008 dönüş kodu için tek bir kontrolle önceden doldurulmuş 500 elemanlık bir istek[] dizisi gönderen OrderSendPacketAsync işlevini bir kez çalıştırın ( MqTradeRequest& request [] , MqlPacketTradeResult& package_result ) veya OrderSendAsync() işlevini 10008 dönüş kodu için 500 kontrolle 500 kez çalıştırın .

[Yedelkin]

Urain :

... MqlPacketTradeRequest yapısı, dinamik bir MqlTradeRequest yapısı dizisinin yapısıysa, bu, basit istek yapıları için tasarlanmış sunucunun tüm mantığını bozabilir.

Dinamik bir dizi kullanan bir ticaret talebi nasıl "sunucu mantığını bozabilir"? Belirli bir yapı türünden bir değişkeni işleyen bir bloğum varsa, o zaman gerekirse bu bloğu aynı türdeki bir dizinin her bir öğesine uygulamamı engelleyen nedir? Benzer şekilde, bugün "sunucu basit istek yapıları için keskinleştirildiyse", o zaman sunucu OrderSendPacketAsync () işlevi tarafından gönderilen dinamik bir diziyi kabul ettiğinde, birinin "basit istek için uyarlanmış" bir blok uygulamasına izin verecek bir döngü eklenmesini engelleyen şey sırayla böyle bir dizinin her bir elemanına "yapılar"?

[Yedelkin]

papaklass :

Bana göre OrderSendAsync() işlevi, sipariş göndermek için bir döngü düzenlemek yerine parametrik hale getirilmelidir. Örneğin, OrderSendAsync(Symbol(), sayı, yön). Parametre olarak: - sembol, -emir sayısı , - emirlerin yönü (al, sat).

Bu, dinamik bir dizi ve OrderSendPacketAsync() işlevi kullanılarak bir kerelik toplu ticaret talebinin gönderilmesine ilişkin özel bir duruma benzer; dinamik dizinin her bir öğesi için " sembol" ve " tür" alanları aynı olduğunda.

[Yedelkin]

Asenkron ticaret işlemleri yaparken, şu veya bu talebin nasıl çalıştığını tam olarak bilmiyoruz. Özellikle, asenkron isteklerden biri kısmen yürütüldüğünde yerine getirilmeyen ne kadar kaldığını bilmiyoruz.

Söyleyin bana, hem Forex'te işlem yaparken hem de döviz piyasasında işlem yaparken, geçmişten gelen bir emrin mülkiyetinin olduğunu doğru anlıyor muyum?

ORDER_VOLUME_CURRENT

iş listesi

zaman uyumsuz isteğin ne kadar eksiksiz tamamlandığını açık bir şekilde belirlemenize izin veriyor mu? Yani, Forex'te bir piyasa emri asenkron olarak gönderildiğinde, o zaman tarihte göründüğünde, ORDER_VOLUME_CURRENT==0.0 ise, emrin tamamen gerçekleştiğinin ve ORDER_VOLUME_CURRENT'in içinde olmayan bir emir içerdiğinin garanti edilebileceği doğru mu? sıfır değer, o zaman bu değer böyle bir forex piyasası emri için doldurulmamış bir hacim olarak kabul edilmelidir?

Soru şu gerçeğinden kaynaklanmaktadır: https://www.mql5.com/ru/forum/3775/page28#comment_84851 ORDER_VOLUME_CURRENT özelliğinin borsada kullanılan emirleri ifade ettiği gerçeğine vurgu yapılır.

[Yedelkin]

Eşzamansız bir istekle ilgili bilgilerin geçmişindeki görünümle ilgili soru.

OrderSendAsync() işlevi true değerini döndürdüğünde ve sonuç.retcode alanı 10008 kodunu içerdiğinde, bu durumda, El Kitabına göre, bu "yalnızca gönderme gerçeği anlamına gelir, ancak isteğin ticaret sunucusuna ulaştığına dair herhangi bir garanti vermez. "

Soru: Eğer terminal tarafından eşzamansız bir istek başarıyla gönderildiyse, ancak sunucuya ulaşmadıysa, böyle bir istekle ilgili bilgiler her zaman geçmişe mi girer? Başka bir deyişle, eşzamansız bir istek başarıyla (tüm önlemlerle) sunucuya gönderilir, ancak bununla ilgili bilgiler geçmişte görünmez mi? Böyle bir senaryo mümkünse, hangi koşullar altında?

[Renat Fatkhullin]

Yedelkin :

Soru: Eğer terminal tarafından eşzamansız bir istek başarıyla gönderildiyse, ancak sunucuya ulaşmadıysa, böyle bir istekle ilgili bilgiler her zaman geçmişe mi girer? Başka bir deyişle, eşzamansız bir istek başarıyla (tüm önlemlerle) sunucuya gönderilir, ancak bununla ilgili bilgiler geçmişte görünmez mi? Böyle bir senaryo mümkünse, hangi koşullar altında?

İstek sunucuya ulaşmadıysa, istemci terminalinde görünme şansı yoktur.

[Yedelkin]

Renat :
İstek sunucuya ulaşmadıysa, istemci terminalinde görünme şansı yoktur.

TEŞEKKÜR! Başarıyla gönderilen bir eşzamansız isteğin kolayca kaybolabileceği ve geçmişe giremeyeceği ortaya çıktı.

[---]

Yedelkin :
TEŞEKKÜR! Başarıyla gönderilen bir eşzamansız isteğin kolayca kaybolabileceği ve geçmişe giremeyeceği ortaya çıktı.

hayır.

[Renat Fatkhullin]

Yedelkin :
Başarıyla gönderilen bir eşzamansız isteğin kolayca kaybolabileceği ve geçmişe giremeyeceği ortaya çıktı.

Eşzamansız isteğin pratik olarak "başarıyla gönderildi" durumu vermediği nokta budur.

İşlevin başarıyla tamamlanması yalnızca "müşterinin bakış açısından siparişin doğru göründüğü ve ağ hattına atıldığı, OnTrade'de cevabı bekleyin" anlamına gelir.