Do you need my comments here at all? I am linking mql code with external code, in parallel I look at your developments, I find errors, I may not write here.
Don't forget to write explicitly about bitness in the article. Something like: "code for x64" or make a switch on macros to compile for different architectures. By the way, what is sizeof(ULONG) on x64? I have some contradictory data. On the one hand it should be 4 always, the LLP64 model in win hints at it, and msdn writes: https://msdn.microsoft.com/en-us/library/windows/desktop/aa383751%28v=vs.85%29.aspx.
ULONG:<br/ translate="no">An unsigned LONG. The range is 0 through 4294967295 decimal This type is declared in WinDef.h as follows: typedef unsigned long ULONG;
but I'm not sure.
SO:
if I'm right, you've crammed ulong here for nothing:
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...
Could you share for which tasks you are going to use it? There's even a request in the article
I can't think of anywhere where it would be convenient for me.
I'm in linux, hence ipc in general becomes a non-trivial task (communication between terminal under wine and linuex exe). And ipc over a network is a universal way. I connect the µl script to the linux programme via loopback (127.0.0.1) on the same comp. Basically, I wrote a linux api for the terminal (the µl script handles requests and sends price data or places orders).
In my situation this is the best way of IPC from what I have tried. And I don't want to transfer my developments to µl - I don't want to be bound to a particular language, as a matter of principle.
I'm in linux, hence ipc in general becomes a non-trivial task (communication between terminal under wine and linuex exe). And ipc over the network is a universal way. I connect the µl script to the linux programme via loopback (127.0.0.1) on the same comp. Basically, I wrote a linux api for the terminal (the µl script handles requests and sends price data or places orders).
In my situation this is the best way of IPC from what I have tried. I don't want to transfer my developments to µl - I don't want to be bound to a particular language, as a matter of principle.
It would be a great article! You get your own trading universal API for any platform. And for a platform you write only a receiver/transmitter on the API of the platform itself.
And you can write TS in any language. Programmers are like that!
Payback is only in latency. That's why it won't work for a very narrow kind of TC - and that's okay.
The article is very interesting and informative. I plan to use socket technology to transfer from VPS server with MT-5 terminals to server with MS-SQL database information on financial status of accounts at the end of the day/week/month. Implemented in practice, but practice shows that after some time packets start to be lost. And judging by the logs at first the server part "stops", and client parts at this time continue to think that everything is OK, because the code of the client part of the check of type
but in the article.
Do you need my comments here at all? I am linking mql code with external code, in parallel I look at your developments, I find errors, I may not write here.
it's okay, comments are welcome.
I'm sending the type edits to the article.
I'll use 64 bits in the examples
https://msdn.microsoft.com/en-us/library/windows/desktop/aa383751%28v=vs.85%29.aspx.
but I'm not sure.
SO:
if I'm right, you've crammed ulong here for nothing:
I got such a synchronous TCP client:
I don't need a server on µl, so just a client. Tested superficially.
ZЫЫ: Thanks for the article.I have such a synchronous TCP client:
Could you share for which tasks you are going to use it? There is even a request in the article
If you also have ideas of application - share them in comments to the article
I can't think of any application where it would be convenient for me.
Could you share for which tasks you are going to use it? There's even a request in the article
I can't think of anywhere where it would be convenient for me.
I'm in linux, hence ipc in general becomes a non-trivial task (communication between terminal under wine and linuex exe). And ipc over a network is a universal way. I connect the µl script to the linux programme via loopback (127.0.0.1) on the same comp. Basically, I wrote a linux api for the terminal (the µl script handles requests and sends price data or places orders).
In my situation this is the best way of IPC from what I have tried. And I don't want to transfer my developments to µl - I don't want to be bound to a particular language, as a matter of principle.
I'm in linux, hence ipc in general becomes a non-trivial task (communication between terminal under wine and linuex exe). And ipc over the network is a universal way. I connect the µl script to the linux programme via loopback (127.0.0.1) on the same comp. Basically, I wrote a linux api for the terminal (the µl script handles requests and sends price data or places orders).
In my situation this is the best way of IPC from what I have tried. I don't want to transfer my developments to µl - I don't want to be bound to a particular language, as a matter of principle.
It would be a great article! You get your own trading universal API for any platform. And for a platform you write only a receiver/transmitter on the API of the platform itself.
And you can write TS in any language. Programmers are like that!
Payback is only in latency. That's why it won't work for a very narrow kind of TC - and that's okay.
Implemented in practice, but practice shows that after some time packets start to be lost. And judging by the logs at first the server part "stops", and client parts at this time continue to think that everything is OK, because the code of the client part of the check of type
if(client==INVALID_SOCKET) StartClient(Host,Port);does not give anything. I.e. clients can't diagnose the loss of connection with the server before sending and even at the moment of sending packets.Perhaps it is necessary to add some function like "CheckSocket" for preliminary check of server socket operability? How to implement it then ?