Cómo protegerse contra la copia de operaciones largas del probador - página 7

 
Dmitry Fedoseev:
Ya lo he probado. Está funcionando. Lo he probado en MT4 en tester, en experto.
Entonces esta es la salida, que se sugirió en la primera página del hilo. Allí el autor respondió que WebRequest no se ejecuta en el probador.
 
Dmitry Fedoseev:
Ya lo he probado. Está funcionando. Probado en MT4 en el probador, en el experto.
Entonces es la solución más fiable.
 
Hay una trampa. En el archivo de hosts podemos hacer una redirección.
 
Dmitry Fedoseev:
Hay una trampa. Podemos hacer la redirección en el archivo de hosts.
Pero el protocolo de comunicación con el servidor puede estar oculto o encriptado. De qué serviría que un intruso falseara el servidor porque no sabría cómo comunicarse con el programa.
 
Vasiliy Sokolov:
Pero el protocolo de comunicación con el servidor puede estar oculto o encriptado. De qué serviría que un atacante falsificara el servidor, porque no sabría cómo comunicarse con el programa.
Hay que inventar algo.
 
Vasiliy Sokolov:

El problema no es tan sencillo como puede parecer a primera vista. Se puede sugerir lo siguiente (seguir el pensamiento):

  1. Para la primera ejecución, el Asesor Experto comercia en el probador de estrategias hasta la fecha de protección en él (o un mes antes de esa fecha, las condiciones son a discreción del autor).

Sí, me parece una buena opción. En mi opinión, ni siquiera deberíamos tomar el archivo, sino utilizar una variable global. En él ciframos la fecha de la última cita en el probador.

Cuando lo iniciamos en el probador, leemos esa variable global y procesamos los ticks bien a la fecha, que está rígidamente escrita en el EA (si no hay variable global) o al mes anterior a la fecha cifrada, pero seguimos obteniendo ticks y actualizando la variable global según el último tick.

Gracias, probaré esta variante, me gusta mucho.

 
Dmitry Fedoseev:
Hay una trampa. En el archivo de hosts podemos hacer una redirección.

El hecho de que WebRequest no funcione en el probador - sólo lo he sacado de la ayuda, no he probado a solicitar datos.

Redirigir en el archivo de hosts es inútil, mientras que tener que responder a las solicitudes. Es decir, la cantidad de trabajo es significativamente diferente - ya sea sólo mover el tiempo hacia adelante, o la organización de una trampa a través de un servidor de tiempo falso.

Además no me gusta WebRequest precisamente por las acciones adicionales de resolución. No, la variante propuesta por Vasiliy Sokolov me parece la más prometedora.

 
George Merts:

No, la opción sugerida por Vasiliy Sokolov me parece la más prometedora.

La opción infalible, si se quiere, se puede obviar cambiando la hora en el archivo histórico...
 
Sinceramente, chicos, creo que deberíais haber iniciado la discusión sobre este tema para nada. Creo que mucha gente ni siquiera pensaba que fuera posible hacerlo antes, y aquí lo has discutido todo y has dado a la gente una gran idea y una forma de poner en práctica cómo no pagar a los asesores que trabajan en los TF más antiguos.
 
Alexandr Bryzgalov:
La protección de los tontos, si quieres se puede saltar cambiando la hora en el archivo de la barra de historia...

Esto está muy lejos de ser estúpido o perezoso)).

Imagínate la cantidad de chanchullos que habría que hacer:

1. Escriba un script que reemplace los tiempos de las barras en el historial.

2. desconectarse de internet, para que las nuevas barras reales no se mezclen con las sustituidas.

3. Ejecute el script, sustituyendo los tiempos.

4. Empieza a hacer pruebas. Consigue la dirección de la operación.

5. Ejecute el script para que los tiempos de las barras vuelvan a ser normales.

6. Conéctate a Internet.

Esto ya no es un "regalo"...

Razón de la queja: