Discusión sobre el artículo "Trabajando con sockets en MQL, o Cómo convertirse en proveedor de señales"
El artículo es genial, pero ¿el propósito de la aplicación? Esta es una tecnología de tan bajo nivel, incluso un simple ejemplo requiere tanta escritura, y si algo serio?
De todas formas no lo puedes poner en el Market, y para ti es mejor usar WCF. O wininet.dll, si algo simple, ya está incluido en Windows.
Sí, para WCF tendrás que hacer una conexión con .NET, pero entonces la vida se convierte en un día de fiesta. Intercambiamos en paquetes de bytes, ya que entonces es necesario desmontar en componentes, y directamente instancias de clases. Se puede trabajar en cualquier modo - http, binario, https y todos los demás. Al mismo tiempo, todo el gemmor con la autorización, el análisis sintáctico, etc ya se ha ocupado de los chicos de Microsoft.
El artículo puede ser evaluado como una excursión histórica a aquellos tiempos cuando la memoria en el ordenador era 640 Kb y el tornillo era 40 Mb (exactamente megabytes :) El respeto del autor, me acordé de mi juventud)).
- msdn.microsoft.com
Así es, hay muchos métodos.
Pero la tarea sigue siendo urgente - menos dlls autoescritos. Y la cantidad de memoria disponible no tiene nada que ver.
En el mercado, tales cosas, en cuanto a la parte del servidor, es poco probable que aparezca, la política de MK hasta el momento le permite convertirse en sólo un consumidor de información y, a menudo dentro de la caja de arena.
Pero las de cliente son bastante posibles, como las peticiones web y los canales con nombre ya han aparecido.
El artículo es genial, pero ¿el propósito de la aplicación? Esta es una tecnología de tan bajo nivel, incluso un simple ejemplo requiere tanta escritura, y si algo serio?
De todas formas no lo puedes poner en el Market, y para ti es mejor usar WCF. O wininet.dll, si algo simple, ya está incluido en Windows.
Sí, para WCF tendrás que hacer una conexión con .NET, pero entonces la vida se convierte en un día de fiesta. Intercambiamos en paquetes de bytes, ya que entonces es necesario desmontar en componentes, y directamente instancias de clases. Se puede trabajar en cualquier modo - http, binario, https y todos los demás. Al mismo tiempo, todo el gemmor con la autorización, el análisis sintáctico, etc ya se ha ocupado de los chicos de Microsoft.
El artículo se puede valorar como una excursión histórica a aquellos tiempos en los que la memoria del ordenador era de 640 Kb, y el tornillo de 40 Mb (exactamente megabytes :) El respeto del autor, recordaba mi juventud)).
Si hubiera una forma de enviar USER_EVENT al terminal desde la dll, no habría ningún problema - toda la funcionalidad que no está estrictamente relacionada con el comercio (comunicación y GUI) podría ser eliminada del terminal....
Pero esto deja el problema de que el socket asíncrono no funcionará en mql (o más bien puede, pero con limitaciones), y el tcp síncrono puede colgar fácilmente el EA...:-(
y por lo tanto el problema sigue siendo que socket asíncrono no funcionará en mql (o más bien puede, pero con limitaciones).
MQL5 pronto dispondrá de funciones de red de cliente en bruto (sin servidores), incluyendo UDP.
Control por listas permitidas de direcciones IP y URL, como funciona ahora para WebRequest.
¿No te gusta el socket asíncrono del artículo? ¿Qué limitaciones le ves?
En primer lugar, el artículo es UDP, no TCP. Así que eso es lo que significa.
y estrictamente hablando es solo un socket no bloqueante, no una operación asíncrona.
Así es, hay muchos métodos.
Pero la tarea sigue siendo urgente - menos dlls autoescritos. Y la cantidad de memoria disponible no tiene nada que ver.
En el mercado, tales cosas, como para la parte del servidor, es poco probable que aparezca, la política de MK hasta el momento le permite convertirse en sólo un consumidor de información y, a menudo dentro de la caja de arena.
Y los clientes son bastante, como las solicitudes web y canales con nombre ya han aparecido.
En primer lugar, el artículo es UDP, no TCP. Y eso es lo que se trata.
y estrictamente hablando, solo se da socket no bloqueante, para nada operacion asincronica.
))))) si... son 5 puntos por leer el articulo.
Por lo que escribí, es más fácil usar wininet.dll.
¿cómo podéis estar tan seguros de que wininet.dll sustituirá a sockets en cuanto a creación de servidores?
ustedes me sorprenden.
Maxim Kuznetsov pensaba que el artículo trataba sobre UDP.
Alexey Volchanskiy piensa que es sobre peticiones http.
En resumen, es un completo cachondeo, sin palabras, juzgamos un libro por su portada.
El foro con semejantes "expertos" ha tocado fondo.
¿cómo podéis estar tan seguros de que wininet.dll sustituirá a sockets en cuanto a creación de servidores?
me sorprendéis.
Maxim Kuznetsov pensaba que el artículo trataba sobre UDP.
Alexey Volchanskiy piensa que es sobre peticiones http.
En resumen, es un completo cachondeo, sin palabras, juzgamos un libro por su portada.
El foro con semejantes "expertos" ha tocado fondo.
- Aplicaciones de trading gratuitas
- 8 000+ señales para copiar
- Noticias económicas para analizar los mercados financieros
Usted acepta la política del sitio web y las condiciones de uso
Artículo publicado Trabajando con sockets en MQL, o Cómo convertirse en proveedor de señales:
Los sockets... ¿Qué podría existir sin ellos en este mundo de información? Aparecieron por primera vez en 1982 y prácticamente no han cambiado hasta el día de hoy, siguen funcionando para nosotros cada segundo. Son la base de una red, las terminaciones nerviosas del Matrix en el que vivimos.
No es un secreto que WinAPI ha sido diseñado para el lenguaje C. Y el lenguaje MQL es prácticamente su hermano (tanto por espíritu como por su estilo de trabajo). Vamos a crear un archivo mqh para estas funciones WinAPI, que usaremos en el programa MQL principal. La secuencia de nuestras acciones consistirá en proceder al traslado según lo necesitimos.
Autor: o_O