Aiohttp: Cliente Websocket suspenso / bloqueado?

GitMate.io acredita que os problemas possivelmente relacionados são https://github.com/aio-libs/aiohttp/issues/2200 (os soquetes do cliente em segundo plano travam no SIGINT), https://github.com/aio-libs/aiohttp/issues/ 1002 (resposta do Websocket .close () pode travar indefinidamente), https://github.com/aio-libs/aiohttp/issues/376 (ProactorEventLoop trava), https://github.com/aio-libs/aiohttp/issues / 3027 (ws_connect travar) e https://github.com/aio-libs/aiohttp/issues/265 (Implementar websocket do lado do cliente).

parece que client_ws.py # L204 não está retornando ... alguma ideia?

O servidor é um decodificador SkyQ, então pode não ser uma implementação de WS totalmente em conformidade com RFC. Por exemplo, ele não respeita ping / poings ... E há aquele estranho �~� na carga útil ... Não tenho certeza se isso é um opcode ou alguma outra peculiaridade ...

Websocket é um protocolo binário que �~� codifica um tipo e comprimento de mensagem.
Desculpe, não posso ajudá-lo sem sua participação na decodificação e comparação com o tamanho real da carga útil.

�~� é 001111110111111000111111 em binário, que é: 3F7E3F em hexadecimal.

esses bytes se parecem com este de ponta a ponta ...
00111111
01111110
00111111

Não sou um especialista na RFC, mas o que isso quer dizer em termos de tipo e comprimento?

Você acha que o problema é com isso? Ou seja, não está de acordo com o comprimento real da carga útil, e a coisa esperando por um quadro extra, por exemplo?

Curiosamente, este cliente web socket cli , escrito em go, lida bem com a saída, incluindo o binário no topo:

`` `
ws ws: // skyq: 9006 / as / sistema / status
<{
"camessage": {
"motivo": "sem mensagem",
"state": "indisponível"
},
"drmstatus": {
"state": "disponível"
},
"direitos": [
"ANALYTICS",
"BIGBASIC",
"ETHAN_APP_1",
"HD",
"PDL",
"SKY_DRM_CE",
"SKY_DRM_MR",
"SKY_IPPV",
"ULTRA +",
"SKY +",
"GATEWAYENABLER",
"SIDELOAD"
],
"epginfobits": {
"epginfobits": "0xFDE5FFC0",
"máscara": "0x5FFA003F",
"state": "disponível"
},
"gatewayservices": {
"state": "disponível"
},
"hdmi": {
"2160p10bitCapable": falso,
"authenticatedHDCP": "NONE",
"motivo": "a porta de saída HDMI está desativada",
"sinkHDCP": "NONE",
"sinkHLG": falso,
"sinkUHD": falso,
"state": "indisponível",
"uhdConfigured": false
},
"rede" : {
"state": "disponível"
},
"nssplayback": {
"state": "disponível"
},
"pvr": {
"state": "disponível"
},
"cronograma" : {
"lastdate": "20181003",
"state": "disponível"
},
"servicelist": {
"state": "disponível"
},
"cartão inteligente" : {
"ativo": verdadeiro,
"bouquet": "4101",
"countryCode": "GBR",
"moeda": "GBP",
"cwe": verdadeiro,
"agregado familiar": "10947783",
"emparelhado": verdadeiro,
"state": "disponível",
"subbouquet": "1",
"limite de transação": 65535,
"viewCardNumber": "725 325 260"
},
"swupdate": {
"razão": "IDLE",
"state": "indisponível"
},
"atualizações do sistema" : {
"direitos": 2,
"instalar": 1,
"servicegenres": 1,
"smartcard": 1
},
"updatetask": {
"motivo": "sem atualização",
"state": "indisponível"
}
}

^ C
Interromper
✔ [ brad @ bradmac : ~] $ `` `

O protocolo diz: o primeiro 3F byte na mensagem WS é proibido (reservado para uso futuro).
Tem certeza de que não perdeu nada?

Presumo que você esteja se referindo ao 2d, 3o e 4o bits no protocolo de enquadramento de base. Nesse caso, sim, talvez eu tenha entendido errado. Pode ser um problema Unicode / ASCII. Vou dar outra olhada.

Tentei alguns outros conversores online ... Estou entendendo agora:
hex = ef bf bd 7e ef bf bd
binário = 11101111 10111111 10111101 01111110 11101111 10111111 10111101

Se de acordo com o RFC 6455

5.2.  Base Framing Protocol

   This wire format for the data transfer part is described by the ABNF
   [RFC5234] given in detail in this section.  (Note that, unlike in
   other sections of this document, the ABNF in this section is
   operating on groups of bits.  The length of each group of bits is
   indicated in a comment.  When encoded on the wire, the most
   significant bit is the leftmost in the ABNF).  A high-level overview
   of the framing is given in the following figure.  In a case of
   conflict between the figure below and the ABNF specified later in
   this section, the figure is authoritative.

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-------+-+-------------+-------------------------------+
     |F|R|R|R| opcode|M| Payload len |    Extended payload length    |
     |I|S|S|S|  (4)  |A|     (7)     |             (16/64)           |
     |N|V|V|V|       |S|             |   (if payload len==126/127)   |
     | |1|2|3|       |K|             |                               |
     +-+-+-+-+-------+-+-------------+ - - - - - - - - - - - - - - - +
     |     Extended payload length continued, if payload len == 127  |
     + - - - - - - - - - - - - - - - +-------------------------------+
     |                               |Masking-key, if MASK set to 1  |
     +-------------------------------+-------------------------------+
     | Masking-key (continued)       |          Payload Data         |
     +-------------------------------- - - - - - - - - - - - - - - - +
     :                     Payload Data continued ...                :
     + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
     |                     Payload Data continued ...                |
     +---------------------------------------------------------------+

   FIN:  1 bit

      Indicates that this is the final fragment in a message.  The first
      fragment MAY also be the final fragment.

   RSV1, RSV2, RSV3:  1 bit each

      MUST be 0 unless an extension is negotiated that defines meanings
      for non-zero values.  If a nonzero value is received and none of
      the negotiated extensions defines the meaning of such a nonzero
      value, the receiving endpoint MUST _Fail the WebSocket
      Connection_.

Então, parece que RSV1 e RSV2 estão sendo definidos como 1, como você sugere, a menos que alguma tensão esteja sendo negociada? Eu não faço ideia.

O número de caracteres no documento JSON é 1703

O RFC diz o seguinte sobre o comprimento da carga útil:

Payload length:  7 bits, 7+16 bits, or 7+64 bits

      The length of the "Payload data", in bytes: if 0-125, that is the
      payload length.  If 126, the following 2 bytes interpreted as a
      16-bit unsigned integer are the payload length.  If 127, the
      following 8 bytes interpreted as a 64-bit unsigned integer (the
      most significant bit MUST be 0) are the payload length.  Multibyte
      length quantities are expressed in network byte order.  Note that
      in all cases, the minimal number of bytes MUST be used to encode
      the length, for example, the length of a 124-byte-long string
      can't be encoded as the sequence 126, 0, 124.  The payload length
      is the length of the "Extension data" + the length of the
      "Application data".  The length of the "Extension data" may be
      zero, in which case the payload length is the length of the
      "Application data".

Então, diante de tudo isso, para onde vamos a seguir? Se o servidor tiver morte cerebral e não for compatível com RFC, preciso contornar isso, como outro cliente claramente pode fazer ... Você pode dar alguma sugestão?

Ainda parece suspeito.
A única extensão conhecida é a compactação WebSocket que utiliza RSV1. Não sei qual extensão usa RSV2.
Além disso, opcode FF também é reservado e não deve ser usado.

A menos que você não saiba o que o servidor envia, não há como "consertar" um cliente.

@asvetlov Eu tentei a biblioteca websockets e funciona ... Então vou continuar com ela, já que não posso perder mais tempo depurando esta biblioteca com você ...

aoihttp - não funciona

import asyncio
import logging
import sys

import aiohttp

LOGGER = logging.getLogger(__name__)
logformat = "[%(asctime)s] %(levelname)s:%(name)s:%(message)s"
logging.basicConfig(level=logging.DEBUG, stream=sys.stdout,
                    format=logformat, datefmt="%Y-%m-%d %H:%M:%S")


async def main():
    async with aiohttp.ClientSession() as session:
        async with session.ws_connect('http://skyq:9006/as/system/status') as ws:
            payload = await ws.receive()
            print(payload.text)

loop = asyncio.get_event_loop()
loop.run_until_complete(main())

websockets - funciona

import asyncio
import websockets
import logging
import sys

LOGGER = logging.getLogger(__name__)
logformat = "[%(asctime)s] %(levelname)s:%(name)s:%(message)s"
logging.basicConfig(level=logging.DEBUG, stream=sys.stdout,
                    format=logformat, datefmt="%Y-%m-%d %H:%M:%S")


async def hello():
    async with websockets.connect(
            'ws://skyq:9006/as/system/status') as websocket:

        payload = await websocket.recv()
        print(f"{payload}")

asyncio.get_event_loop().run_until_complete(hello())

Sem taxa para fechar este tíquete se desejar, mas você pode querer mantê-lo aberto, pois parece ser um bug ... Ou pelo menos uma situação que não obedece a lei de Postel.

Agradeço sua ajuda para tentar resolver isso.

Ainda parece suspeito.
A única extensão conhecida é a compactação WebSocket que utiliza RSV1. Não sei qual extensão usa RSV2.
Além disso, opcode FF também é reservado e não deve ser usado.

Oi @asvetlov

A menos que você não saiba o que o servidor envia, não há como "consertar" um cliente.

Eu acho que você quis dizer "a menos que, você sabe o que um servidor envia, você não pode consertar um cliente."

Nesse caso, discordo totalmente deste ponto.

Você está familiarizado com o princípio de robustez ?

"Seja conservador no que envia e liberal no que recebe."

Independentemente das OBRIGAÇÕES e OBRIGAÇÕES, na RFC, acho que você está interpretando e esperando que as entidades cumpram a RFC _completamente _... É claro que não, e muitos servidores de internet e clientes por aí, de vários tipos, têm horrendas implementações meio-bastardizadas de protocolos.

Uma boa implementação de biblioteca / protocolo deve perdoá-los na medida do possível. Veja RFC1122 . É completamente possível escrever um cliente de protocolo para perdoar (algumas) violações de protocolo sem ter acesso ao outro participante na comunicação.

Eu sinto que este não é o caso aqui, você parece estar assumindo a visão linha-dura de que se um host não for 100% compatível, então isso é ruim para ele, nós não falaremos com ele. Isso é muito ruim. É como dizer: 'Eu só falo o inglês da rainha, e se você vier falar comigo em algum dialeto esquisito de inglês, eu não falarei com você.'

Claramente, esta não é uma boa abordagem se todo o objetivo da biblioteca é facilitar a comunicação.

Minha sugestão, portanto, é considerar onde você pode relaxar os requisitos rigorosos do protocolo (talvez através do método kwargs, que ativa o manuseio "relaxado") e ver se você pode fazer as coisas falarem mesmo quando o outro lado não está se comportando corretamente .

Além dessa crítica, gostaria de agradecer a você e aos colaboradores de aio-libs por todo o seu trabalho para a comunidade. 👍 🥇

@asvetlov Apenas uma atualização sobre isso ... Eu descobri que meu servidor (não compatível) requer um cabeçalho Upgrade: maiúsculo antes de funcionar. Apenas pensei em mencioná-lo no caso de a questão dos cabeçalhos de caixa de título estar sendo considerada por vocês ... Este é um caso real de uma violação de protocolo de um servidor mal implementado que faz com que o cliente do websocket não funcione.