¿Necesitas mis comentarios aquí? Estoy enlazando código mql con código externo, paralelamente miro tus desarrollos, encuentro errores, puede que no escriba aquí.
No olvides escribir explícitamente sobre bitness en el artículo. Algo como: "código para x64" o hacer un interruptor en las macros para compilar para diferentes arquitecturas. Por cierto, ¿qué es sizeof(ULONG) en x64? Tengo datos contradictorios. Por un lado debería ser 4 siempre, el modelo LLP64 en win lo insinúa, y msdn escribe: https://msdn.microsoft.com/en-us/library/windows/desktop/aa383751%28v=vs.85%29.aspx.
ULONG:<br/ translate="no">Un LONG sin signo. El rango es de 0 a 4294967295 decimal Este tipo se declara en WinDef.h como sigue: typedef unsigned long ULONG;
pero no estoy seguro.
ENTONCES
si estoy en lo cierto, has metido ulong aquí para nada:
The data types supported by Windows are used to define function return values, function and message parameters, and structure members. They define the size and meaning of these elements. For more information about the underlying C/C++ data types, see Data Type Ranges. The following table contains the following types: character, integer...
¿Podrías compartir para qué tareas lo vas a utilizar? Incluso hay una petición en el artículo
No se me ocurre ningún sitio donde me convenga.
Estoy en linux, de ahí que ipc en general se convierta en una tarea no trivial (comunicación entre terminal bajo wine y linuex exe). E ipc sobre una red es una forma universal. Conecto el script µl al programa linux a través de loopback (127.0.0.1) en el mismo ordenador. Básicamente, escribí una api de linux para el terminal (el script µl gestiona las peticiones y envía los datos de precios o coloca las órdenes).
En mi situación esta es la mejor manera de IPC de lo que he probado. Y no quiero transferir mis desarrollos a µl: no quiero estar atado a un lenguaje concreto, por una cuestión de principios.
Estoy en linux, por lo tanto ipc en general se convierte en una tarea no trivial (comunicación entre terminal bajo wine y linuex exe). E ipc sobre la red es una forma universal. Conecto el script µl al programa linux a través de loopback (127.0.0.1) en el mismo ordenador. Básicamente, escribí una api de linux para el terminal (el script µl gestiona las peticiones y envía los datos de precios o coloca las órdenes).
En mi situación, ésta es la mejor forma de IPC que he probado. No quiero transferir mis desarrollos a µl, no quiero estar atado a un lenguaje concreto, por una cuestión de principios.
Sería un gran artículo. Tienes tu propia API universal de comercio para cualquier plataforma. Y para una plataforma escribes sólo un receptor/transmisor en la API de la propia plataforma.
Y puedes escribir TS en cualquier lenguaje. ¡Los programadores son así!
La contrapartida está sólo en la latencia. Por eso no funcionará para un tipo muy estrecho de TC - y eso está bien.
El artículo es muy interesante e informativo. Tengo la intención de utilizar la tecnología de socket para transferir desde el servidor VPS con terminales MT-5 al servidor con base de datos MS-SQL información sobre el estado financiero de las cuentas al final del día / semana / mes. Implementado en la práctica, pero la práctica muestra que después de algún tiempo los paquetes comienzan a perderse. Y a juzgar por los registros en un primer momento la parte del servidor "se detiene", y las partes cliente en este momento siguen pensando que todo está bien, porque el código de la parte cliente de la comprobación de tipo
no da nada. Es decir, los clientes no pueden diagnosticar la pérdida de conexión con el servidor antes de enviar e incluso en el momento de enviar paquetes.
¿Tal vez sea necesario añadir alguna función como "CheckSocket" para la comprobación preliminar de la operatividad del socket del servidor? ¿Cómo implementarlo entonces?
sino en el artículo.
¿Necesitas mis comentarios aquí? Estoy enlazando código mql con código externo, paralelamente miro tus desarrollos, encuentro errores, puede que no escriba aquí.
está bien, los comentarios son bienvenidos.
Estoy enviando las ediciones de tipo al artículo.
Usaré 64 bits en los ejemplos
https://msdn.microsoft.com/en-us/library/windows/desktop/aa383751%28v=vs.85%29.aspx.
pero no estoy seguro.
ENTONCES
si estoy en lo cierto, has metido ulong aquí para nada:
Tengo un cliente TCP síncrono:
No necesito un servidor en µl, así que sólo un cliente. Probado superficialmente.
ZЫЫ: Gracias por el artículo.Tengo un cliente TCP síncrono de este tipo:
¿Podrías compartir para qué tareas lo vas a utilizar? Incluso hay una solicitud en el artículo
Si usted también tiene ideas de aplicación - compartirlas en los comentarios al artículo
No puedo pensar en ninguna aplicación en la que sería conveniente para mí.
¿Podrías compartir para qué tareas lo vas a utilizar? Incluso hay una petición en el artículo
No se me ocurre ningún sitio donde me convenga.
Estoy en linux, de ahí que ipc en general se convierta en una tarea no trivial (comunicación entre terminal bajo wine y linuex exe). E ipc sobre una red es una forma universal. Conecto el script µl al programa linux a través de loopback (127.0.0.1) en el mismo ordenador. Básicamente, escribí una api de linux para el terminal (el script µl gestiona las peticiones y envía los datos de precios o coloca las órdenes).
En mi situación esta es la mejor manera de IPC de lo que he probado. Y no quiero transferir mis desarrollos a µl: no quiero estar atado a un lenguaje concreto, por una cuestión de principios.
Estoy en linux, por lo tanto ipc en general se convierte en una tarea no trivial (comunicación entre terminal bajo wine y linuex exe). E ipc sobre la red es una forma universal. Conecto el script µl al programa linux a través de loopback (127.0.0.1) en el mismo ordenador. Básicamente, escribí una api de linux para el terminal (el script µl gestiona las peticiones y envía los datos de precios o coloca las órdenes).
En mi situación, ésta es la mejor forma de IPC que he probado. No quiero transferir mis desarrollos a µl, no quiero estar atado a un lenguaje concreto, por una cuestión de principios.
Sería un gran artículo. Tienes tu propia API universal de comercio para cualquier plataforma. Y para una plataforma escribes sólo un receptor/transmisor en la API de la propia plataforma.
Y puedes escribir TS en cualquier lenguaje. ¡Los programadores son así!
La contrapartida está sólo en la latencia. Por eso no funcionará para un tipo muy estrecho de TC - y eso está bien.
Implementado en la práctica, pero la práctica muestra que después de algún tiempo los paquetes comienzan a perderse. Y a juzgar por los registros en un primer momento la parte del servidor "se detiene", y las partes cliente en este momento siguen pensando que todo está bien, porque el código de la parte cliente de la comprobación de tipo
if(client==INVALID_SOCKET) StartClient(Host,Port);no da nada. Es decir, los clientes no pueden diagnosticar la pérdida de conexión con el servidor antes de enviar e incluso en el momento de enviar paquetes.¿Tal vez sea necesario añadir alguna función como "CheckSocket" para la comprobación preliminar de la operatividad del socket del servidor? ¿Cómo implementarlo entonces?