¿Cómo puedo acceder al pavo a distancia? - página 5

 
sergeev >>:

и не должно наблюдаться.

дело в том, что эксперт вообще не сможет ходить чаще чем в 1 секунду за информацией. Так уж работают связки МT4 <-> wininet.dll<-> сервер.

Ну будет клиент долбить сервак запросами через каждую секунду. Ну и что? на то он и сервак, чтоб любой груз выдерживать. Представте как гуглы долбятся или вконтакте.

Я тестировал для проверки на 20 машинах + на каждой запущено по 3 терминала в этих связках запрос-ответ причем запросы при прогоне из тестера!

И вполне здорово себя чувствовали все участники эксперимента (и провайдер тоже :). Единственное, что медленно тест происходит. Тик обрабатывается раз в секунду. Но и это не такая большая проблема.

Поэтому такие системы (в которых некий блок кода вынесен в интернет) вполне рабочие.


Para que la prueba funcione correctamente en dicha combinación, simplemente vuelco los datos en un archivo separado con una marca de tiempo en el nombre del archivo. Como resultado, después de la primera ejecución, el probador apila todos los datos en el directorio. La segunda ejecución es aún más rápida que si los datos estuvieran en la base de datos de la máquina local. Sin embargo, puede haber bastantes archivos.

 
sol >>:

А чтобы тест нормально отрабатывался в такой связке, я данные просто сбрасываю в отдельный файл с timestamp в названии файла. В итоге после первого прогона тестер складывает все данные в директории. Второй прогон уже летит даже быстрее чем если бы эти данные были в базе данных на локальной машине. Правда файлов может оказаться довольно много.

en principio como opción... es algo intermedio entre tomar todos los datos a la vez o un poco a la vez, pero a menudo.

Lo principal es que cuanto más preciso sea el conjunto de tareas, más posibilidades habrá de optimizarlo en términos de velocidad.

 
sergeev писал(а) >>
Por ejemplo, para una línea del indicador 250000 barras*8 bytes (tiempo de la barra) + 8 bytes (valor de la línea) ~ 4 mb de información.

1. El tiempo no es necesario para todos los indicadores.
2. Las cotizaciones se pueden comprimir. El tiempo también se puede comprimir)))
3. no es necesario transmitir todas las cotizaciones cada vez. Existe una variante más económica. Durante la inicialización, el indicador se registra en el servidor y transmite una gran cantidad de datos. El servidor devuelve algún manejador asociado con el conjunto de datos recibidos y el cliente que recibió estos datos. Mientras el indicador está funcionando, envía periódicamente información sobre la barra cero para corregir la lectura actual en ella. Cuando la barra se está cerrando, el indicador debe enviar la información final sobre la barra al servidor que devolverá el valor de la barra cerrada. Cuando la conexión se desinicializa/se rompe, el servidor libera el handle asignado y destruye el conjunto de datos (o no, como se quiera).
4. Además, el indicador puede almacenar en caché en el lado del cliente los valores recibidos del indicador (pueden almacenarse junto con el bloque de datos comprimido, según el cual se calculan).
UPD: No se puede recalcular el indicador en todos los ticks, porque muy a menudo los ticks están en el flujo de +1 -1 -1 +1 -1 -1 - usted realmente necesita para calcular el indicador sólo 2 veces.

 
lea >>:

1. Время нужно не для всех индикаторов.

Sí, pero ahora estamos hablando de un caso general.

2. Las cotizaciones se pueden comprimir. El tiempo también se puede comprimir)))

Lánzame una idea.

3. no es necesario transmitir todas las cotizaciones cada vez. Existe una variante más económica. Durante la inicialización, el indicador se registra en el servidor y transmite una gran cantidad de datos. El servidor devuelve algún manejador asociado con el conjunto de datos recibidos y el cliente que recibió estos datos. Mientras el indicador está funcionando, envía periódicamente información sobre la barra cero para corregir la lectura actual en ella. Cuando la barra se está cerrando, el indicador debe enviar la información final sobre la barra al servidor que devolverá el valor de la barra cerrada. Cuando la conexión se desinicializa/se rompe, el servidor liberará el handle asignado y destruirá el conjunto de datos (o no, como se quiera).

No está claro cómo puede acelerar la transferencia de datos sobre la línea inducida.

4. Además, el indicador puede almacenar en caché en el lado del cliente los valores del indicador recibidos (pueden almacenarse junto con el bloque de datos comprimido, según el cual se calculan).
similar a como ya está implementado en MT - IndicatorCounted(). Yo prescribiría mi propia función similar para tales fines.
UPD: Puede no recalcular el indicador en todos los ticks, porque muy a menudo los ticks están en el flujo de +1 -1 -1 -1 -1 - de hecho sólo necesita calcular el indicador 2 veces.

En otras palabras, ahora hemos empezado a resolver un problema para los inductores. Sincronización y transmisión de barras de historia :)
Tal vez deberíamos proponerles que hicieran un servicio así para nosotros.
Es una idea interesante. Que el servidor almacene un instrumento con igual precio de apertura/cierre/alta/baja. Y los volúmenes también. Se cargará y sincronizará según todas las reglas generales, como todas las monedas. Y entonces puede utilizarse como una línea de inductores.

Quizá merezca la pena indagar en esta dirección en la documentación técnica de la sincronización de barras.

 
también hay una solución bastante retorcida:
1) hacer una captura de pantalla del gráfico con el indicador
2) Sube el archivo de captura de pantalla a tu servidor HTTP
3) Los usuarios se conectan con sus claves de acceso y miran la imagen.
Pero esto sólo es bueno cuando sólo necesitas mirar el indicador. :(
 
lea писал(а) >>
3. no es necesario transmitir todas las cotizaciones cada vez. Existe una variante más económica. Durante la inicialización, el indicador se conecta al servidor y transmite una gran cantidad de datos. El servidor devuelve algún manejador asociado al conjunto de datos recibidos y al cliente que envió estos datos. Mientras el indicador está funcionando, envía periódicamente información sobre la barra cero para corregir la lectura actual en ella. Cuando la barra se está cerrando, el indicador debe enviar la información final sobre la barra al servidor que devolverá el valor de la barra cerrada. Al desinicializar/romper la conexión, el servidor liberará el handle asignado y destruirá el conjunto de datos (o no, lo que usted prefiera).

Variante asquerosa - al arrancar todo el sistema se ralentiza con el terminal o hay que esperar mucho tiempo para cargar (algunos sistemas siguen usando canales lentos, por ejemplo las bolas de naftalina). Es mucho mejor descargar la información en pequeños trozos y guardar el historial en la máquina del usuario para que sólo se envíe información fresca al tráfico como se hace en las últimas versiones: http: //xrust.land.ru/download/

 

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


El primer elemento de la serie se almacena explícitamente. A continuación, diferenciamos la serie y utilizamos la codificación de entropía.


Variante asquerosa

Esto es sólo el principio básico. La información puede cargarse y transferirse de diferentes maneras. No me refiero a la carga en segundo plano/asíncrona en el caso de la implementación de la dll.
 

Incluso en el caso de la DLL, es deseable dar la información a trozos para que el consumidor no tenga que esperar ("¿Por qué?"), y al final es agradable :)

 
xrust писал(а) >>

Incluso en el caso de la DLL es conveniente dar la información a trozos para que el consumidor no sufra una larga espera ("¿Por qué?"), y al final es bonito :)


La carga en segundo plano/asíncrona, según entiendo, implica.
 

Ese es mi punto exactamente...

Razón de la queja: