Come posso accedere alla tacchina da remoto? - pagina 5
Ti stai perdendo delle opportunità di trading:
- App di trading gratuite
- Oltre 8.000 segnali per il copy trading
- Notizie economiche per esplorare i mercati finanziari
Registrazione
Accedi
Accetti la politica del sito e le condizioni d’uso
Se non hai un account, registrati
и не должно наблюдаться.
дело в том, что эксперт вообще не сможет ходить чаще чем в 1 секунду за информацией. Так уж работают связки МT4 <-> wininet.dll<-> сервер.
Ну будет клиент долбить сервак запросами через каждую секунду. Ну и что? на то он и сервак, чтоб любой груз выдерживать. Представте как гуглы долбятся или вконтакте.
Я тестировал для проверки на 20 машинах + на каждой запущено по 3 терминала в этих связках запрос-ответ причем запросы при прогоне из тестера!
И вполне здорово себя чувствовали все участники эксперимента (и провайдер тоже :). Единственное, что медленно тест происходит. Тик обрабатывается раз в секунду. Но и это не такая большая проблема.
Поэтому такие системы (в которых некий блок кода вынесен в интернет) вполне рабочие.
Affinché il test funzioni correttamente in tale combinazione, scarico semplicemente i dati in un file separato con un timestamp nel nome del file. Di conseguenza, dopo la prima esecuzione, il tester impila tutti i dati nella directory. La seconda esecuzione è ancora più veloce che se i dati fossero nel database sulla macchina locale. Tuttavia, ci possono essere molti file.
А чтобы тест нормально отрабатывался в такой связке, я данные просто сбрасываю в отдельный файл с timestamp в названии файла. В итоге после первого прогона тестер складывает все данные в директории. Второй прогон уже летит даже быстрее чем если бы эти данные были в базе данных на локальной машине. Правда файлов может оказаться довольно много.
in linea di principio come opzione... è solo una via di mezzo tra il prendere tutti i dati in una volta o un po' alla volta ma spesso.
La cosa principale è che più preciso è il compito impostato, maggiore è la possibilità di ottimizzarlo in termini di velocità.
Ad esempio, per una linea di indicatore 250000 barre*8 byte (tempo della barra) + 8 byte (valore della linea) ~ 4 mb di informazioni.
1. Il tempo non è necessario per tutti gli indicatori.
2. Le citazioni possono essere compresse. Anche il tempo può essere compresso)))
3. non è necessario trasmettere tutte le citazioni ogni volta. C'è una variante più economica. Durante l'inizializzazione, l'indicatore si connette al server e trasmette una grande quantità di dati. Il server restituisce un qualche handle associato all'insieme di dati ricevuti e al client che ha ricevuto questi dati. Mentre l'indicatore lavora, invia periodicamente informazioni sulla barra zero per correggere la lettura corrente su di essa. Quando la barra si chiude, l'indicatore dovrebbe inviare le informazioni finali sulla barra al server che restituirà il valore della barra chiusa. Quando la connessione viene deinizializzata/rottamata, il server rilascia l'handle assegnato e distrugge l'insieme di dati (o no, come si vuole).
4. Inoltre, l'indicatore può memorizzare nella cache sul lato client i valori ricevuti dell'indicatore (possono essere memorizzati insieme al blocco di dati compressi, in base al quale sono calcolati).
UPD: Non è possibile ricalcolare l'indicatore su tutti i tick, perché molto spesso i tick sono nel flusso di +1 -1 -1 +1 -1 -1 - è davvero necessario calcolare l'indicatore solo 2 volte.
1. Время нужно не для всех индикаторов.
Sì, ma ora stiamo parlando di un caso generale.
2. Le citazioni possono essere compresse. Anche il tempo può essere compresso)))
Lanciami un'idea.
3. non è necessario trasmettere tutte le citazioni ogni volta. C'è una variante più economica. Durante l'inizializzazione, l'indicatore si connette al server e trasmette una grande quantità di dati. Il server restituisce alcuni handle associati all'insieme di dati ricevuti e al client che ha ricevuto questi dati. Mentre l'indicatore lavora, invia periodicamente informazioni sulla barra zero per correggere la lettura corrente su di essa. Quando la barra si chiude, l'indicatore dovrebbe inviare le informazioni finali sulla barra al server che restituirà il valore della barra chiusa. Quando la connessione viene deinizializzata/rottamata, il server rilascerà l'handle assegnato e distruggerà l'insieme di dati (o no, come si vuole).
Non è chiaro come possa accelerare il trasferimento dei dati sulla linea indotta.
4. Inoltre, l'indicatore può memorizzare nella cache sul lato client i valori dell'indicatore ricevuti (possono essere memorizzati insieme al blocco di dati compressi, in base al quale sono calcolati).
simile a come è già implementato in MT - IndicatorCounted(). Io prescriverei una mia funzione simile per tali scopi.
UPD: Potresti non ricalcolare affatto l'indicatore su tutti i tick, perché molto spesso i tick sono nel flusso di +1 -1 -1 -1 -1 -1 - infatti hai solo bisogno di calcolare l'indicatore 2 volte.
In altre parole - ora abbiamo iniziato a risolvere un problema per gli induttori. Sincronizzazione e trasmissione delle barre della storia :)
Forse dovremmo proporre loro di fare un tale servizio per noi!
È un'idea interessante: lasciare che il server memorizzi uno strumento con lo stesso prezzo di apertura/chiusura/alto/alto. E anche i volumi. Sarà scaricato e sincronizzato secondo tutte le regole generali, come tutte le valute. E può essere usato come una linea di induttori.
Può valere la pena di scavare in questa direzione nella documentazione tecnica della sincronizzazione delle barre.
1) fare uno screenshot del grafico con l'indicatore
2) Carica il file dello screenshot sul tuo server HTTP
3) Gli utenti accedono con il loro login/password e guardano l'immagine.
Ma questo va bene solo quando hai bisogno di guardare l'indicatore. :(
3. non è necessario trasmettere tutte le citazioni ogni volta. C'è una variante più economica. Durante l'inizializzazione, l'indicatore si collega al server e trasmette una grande quantità di dati. Il server restituisce alcuni handle associati all'insieme di dati ricevuti e al client che ha inviato questi dati. Mentre l'indicatore lavora, invia periodicamente informazioni sulla barra zero per correggere la lettura corrente su di essa. Quando la barra si chiude, l'indicatore dovrebbe inviare le informazioni finali sulla barra al server che restituirà il valore della barra chiusa. Alla deinizializzazione/interruzione della connessione, il server rilascerà l'handle assegnato e distruggerà l'insieme di dati (o no, come preferite).
Variante disgustosa - quando si avvia l'intero sistema rallenta con il terminale o si deve aspettare molto tempo per caricare (alcuni sistemi usano ancora canali lenti, per esempio la naftalina). È molto meglio scaricare le informazioni in piccoli pezzi e salvare la cronologia sulla macchina dell'utente in modo che solo le informazioni fresche siano inviate al traffico come viene fatto nelle ultime versioni: http: //xrust.land.ru/download/
Подкиньте идейку
Il primo elemento della serie è memorizzato esplicitamente. Poi differenziamo la serie e usiamo la codifica dell'entropia.
Variante disgustosa
Anche nel caso della DLL, è auspicabile dare le informazioni in pezzi in modo che il consumatore non debba aspettare ("PERCHE'?"), ed è bello alla fine :)
Anche nel caso della DLL è auspicabile dare le informazioni in pezzi in modo che il consumatore non soffra una lunga attesa ("Perché?"), ed è bello alla fine :)
Il caricamento in background/asincrono come lo intendo io implica.È quello che sto dicendo...