Discussão do artigo "WebSocket para MetaTrader 5" - página 2

[Roman]

Renat Fatkhullin:

Você simplesmente não entende ou não sabe como usar esse recurso.

Essa função fornece instantaneamente o número de bytes disponíveis no buffer de entrada e não informa que o soquete está ativo. A função é muito importante e permite que você não entre em espera síncrona, mas leia os dados parte por parte sem perder o controle sobre o programa.

E as funções TLS também estão corretas - elas são fornecidas para usuários treinados que sabem como e em que sequência usá-las. Elas não são para aqueles que "ligam e pronto".

Além disso, as funções de socket e tls são, em sua forma pura, as mesmas que o terminal usa para conexões raw/tls/https. Ou seja, tudo funciona bem. Essas mesmas implementações funcionam em nossas soluções de alta carga.

As funções de rede brutas não são para iniciantes e nem para uso ingênuo. É preciso entender suficientemente bem os princípios e as peculiaridades da interação de rede. E se estivermos falando de TLS, os métodos e a sequência de processamento do processo de handshake.

Essa função não tem parâmetro de buffer. De que buffer de entrada estamos falando?
Não sei de que entendimento você está falando e para quais usuários, Ilyas encontrou esse erro e o considerou um engano.
A questão é que todos os usuários são orientados por exemplos da documentação do soquete.
E os usuários avançados escrevem a especificação do protocolo, e as atualizações e a análise de quadros entendem tudo isso.
O problema é que a função SocketIsReadable(socket) não deixa claro o que retorna, para wss: frame.

[Roman]

Stanislav Korotky:

Existe alguma lógica por trás disso? Qual é o número mágico e por que ele seria adequado para um comprimento de mensagem de 256 ou 1500, por exemplo?

Justificativa? Não sei. Com o número na variável, ela é lida sem problemas. O comprimento é definido como o tamanho máximo aproximado do quadro de entrada.
Você pode defini-lo como o máximo, isso não afeta nada.

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

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

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

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

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

E com a função SocketIsReadable(socket) você sabe que ele lê com erro.

O que SocketIsReadable(socket) retorna em len não se encaixa em SocketTlsRead() e SocketTlsReadAvailable()

[Renat Fatkhullin]

Roman:

Essa função não tem parâmetro de buffer. De que buffer de entrada estamos falando?
Não sei de que entendimento você está falando e para quais usuários, esse erro foi encontrado por Ilyas e acho que ele o considerou um erro.
A questão é que todos os usuários são orientados por exemplos da documentação de soquetes.
E os usuários avançados escrevem a especificação do protocolo, e as atualizações e a análise de quadros entendem tudo isso.
O problema é que a função SocketIsReadable(socket) não deixa claro o que retorna, para wss: frame.

Portanto, você não tem a menor ideia sobre soquetes e seus buffers, mas nos ensina os erros.

Verificar o tamanho dos dados brutos no buffer de entrada SocketIsReadable certamente não se encaixa nas funções Tls que lidam com dados criptografados recebidos em um tamanho menor.

"Entendi como um erro" - as pessoas conseguem interpretar qualquer resposta simples como uma admissão de culpa. Mostre uma resposta clara.

[Roman]

Renat Fatkhullin:
Portanto, você não tem a menor ideia sobre soquetes e seus buffers, mas nos ensina os erros.

Verificar o tamanho dos dados brutos no buffer de entrada SocketIsReadable certamente não se encaixa nas funções Tls que lidam com dados criptografados recebidos em um tamanho menor.

A pergunta era sobre a função SocketIsReadible, e o fato de a função ter um buffer interno está claro.
Você escreve sobre o buffer da função SocketIsReadible, mas é estranho mencioná-lo se ele não estiver disponível para o usuário.

[Renat Fatkhullin]

Leia o artigo e dê uma olhada no código proposto.

É estranho alegar erros com um trecho de código irreproduzível de várias linhas quando estamos falando sobre a qualidade da implementação de um protocolo complexo.

[Renat Fatkhullin]

Roman:

A pergunta era sobre a função SocketIsReadible, e o fato de a função ter um buffer interno está claro.
Você escreve sobre o buffer da função SocketIsReadible, mas é estranho mencioná-lo se ele não estiver disponível para o usuário.

Mais uma vez, repito: você não entende de soquetes e não conhece suas peculiaridades.

Você está até mesmo enganado sobre os buffers "internos" do SocketIsReadable, que não existem. De quem são os buffers nos soquetes? Quem os gerencia? Como eles funcionam e quais são suas peculiaridades?

Daí o uso indevido com declarações de erro, quando a realidade diverge da percepção ingênua.

[Roman]

Renat Fatkhullin:

"Tomado por um erro" - as pessoas conseguem confundir qualquer resposta clara com uma admissão de culpa. Mostre-me uma resposta clara.

.

[Renat Fatkhullin]

Roman:

.

A primeira parte de sua resposta está correta, pois explica a diferença entre os tamanhos dos dados brutos e dos dados descriptografados.

Mas a última resposta é um caso particular (colocar tamanho fixo) na forma de uma muleta. É mais provável que seja contra o pano de fundo de outro trecho de código de três linhas, no qual nada além de uma correção/amparo particular pode ser oferecido.

O Ilyas não lida com soquetes. Não há reconhecimento de erro.

Para fins de informação: escrevi a implementação de soquetes brutos, tls, https e seus derivados no MT5. Como antes, escrevi dezenas de implementações de protocolos de rede desde 1995.

Portanto, é estranho discutir comigo. Dezenas de milhões de dispositivos trabalharam e trabalham com minhas implementações.

[Roman]

Renat Fatkhullin:
A primeira parte de sua resposta está correta, pois explica a diferença entre o tamanho dos dados brutos e dos dados descriptografados.

Mas a última resposta é um caso particular (colocar tamanho de correção) na forma de uma muleta. Provavelmente, isso ocorre no contexto de outro trecho de código de três linhas, no qual nada além de uma correção/amparo particular pode ser oferecido.

O Ilyas não lida com soquetes. Não há reconhecimento de erro.

Para fins de informação: escrevi a implementação de soquetes brutos, tls, https e seus derivados no MT5. Como antes, escrevi dezenas de implementações de protocolos de rede desde 1995.

Portanto, é estranho discutir comigo. Dezenas de milhões de dispositivos trabalharam e trabalham em minhas implementações.

Entendo sua experiência incontestável. E ninguém iria discutir com você.
Mas o artigo não revela a questão de como usar corretamente o wss: em MQL!
Porque o autor do artigo não entende esse ponto, assim como todos os outros usuários (mesmo os avançados).
É por isso que uso em minha implementação o fix size como muleta.

Por favor, mostre-me a leitura correta do quadro wss: em MQL, levando em conta o pool SocketIsReadable, e todos dirão apenas obrigado.

[Renat Fatkhullin]

Roman:

Entendo sua experiência incontestável. E ninguém iria discutir com você.
Mas o artigo não revela a questão de como usar o wss: no MQL corretamente!
Porque o autor do artigo não entende esse ponto tão bem quanto todos os outros usuários (mesmo avançados).
É por isso que uso em minha implementação o tamanho da correção como uma muleta.

Por favor, mostre-me a leitura correta do quadro wss: em MQL, levando em conta o pool SocketIsReadable, e todos dirão apenas obrigado.

Não tenho tempo agora, mas devo fazer um conjunto de implementações CSocketRaw, CSocketTLS, CSocketHTTP na biblioteca MQL5 padrão.

Se eu tiver 8 horas de tempo livre, farei isso.