Discussion of article "Working with sockets in MQL, or How to become a signal provider"

 

New article Working with sockets in MQL, or How to become a signal provider has been published:

Sockets… What in our IT world could possibly exist without them? Dating back to 1982, and hardly changed up to the present time, they smoothly work for us every second. This is the foundation of network, the nerve endings of the Matrix we all live in.

This article describes the principle of creating asynchronous TCP and UDP sockets.  It provides several practical examples of interaction between the server and clients.

Author: o_O

 

The article is cool, but the purpose of the application? This is such a low-level technology, even a simple example required so much writing, and if something serious?

You can't put it in the Market anyway, and for yourself it's better to use WCF. Or wininet.dll, if something simple, it is already included in Windows.

Yes, for WCF you will have to make a connection with .NET, but then life becomes a holiday. We exchange on packets of bytes, as which then it is necessary to disassemble into components, and directly instances of classes. You can work in any mode - http, binary, https and all others. At the same time, the whole gemmor with authorisation, parsing, etc. has already been taken care of by Microsoft guys.

The article can be evaluated as a historical excursion to those times when the memory on the computer was 640 Kb and the screw was 40 Mb (exactly megabytes :) The author's respect, I remembered my youth)).

Основные сведения о WinInet
Основные сведения о WinInet
  • msdn.microsoft.com
Если производный объект CInternetSession, переопределите OnStatusCallback и включить обратные вызовы состояния, MFC вызывает пользовательскую функцию OnStatusCallback со сведениями о ходе выполнения о работе полностью в этом сеансе Интернета. Поскольку один сеанс может поддерживать несколько подключений (, по своим времени существования, можно...
 

That's right, there are many methods.

But the task is still urgent - less self-written dlls. And the amount of available memory has nothing to do with it.

In the market, such things, as for the server part, are unlikely to appear, the policy of MK so far allows you to become only a consumer of information and often within the sandbox.

But client ones are quite possible, as web requests and named channels have already appeared.

 
Alexey Volchanskiy:

The article is cool, but the purpose of the application? This is such a low-level technology, even a simple example required so much writing, and if something serious?

You can't put it in the Market anyway, and for yourself it's better to use WCF. Or wininet.dll, if something simple, it is already included in Windows.

Yes, for WCF you will have to make a connection with .NET, but then life becomes a holiday. We exchange on packets of bytes, as which then it is necessary to disassemble into components, and directly instances of classes. You can work in any mode - http, binary, https and all others. At the same time the whole gemmor with authorisation, parsing, etc. has already been taken care of by Microsoft guys.

The article can be evaluated as a historical excursion to those times when the memory on the computer was 640 Kb, and the screw was 40 Mb (exactly megabytes :) The author's respect, I remembered my youth)).

If there was a way to send USER_EVENT to the terminal from dll, there would be no problems at all - all functionality that is not strictly related to trading (communication and GUI) could be removed from the terminal....

But this leaves the problem that asynchronous socket will not work in mql (or rather it can, but with limitations), and synchronous tcp can easily hang the EA...:-(

 
Maxim Kuznetsov:

and so the problem remains that asynchronous socket will not work in mql (or rather it can, but with limitations).

Do you not like the asynchronous socket from the article? What limitations do you see in it?
 

MQL5 will soon have raw client (without servers) network functions, including UDP.

Control by allowed lists of IP addresses and URLs, as it works now for WebRequest.

 
o_O:
You don't like the asynchronous socket from the article? What limitations do you see in it?

First of all, the article is UDP, not TCP. So that's what this means.

and strictly speaking it is just a non-blocking socket, not asynchronous operation.

 
o_O:

That's right, there are many methods.

But the task is still urgent - less self-written dlls. And the amount of available memory has nothing to do with it.

In the market, such things, as for the server part, are unlikely to appear, the policy of MK so far allows you to become only a consumer of information and often within the sandbox.

And client ones are quite, as web requests and named channels have already appeared.

So I wrote, it's easier to use wininet.dll, still it's a layer higher. Although, someone still likes to pick in assembler )
 
Maxim Kuznetsov:

first of all, the article is UDP, not TCP. And that's what it's about.

and strictly speaking, just non-blocking socket is given, not asynchronous operation at all.

))))) yeah... that's five points for reading the article.

 
Alexey Volchanskiy:
So I wrote, it's easier to use wininet.dll.

how can you be so sure that wininet.dll will replace sockets in terms of server creation?

you guys surprise me.

Maxim Kuznetsov thought the article was about UDP.

Alexey Volchanskiy thinks it's about http requests.

In short, it's a complete hoot, no words, we judge a book by its cover.

forum with such "experts" has gone deep to the bottom.

 
o_O:

how can you be so sure that wininet.dll will replace sockets in terms of server creation?

you guys surprise me.

Maxim Kuznetsov thought the article was about UDP.

Alexey Volchanskiy thinks it's about http requests.

In short, it's a complete hoot, no words, we judge a book by its cover.

The forum with such "experts" has gone deep to the bottom.

Is this a forum on low-level network programming? )))