Türkiye'ye uzaktan erişim nasıl yapılır? - sayfa 5

 
sergeev >> :

ve izlenmemelidir.

gerçek şu ki bir uzman bilgi almak için 1 saniyeden fazla yürüyemez. MT4 <-> wininet.dll <-> sunucu paketleri bu şekilde çalışır.

İstemci, sunucuyu her saniye isteklerle çekiçleyecektir. Ne olmuş? bu yüzden her türlü yüke dayanabilecek bir sunucudur. Google'ın nasıl çekiçlediğini veya VKontakte'yi hayal edin.

Bu istek-yanıt paketlerinde her biri 3 terminal çalıştıran 20 makinede + doğrulama için test ettim ve test cihazından çalıştırırken istekler!

Ve deneydeki tüm katılımcılar oldukça havalı hissettiler (ve sağlayıcı da :). Tek şey, testin yavaş olmasıdır. Bir onay saniyede bir işlenir. Ama bu da o kadar büyük bir sorun değil.

Bu nedenle, bu tür sistemler (İnternette belirli bir kod bloğunun yayınlandığı) oldukça çalışıyor.


Ve testin böyle bir pakette normal şekilde çalışması için, verileri dosya adında bir zaman damgası olan ayrı bir dosyaya döküyorum. Sonuç olarak, ilk çalıştırmadan sonra test cihazı dizindeki tüm verileri toplar. İkinci çalıştırma, bu verilerin yerel makinedeki veritabanında bulunmasından bile daha hızlı uçar. Gerçek dosyalar oldukça fazla olabilir.

 
sol >> :

Ve testin böyle bir pakette normal şekilde çalışması için, verileri dosya adında bir zaman damgası olan ayrı bir dosyaya döküyorum. Sonuç olarak, ilk çalıştırmadan sonra test cihazı dizindeki tüm verileri toplar. İkinci çalıştırma, bu verilerin yerel makinedeki veritabanında bulunmasından bile daha hızlı uçar. Gerçek dosyalar oldukça fazla olabilir.

prensipte, bir seçenek olarak ... bu, tüm verileri bir seferde veya biraz ama sık sık alma arasındaki bir geçiştir.

Ana şey, görev ne kadar doğru olursa, hız açısından optimize etme şansı o kadar artar.

 
sergeev писал(а) >>
örneğin, göstergenin bir satırı için 250.000 çubuk * 8 bayt (çubuk zamanı) + 8 bayt (satır değeri) ~ 4 MB bilgi.

1. Tüm göstergelerin zamana ihtiyacı yoktur.
2. Alıntılar sıkıştırılabilir. Zaman da sıkıştırılabilir
3. Her seferinde tüm alıntıları iletmek gerekli değildir. Daha ekonomik bir seçenek var. Başlatma sırasında, gösterge sunucuda oturum açar ve büyük miktarda veri aktarır. Sunucu, alınan veri seti ve bu verileri gönderen istemci ile ilişkili bazı tanıtıcıları döndürür. Çalışma sırasında gösterge, üzerindeki mevcut okumaları düzeltmek için periyodik olarak sıfır çubuğunun göstergeleri hakkında bilgi gönderir. Çubuğun kapanması sırasında, gösterge, çubukla ilgili son bilgileri sunucuya göndermeli ve bu, kapatılan çubuğun değerini döndürecektir. Bağlantıyı başlatırken/bağlantıyı keserken, sunucu tahsis edilen tanıtıcıyı serbest bırakır ve veri setini yok eder (veya istediğiniz gibi serbest bırakmaz).
4. Ayrıca gösterge, alınan gösterge değerlerini istemci tarafında önbelleğe alabilir (bunlar hesaplandıkları sıkıştırılmış veri bloğu ile birlikte saklanabilir).
UPD: Genel olarak, tüm kenelerdeki göstergeyi yeniden hesaplamak mümkün değildir, çünkü çok sık +1 -1 +1 -1 +1 -1 gibi akışı tıklar - aslında göstergeyi yalnızca 2 kez hesaplamanız gerekir.

 
lea >> :

1. Tüm göstergelerin zamana ihtiyacı yoktur.

Evet. ama şimdi genel durumdan bahsediyoruz.

2. Alıntılar sıkıştırılabilir. Zaman da sıkıştırılabilir

bir fikir atın

3. Her seferinde tüm alıntıları iletmek gerekli değildir. Daha ekonomik bir seçenek var. Başlatma sırasında, gösterge sunucuda oturum açar ve büyük miktarda veri aktarır. Sunucu, alınan veri seti ve bu verileri gönderen istemci ile ilişkili bazı tanıtıcıları döndürür. Çalışma sırasında gösterge, üzerindeki mevcut okumaları düzeltmek için periyodik olarak sıfır çubuğunun göstergeleri hakkında bilgi gönderir. Çubuğun kapanması sırasında, gösterge, çubukla ilgili son bilgileri sunucuya göndermeli ve bu, kapatılan çubuğun değerini döndürecektir. Bağlantıyı başlatırken/bağlantıyı keserken, sunucu tahsis edilen tanıtıcıyı serbest bırakır ve veri setini yok eder (veya istediğiniz gibi serbest bırakmaz).

bu biraz belirsiz, türkiye hattı ile ilgili veri aktarımını nasıl hızlandırabilir.

4. Ayrıca gösterge, alınan gösterge değerlerini istemci tarafında önbelleğe alabilir (bunlar hesaplandıkları sıkıştırılmış veri bloğu ile birlikte saklanabilir).
MT - IndicatorCounted() içinde zaten uygulandığı için benzetme yoluyla. Bu amaçlar için kendi benzer işlevimi yazardım.
UPD: Genel olarak, tüm kenelerdeki göstergeyi yeniden hesaplamak mümkün değildir, çünkü çok sık +1 -1 +1 -1 +1 -1 gibi akışı tıklar - aslında göstergeyi yalnızca 2 kez hesaplamanız gerekir.

Yani artık hindiler için sorunu çözmeye başladık. hangi metakotalar çok uzun zaman önce karar verdi. Tarih çubuklarının senkronizasyonu ve aktarımı :)
Belki de böyle bir hizmeti evde yapmaları için bir teklif yapmanız gerekiyor!
Bu ilginç bir düşünce. açılış/kapanış fiyatı/yüksek/düşük eşit olan böyle bir enstrümanı bir sunucunun saklamasına izin verin. Ve hacim de. Tüm para birimleri gibi tüm genel kurallara göre yüklenecek ve senkronize edilecektir. Ve sonra bir dizi indükleyici olarak kullanılabilir.

Çubukları senkronize etmek için teknik belgelerde muhtemelen bu yönde kazmaya değer.

 
Ayrıca oldukça sapkın bir çözüm var:
1) göstergeli grafiğin ekran görüntüsünü alın
2) ekran görüntüsü dosyasını HTTP sunucunuza yükleyin
3) kullanıcılar giriş bilgileri / şifreleri ile giriş yapar ve resme bakar
gerçek sadece türkiye'ye bakmanız gerektiğinde durum için uygundur. eğer kendi başına bitirebileceğin başka bir şey varsa, o zaman... :(
 
lea писал(а) >>
3. Her seferinde tüm alıntıları iletmek gerekli değildir. Daha ekonomik bir seçenek var. Başlatma sırasında, gösterge sunucuda oturum açar ve büyük miktarda veri aktarır. Sunucu, alınan veri seti ve bu verileri gönderen istemci ile ilişkili bazı tanıtıcıları döndürür. Çalışma sırasında gösterge, üzerindeki mevcut okumaları düzeltmek için periyodik olarak sıfır çubuğunun göstergeleri hakkında bilgi gönderir. Çubuğun kapanması sırasında, gösterge, çubukla ilgili son bilgileri sunucuya göndermeli ve bu, kapatılan çubuğun değerini döndürecektir. Bağlantıyı başlatırken/bağlantıyı keserken, sunucu tahsis edilen tanıtıcıyı serbest bırakır ve veri setini yok eder (veya istediğiniz gibi serbest bırakmaz).

İğrenç seçenek - başlangıçta, tüm sistem terminalle birlikte yavaşlar veya yükleme için çok uzun bir süre beklemeniz gerekir (bazıları hala yavaş kanallarda oturur - örneğin, mophil ağları). Bilgileri küçük parçalar halinde indirmek, geçmişi kullanıcının makinesinde tutmak çok daha uygundur, bu nedenle bunun en son sürümlerinde kararlaştırıldığı gibi yalnızca yeni bilgiler trafiğe girer: http://xrust.land.ru/download/

 

Подкиньте идейку


Serinin ilk elemanı açıkça saklanır. Ardından, serileri farklılaştırıyoruz ve entropi kodlamasını kullanıyoruz.


iğrenç seçenek

Bu sadece temel ilkedir. Bilgileri bir çok farklı yolla indirebilir ve aktarabilirsiniz. Dll ile uygulama durumunda arka plan/zaman uyumsuz yükleme hakkında sessizim.
 

DLL söz konusu olduğunda bile, bilgilerin parçalar halinde verilmesi arzu edilir ve tüketici beklenti içinde pes etmez ("NEDEN?" gibi aptal sorular sormaz) ve sonuçta güzeldir :)

 
xrust писал(а) >>

DLL söz konusu olduğunda bile, bilgilerin parçalar halinde verilmesi arzu edilir ve tüketici beklenti içinde pes etmez ("NEDEN?" gibi aptal sorular sormaz) ve sonuçta güzeldir :)


Anladığım kadarıyla arka plan/eşzamansız yükleme bunu ima ediyor.
 

Ben de bundan bahsediyorum...