"DLL'leri Kullanmadan Adlandırılmış Kanalları Kullanarak MetaTrader 5 ile İletişim Kurma" makalesi için tartışma

Yeni yorum
 

Yeni makale DLL'leri Kullanmadan Adlandırılmış Kanalları Kullanarak MetaTrader 5 ile İletişim Kurma yayınlandı:

Birçok geliştirici aynı sorunla karşı karşıyadır: Güvenli olmayan DLL'ler kullanmadan alım satım terminali korumalı alanına nasıl ulaşılır? En kolay ve en güvenli yöntemlerden biri, normal dosya işlemleri gibi çalışan standart Adlandırılmış Kanalları kullanmaktır. Bunlar, programlar arasında işlemciler arası istemci-sunucu iletişimini düzenlemenize olanak tanır. C++ ve MQL5'te sunucu, istemci, bunlar arasındaki veri alışverişini ve performans karşılaştırmasını içeren pratik örneklere bir göz atın.

En kolay ve en güvenli yöntemlerden biri, normal dosya işlemleri gibi çalışan standart Adlandırılmış Kanalları kullanmaktır. Bunlar, programlar arasında işlemciler arası istemci-sunucu iletişimini düzenlemenize olanak tanır. Bu konuda, yani DLL'lere erişimin mümkün olduğunu gösteren halihazırda yayınlanmış bir makale olmasına rağmen Adlandırılmış Kanalları kullanarak MetaTrader 5 terminalleri arasında iletişim kurmak için DLL içermeyen bir çözüm, istemci terminalinin standart ve güvenli özelliklerini kullanacağız.

Adlandırılmış kanallar hakkında daha fazla bilgiyi MSDN kitaplığında bulabilirsiniz, ancak biz pratik C++ ve MQL5 örneklerine geçeceğiz. Aralarında sunucu, istemci, veri alışverişi uygulayacağız ve ardından performansı kıyaslayacağız.

Yazar: MetaQuotes

 
Test cihazında pipler çalışıyor mu?
 
Graff:
Test cihazında borular çalışır mı?

Farklı terminaller arasındaki iletişim neden test cihazında çalışmalıdır?

Olaylar aracılığıyla yapın, test cihazında çalışırlar.

 
Urain:

Neden farklı terminaller arasındaki iletişim test cihazında çalışmalı?

Neden olmasın? Denemelisiniz. Ama nedenini bilmiyorum... :)


Olaylar aracılığıyla yapın, test cihazında çalışırlar.

Olaylar aracılığıyla ne? Terminaller arasında iletişim mi?

;)

 

Adlandırılmış boru hatları yerel aracılarda çalışır, ancak kümelerde devre dışı bırakılır.

Yani, hem bireysel testler hem de toplu yerel aracılar üçüncü taraf (yalnızca yerel değil) bir pip sunucusuna bağlanabilir.

 
MetaDriver:
Neden olmasın? Denemeye değer. Nedenini bilmiyorum. :)


olaylar aracılığıyla ne? terminaller arasındaki iletişim?

;)

Sorunun özüne inin, eğer bir kişinin test cihazındaki programlar arasında iletişime ihtiyacı varsa, o zaman bir terminaldeki programlar arasında veri aktarımı görevi görülebilir ve tüm bu saçmalıkları atlayarak olaylar aracılığıyla yapılabilir, cevabım oldukça mantıklı.
 
Urain:
Bir kişinin test cihazındaki programlar arasında iletişime ihtiyacı varsa, o zaman bir terminaldeki programlar arasında veri aktarımı görevi açıktır ve bu, tüm bu saçmalıkları atlayarak olaylar aracılığıyla yapılabilir, cevabım oldukça mantıklı.
İşin içine girdim, bana sadece test sürecini harici bir programdan izlemekle ilgileniyormuş gibi geldi.
 

Hızlı bir bakışta, bunu kullanmanın iki yolu vardır:

Ve bu konudaki makaleler ilginç olacaktır.

 
Rosh:

Hızlı bir bakışta, bunu kullanmanın iki yolu vardır:

Ve bu konuyla ilgili makaleler ilginç olacaktır.

Ne yazık ki bu sadece Windows için C'de nasıl programlanacağını bilenler için mümkündür, çünkü:

Renat:
Sadece bunun istemci desteği olduğunu ve sunucu bağlayıcılarının terminalde oluşturulamayacağını unutmayın.

Yani istemci-sunucu teknolojilerinde iki istemci sunucu aracılığı olmadan birbirlerini göremezler. Diğer programlama dillerinde adlandırılmış kanallar oluşturma konusuna baktım, ancak ne yazık ki, çoğunda standart yollarla Windows için bir istemci oluşturabilirsiniz, ancak Unix için kanallar neredeyse her yerde sorunsuz bir şekilde oluşturulur.

Algoritmaya göre iki adlandırılmış kanalı full-duplex bağlayabilecek EXE-kabukları şeklinde ağ geçitlerine ihtiyacımız var:

  1. A ve B adında iki kanal oluşturun
  2. Bağlantı için A kanalını dinleyen ilk alt işlemi oluşturun.
  3. Mesaj bekleyen bir istemci A kanalına bağlandıktan sonra, bağlantı için B kanalını dinleyen ikinci bir alt süreç oluşturun.
  4. İlk alt süreç, A kanalından B kanalına bir döngü içinde bir bayt akışı aktarmak için açılır
  5. Bir istemci B kanalına bağlanır bağlanmaz, ikinci alt işlem bayt akışını B kanalından A kanalına bir döngü içinde okumak üzere başlatılır.
  6. İkinci istemci ilk mesajı B kanalından A kanalına iletmeye başlar.
  7. ve bu böyle devam eder, ta ki bir müşteri düşene kadar, sonrasında her iki kanal da yok olur ve 1. noktaya geçeriz. 1

Elbette, tek görevli MQL komut dosyalarında tam çift yönlü gerekli değildir, çünkü istemciler bilgileri eşzamansız olarak alamaz ve iletemez. Ancak half-duplex yalnızca sunucunun değişim protokolünü bildiği ve karşı moda geçmek için bir istemciden diğerine alım-iletimin nerede bittiğini kolayca hesaplayabildiği durumlar için uygundur. Eğer bunu bilmiyorsa, çünkü telepatik yetenekleri yoktur ve bu sadece kendileri tarafından bilinen protokolü kullanarak birbirleriyle alışveriş yapan istemciler tarafından biliniyorsa, o zaman iki alt süreçli bir tam dubleks gereklidir. Böyle bir ağ geçidi uygundur çünkü her istemcinin başka bir istemciyle iletişim için yalnızca bir kanalı vardır ve ilk döngüde bağlantı olasılığını kesinlikle kontrol edecekse, istemci tarafındaki bağlantı sırası herhangi bir rol oynamaz. Ağ geçidi algoritması, protokole göre ilk olan istemcinin bağlantı olasılığını hariç tutar, ikinci istemci bağlanmadan önce bir mesaj iletmelidir ve boşluğa iletim gerçekleşmeyecektir.

Teorik olarak, adlandırılmış kanalların sayısı sınırsız olduğundan, algoritmaya göre tek görevli bir simpleks ağ geçidi oluşturmak mümkün olacaktır:

  1. Ağ geçidinden istemciye iletim için ilk adlandırılmış kanal oluşturulur
  2. İlk istemci bağlantı kurduktan sonra, istemciden mesaj almak için ikinci bir kanal oluşturulur
  3. Verici istemci ikinci kanala bağlandıktan sonra, işlem bayt akışını alıcı kanaldan verici kanala doğru döngüye sokar.
  4. Bir istemci bağlantıyı keser kesmez her iki kanalı da kaldırır ve 1. adıma geçeriz.

Bu durumda, iki istemciyi half-duplex olarak bağlamak için bu tür iki ağ geçidine veya yalnızca simplex kullanılıyorsa bir ağ geçidine ihtiyacınız olacaktır. Tam çift yönlü ağ geçidine kıyasla dezavantajı, MQL komut dosyalarında iki kanal (alım ve iletim için) yazmanız ve bunlarda da bağlantı sırasını kesinlikle gözlemlemeniz gerekmesidir: önce alım ve sonra iletim için (aksi takdirde ikinci kanal asla oluşturulmayacaktır). Bu ağ geçidinin algoritması, ikinci istemci bağlanmadan önce bir mesaj iletmesi gereken protokole göre ilk olan bir istemciyi bağlama olasılığını da dışlar ve boşluğa iletim gerçekleşmez.

Doğal olarak, ağ geçitleri, örneğin başlangıçta komut satırı aracılığıyla, alıcı-verici ve bağlanan istemcilerin sırasına bağlı olarak kanal adlarını yapılandırma imkanı sağlamalıdır.

C dilinde programlama yapan biri bu tür ağ geçitleri oluşturup bunları EXE'lere derler ve burada yayınlarsa, diğer programlama dillerinde tef olmadan standart MQL5 araçlarını kullanarak komut dosyaları, Uzman Danışmanlar ve göstergeler arasında bağlantılar oluşturmak kolay olacaktır.

Teorik olarak, MQL dışındaki dillerde sunucular oluşturmamak için istemcileri bu tür ağ geçitlerine nasıl düzgün bir şekilde bağlayacağınıza dair bir makale de yazabilirsiniz (muhtemelen C'de programlayamayan tek kişi ben değilim, değil mi?) Bir C programcısı ile ortak yazarlıkta belirli örneklerle. Yani, benden makalenin metni ve MQL'deki örnekler ve C-sh programcısından C ve EXE-shniki'deki ağ geçitlerinin kaynakları. Ücret paylaşılacaktır.

 
Bu arada, örnekler kimseyi beklemenize gerek olmayan tam çift yönlü alışverişi göstermektedir.

Sunucu basittir, /release dizinindeki derlenmiş exe dosyası da dahil olmak üzere hepsi kaynaklarda bulunmaktadır. Testler kolayca tekrarlanabilir.
 
Renat:
Bu arada, örnekler kimseyi beklemek zorunda olmadığınız tam çift yönlü değişimi göstermektedir.

Sunucu basittir, /release dizinindeki derlenmiş exe dosyası da dahil olmak üzere hepsi kaynaklarda bulunmaktadır. Testler kolayca tekrarlanabilir.

Mesele bu değil. Örneğinizi çalıştırmayı denedim. Çalışıyor. Ancak hiçbir faydası yok, yani denedim ve hepsi bu, silinebilir çünkü artık gerekli değil.

Bir yandan dll'den kurtuldunuz, ancak diğer yandan yine uygulama kullanımı için diğer programlama dillerinde koltuk değneklerine ihtiyacınız var.

Önerilen yöntemin dezavantajı, yalnızca MQL dışındaki dillerde uygulama geliştiren ve Windows API'sini destekleyen programcılar için uygun olmasıdır. Yani, önerilen örnek evrensel değildir ve değişiklik yapılmadan diğer görevlere uyarlanamaz. Ve herkesin farklı görevleri vardır. Ve bu, kullanıcıların MQL'e ek olarak başka bir dilde çalışmak için iki komut dosyası arasında temel bir bilgi alışverişi bile oluşturmaları gerekeceği anlamına gelir; bunun üzerine, değişim protokolüyle ilgili bazı mantıkları yazmanız gereken bir sunucu oluşturmak için.

Ağ geçitlerini bir kez oluşturmayı, derlemeyi ve tüm gelenler için yayınlamayı öneriyorum, böylece herhangi bir kullanıcı yalnızca standart MQL araçlarını kullanarak bağlantılar oluşturabilir.

Örneğin, benim için açık ya da kapalı ham dosyaların C dilinde olması fark etmez. Çünkü C dilinde hiçbir şey yazmıyorum ve uçuşları sıralamak zaman alacak. Aynı ham dosyaları derleyemiyorum bile. Saf Java'da ve diğer birçok programlama dilinde, standart araçları kullanarak dosya akışları aracılığıyla yalnızca istemci bağlantısı oluşturabilirsiniz. En azından simpleks ile iki adlandırılmış kanalı birbirine bağlayan bir ağ geçidi olsaydı, hiçbir sorun olmazdı. Değişim protokolünü istemcilere yazardım, birkaç ağ geçidi üzerinden bağlanırdım, hata ayıklardım ve her şey çalışırdı. Yani her görev için ayrı bir sunucu tasarlamaya ve oluşturmaya gerek yok.

Ve şu anda, yani ağ geçitleri olmadan, birçok insan C için bir geliştirme ortamı kurmak, yeni bir programlama dili öğrenmek vb. zorunda kalacak.

Ağ geçidinin umurunda değildir: bir istemciden aldığını diğerine gönderir. Mantık aptalcadır, ancak iki istemciyi herhangi bir ek koltuk değneği olmadan birleştirmeye ve tefle dans etmeye izin verir, yani evrenseldir ve bilgi alışverişi protokolünden ve C dili bilgisinden bağımsızdır.

Burada, dedikleri gibi, tok açın halinden anlamaz. C'de bir şeyler geliştirenlerin herhangi bir sorun görmesi pek olası değildir. Ve geri kalanımız için, bu sistemle istediğimiz gibi başa çıkabiliriz.

1234567
Yeni yorum