How do I access the turkey remotely? - page 5
You are missing trading opportunities:
- Free trading apps
- Over 8,000 signals for copying
- Economic news for exploring financial markets
Registration
Log in
You agree to website policy and terms of use
If you do not have an account, please register
и не должно наблюдаться.
дело в том, что эксперт вообще не сможет ходить чаще чем в 1 секунду за информацией. Так уж работают связки МT4 <-> wininet.dll<-> сервер.
Ну будет клиент долбить сервак запросами через каждую секунду. Ну и что? на то он и сервак, чтоб любой груз выдерживать. Представте как гуглы долбятся или вконтакте.
Я тестировал для проверки на 20 машинах + на каждой запущено по 3 терминала в этих связках запрос-ответ причем запросы при прогоне из тестера!
И вполне здорово себя чувствовали все участники эксперимента (и провайдер тоже :). Единственное, что медленно тест происходит. Тик обрабатывается раз в секунду. Но и это не такая большая проблема.
Поэтому такие системы (в которых некий блок кода вынесен в интернет) вполне рабочие.
In order for the test to work properly in such a combination, I simply dump the data into a separate file with a timestamp in the file name. As a result, after the first run, the tester stacks all the data in the directory. The second run goes even faster than if the data were in the database on the local machine. However, there may be quite a lot of files.
А чтобы тест нормально отрабатывался в такой связке, я данные просто сбрасываю в отдельный файл с timestamp в названии файла. В итоге после первого прогона тестер складывает все данные в директории. Второй прогон уже летит даже быстрее чем если бы эти данные были в базе данных на локальной машине. Правда файлов может оказаться довольно много.
in principle as an option... is just something in between taking in all the data at once or a little at a time but often.
The main thing is that the more precise the task set, the better the chance of optimising it in terms of speed.
e.g. for one indicator line 250000 bars*8 bytes (bar time) + 8 bytes (line value) ~ 4 mb of info.
1. Time is not necessary for all indicators.
2. Quotes can be compressed. Time can also be compressed)))
3. it is not necessary to transmit all quotes every time. There is a more economical variant. During initialization, the indicator logs to the server and transmits a large chunk of data. The server returns some handle associated with the received data set and the client that received this data. While the indicator is working, it periodically sends information about the zero bar in order to correct the current reading on it. When the bar is closing, the indicator should send the final information about the bar to the server that will return the value for the closed bar. When the connection is deinitialised/broken, the server will release the allocated handle and destroy the data set (or not, as one likes).
4. In addition, the indicator can cache on the client side the received values of the indicator (they can be stored together with the compressed data block, according to which they are calculated).
UPD: You can not recalculate the indicator at all on all ticks, because very often the ticks are in the flow of +1 -1 -1 +1 -1 -1 - you really need to calculate the indicator only 2 times.
1. Время нужно не для всех индикаторов.
Yes, but now we are talking about a general case.
2. Quotes can be compressed. Time can also be compressed)))
Throw me an idea.
3. it is not necessary to transmit all quotes every time. There is a more economical variant. During initialization, the indicator logs to the server and transmits a large chunk of data. The server returns some handle associated with the received data set and the client that received this data. While the indicator is working, it periodically sends information about the zero bar in order to correct the current reading on it. When the bar is closing, the indicator should send the final information about the bar to the server that will return the value for the closed bar. When the connection is deinitialised/broken, the server will release the allocated handle and destroy the data set (or not, as one likes).
This is a little unclear how it can speed up the transfer of data about the induced line.
4. In addition, the indicator can cache on the client side the received indicator values (they can be stored together with the compressed data block, according to which they are calculated).
similar to how it is already implemented in MT - IndicatorCounted(). I would prescribe my own similar function for such purposes.
UPD: You may not recalculate the indicator at all on all ticks, because very often the ticks are in the flow of +1 -1 -1 -1 -1 -1 - in fact you only need to calculate the indicator 2 times.
In other words - we have started to solve a problem for inductors now. Synchronizing and transmitting history bars :)
Maybe we should propose them to make such a service for us!
It's an interesting idea. Let the server store an instrument with equal open/close/high/lo price. And the volumes too. It will be downloaded and synchronized according to all general rules, like all currencies. And it can then be used as a line of inducators.
It may be worth digging in this direction in the technical documentation of bar synchronization.
1) make a screenshot of the chart with the indicator
2) Upload the screenshot file to your HTTP server
3) Users log in using their login/passwords and look at the image.
But this is only good when you just need to look at the indicator. :(
3. it is not necessary to transmit all the quotes every time. There is a more economical variant. During initialisation the indicator logs in to the server and transmits a big chunk of data. The server returns some handle associated with the received data set and the client that sent this data. While the indicator is working, it periodically sends information about the zero bar in order to correct the current reading on it. When the bar is closing, the indicator should send the final information about the bar to the server that will return the value for the closed bar. On deinitialisation/break of the connection, the server will release the allocated handle and destroy the data set (or not, whichever you prefer).
Disgusting variant - when starting the whole system slows down with terminal or you have to wait for very long time to load (some systems are still using slow channels, for example mothballs). It is much better to download the information in small chunks and save the history on the user's machine so that only fresh information is sent to the traffic as it is done in the latest versions: http: //xrust.land.ru/download/
Подкиньте идейку
The first element of the series is stored explicitly. Then we differentiate the series and use entropy coding.
Disgusting variant
Even in the case of DLL, it is desirable to give the information in chunks so that the consumer does not have to wait ("WHY?"), and it is nice in the end :)
Even in the case of DLL it is desirable to give the information in chunks so that the consumer does not suffer a long wait (no silly questions "WHY?"), and it is beautiful in the end :)
Background/asynchronous loading as I understand it implies.That's what I'm saying...