Discussion of article "Websockets for MetaTrader 5" - page 2

[Roman]

Renat Fatkhullin:

You just don' t understand or know how to use this feature.

This function instantly gives the available number of bytes in the input buffer, and does not tell you that the socket is alive. The function is very important and allows you not to go into synchronous waiting, but to read out data portion by portion without losing control over the programme.

And TLS functions are also correct - they are given for trained users who know how and in what sequence to use them. They are not for those who "called and that's it".

Not only that, socket and tls functions are in pure form the same ones that terminal uses for raw/tls/https connections. That is, everything works fine. These same implementations work in our high load solutions.

Raw network functions are not for beginners and not for naive use. One should understand the principles and peculiarities of network interaction well enough. And if we are talking about TLS, the methods and sequence of processing handshake process.

This function has no buffer parameter. What input buffer are we talking about?
I don't know what understanding you are talking about and for which users, Ilyas found this error and took it as a mistake.
The point is that all users are oriented on examples from socket documentation.
And advanced users write protocol specification, and upgrades and frame parsing understand all this.
The problem is that the function SocketIsReadable(socket) is not clear what it returns, for wss: frame.

[Roman]

Stanislav Korotky:

Is there any rationale behind it? What is the magic number and why would it be fine for a message length of 256 or 1500, for example?

Rationale? I don't know. With the number in the variable, it reads without a problem. The length is set to the approximate maximum size of the incoming frame.
You can set it to the maximum, it doesn't affect anything.

string CWs::Recv()
{
   uchar   rsp[]; //, res[];
   string  result  = "";
   //uint timeout_check = GetTickCount() + timeout;

   //do
   //{
      uint len = 65536; //SocketIsReadable(socket);

      //if(len)
      //{
         int rsp_len = SocketTlsReadAvailable(socket, rsp, len);

         //if(rsp_len > 0)
         //{
            //ArrayInsert(res, rsp, ArraySize(res), 0); 
            //break;
         //} 
      //}
   //}
   //while(GetTickCount() < timeout_check && !IsStopped());

   if(rsp_len > 0) //(ArraySize(res) > 0)
      result = Unpack(rsp, ArraySize(rsp));
   
  
   return(result);
}

And with the SocketIsReadable(socket) function you know that it reads with an error.

What SocketIsReadable(socket) returns in len does not fit in SocketTlsRead() and SocketTlsReadAvailable()

[Renat Fatkhullin]

Roman:

This function has no buffer parameter. What input buffer are we talking about?
I don't know what understanding you are talking about and for which users, this error was found by Ilyas and I think he took it as a mistake.
The point is that all users are oriented on examples from the documentation for sockets.
And advanced users write protocol specification, and upgrades and frame parsing understand it all.
The problem is that the function SocketIsReadable(socket) is not clear what it returns, for wss: frame.

So, you have no idea about sockets and their buffers at all, but you teach us errors.

Checking the size of raw data in the incoming buffer SocketIsReadable certainly doesn't fit with Tls functions that deal with encrypted data received in a smaller size.

'Took it as a mistake' - people manage to take any neat answer as an admission of guilt. Show a clear answer.

[Roman]

Renat Fatkhullin:
So you have no idea at all about sockets and their buffers, but you teach us mistakes.

Checking the size of raw data in the incoming buffer SocketIsReadable certainly doesn't fit with Tls functions that deal with encrypted data received in a smaller size.

The question was about the SocketIsReadible function, and the fact that the function has an internal buffer is clear.
You write about the buffer of the SocketIsReadible function , but it is strange to mention it if it is not available to the user.

[Renat Fatkhullin]

Read the article and look at the proposed code.

It is strange to claim errors with an unreproducible piece of code of several lines when we are talking about the quality of implementation of a complex protocol.

[Renat Fatkhullin]

Roman:

The question was about the SocketIsReadible function, and the fact that the function has an internal buffer is clear.
You write for the buffer of the SocketIsReadible function , but it is strange to mention it if it is not available to the user.

Once again I repeat - you don't understand sockets and don't know their peculiarities.

You are even mistaken about 'internal' SocketIsReadable buffers which do not exist. Whose buffers are in sockets? Who manages them? How do they work and what are their peculiarities?

Hence misuse with error statements when reality diverges from naive perception.

[Roman]

Renat Fatkhullin:

'Taken for a mistake' - people manage to mistake any neat answer for an admission of guilt. Show me a clear answer.

.

[Renat Fatkhullin]

Roman:

.

The first part of his answer is correct, it explains the difference between the sizes of raw data and decrypted data.

But the last answer is a private case (put fix size) in the form of a crutch. It is most likely against the background of another three-line piece of code where nothing but a private correction/crutch can be offered.

Ilyas does not deal with sockets. There is no error acknowledgement.

For information: I wrote implementation of raw sockets, tls, https and their derivatives in MT5. As before I wrote dozens of implementations of network protocols since 1995.

So it is strange to argue with me. Tens of millions of devices worked and work on my implementations.

[Roman]

Renat Fatkhullin:
The first part of his answer is correct, it explains the difference between the size of raw data and decrypted data.

But the last answer is a private case (put fix size) in the form of a crutch. Most likely, it is against the background of another three-line piece of code where nothing but a private correction/crutch can be offered.

Ilyas does not deal with sockets. There is no error acknowledgement.

For information: I wrote the implementation of raw sockets, tls, https and their derivatives in MT5. As before I wrote dozens of implementations of network protocols since 1995.

So it is strange to argue with me. Tens of millions of devices worked and work on my implementations.

I understand your undisputed experience. And no one was not going to argue with you.
But the article does not reveal the question of how to correctly use wss: in MQL!
Because the author of the article does not understand this point, as well as all other (even advanced) users.
That's why I use in my implementation, fix size as a crutch.

Please show me the correct wss: frame reading in MQL, taking into account the SocketIsReadable pool, everyone will say only thanks.

[Renat Fatkhullin]

Roman:

I understand your undisputed experience. And no one was going to argue with you.
But the article does not reveal the question of how to use wss: in MQL correctly!
Because the author of the article does not understand this point as well as all other (even advanced) users.
That's why I use in my implementation the fix size as a crutch.

Please show me the correct wss: frame reading in MQL, taking into account the SocketIsReadable pool, everyone will say only thanks.

I don't have time now, but I should make a set of CSocketRaw, CSocketTLS, CSocketHTTP implementations in the standard MQL5 library.

If I have 8 hours of free time, I will do it.