Aiohttp: ¿Cliente de Websocket colgando / bloqueando?

GitMate.io cree que los posibles problemas relacionados son https://github.com/aio-libs/aiohttp/issues/2200 (los websockets del cliente en segundo plano se cuelgan de SIGINT), https://github.com/aio-libs/aiohttp/issues/ 1002 (La respuesta de Websocket .close () puede bloquearse indefinidamente), https://github.com/aio-libs/aiohttp/issues/376 (ProactorEventLoop se bloquea), https://github.com/aio-libs/aiohttp/issues / 3027 (ws_connect hang) y https://github.com/aio-libs/aiohttp/issues/265 (Implementar websocket del lado del cliente).

parece que client_ws.py # L204 no regresa ... ¿alguna idea?

El servidor es un decodificador SkyQ, por lo que es posible que no sea una implementación de WS totalmente compatible con RFC. Por ejemplo, no respeta los ping / poings ... Y hay ese extraño �~� en la carga útil ... No estoy seguro si es un código de operación o alguna otra peculiaridad ...

Websocket es un protocolo binario �~� codifica el tipo y la longitud de un mensaje.
Lo siento, no puedo ayudarlo sin su participación para decodificarlo y compararlo con el tamaño real de la carga útil.

�~� es 001111110111111000111111 en binario, que es: 3F7E3F en hexadecimal.

esos bytes se ven así de extremo a extremo ...
00111111
01111110
00111111

No soy un experto en RFC, pero ¿qué dice esto en términos de tipo y longitud?

¿Crees que el problema está en eso? Es decir, ¿no está de acuerdo con la longitud real de la carga útil y, por ejemplo, está esperando una trama adicional?

Curiosamente, este cliente cli de socket web , escrito en go, maneja bien la salida, incluidas las cosas binarias en la parte superior:

''
ws ws: // skyq: 9006 / as / system / status
<{
"camessage": {
"motivo": "sin mensaje",
"estado": "no disponible"
},
"drmstatus": {
"estado": "disponible"
},
"derechos": [
"ANALÍTICA",
"GRANDE",
"ETHAN_APP_1",
"HD",
"PDL",
"SKY_DRM_CE",
"SKY_DRM_MR",
"SKY_IPPV",
"ULTRA +",
"SKY +",
"GATEWAYENABLER",
"CARGA LATERAL"
],
"epginfobits": {
"epginfobits": "0xFDE5FFC0",
"máscara": "0x5FFA003F",
"estado": "disponible"
},
"gatewayservices": {
"estado": "disponible"
},
"hdmi": {
"2160p10bitCapable": falso,
"authenticatedHDCP": "NINGUNO",
"motivo": "El puerto de salida HDMI está desactivado",
"sinkHDCP": "NINGUNO",
"sinkHLG": falso,
"sinkUHD": falso,
"estado": "no disponible",
"uhdConfigured": falso
},
"la red" : {
"estado": "disponible"
},
"nssplayback": {
"estado": "disponible"
},
"pvr": {
"estado": "disponible"
},
"calendario" : {
"lastdate": "20181003",
"estado": "disponible"
},
"Lista de servicios" : {
"estado": "disponible"
},
"tarjeta electrónica" : {
"activo": verdadero,
"ramo": "4101",
"countryCode": "GBR",
"moneda": "GBP",
"cwe": cierto,
"familyid": "10947783",
"emparejado": verdadero,
"estado": "disponible",
"subramo": "1",
"transactionlimit": 65535,
"viewsCardNumber": "725325260"
},
"swupdate": {
"motivo": "IDLE",
"estado": "no disponible"
},
"actualizaciones del sistema" : {
"derechos": 2,
"instalar": 1,
"servicegenres": 1,
"tarjeta inteligente": 1
},
"updatetask": {
"motivo": "sin actualización",
"estado": "no disponible"
}
}

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

El protocolo dice: el primer byte 3F en el mensaje WS está prohibido (reservado para uso futuro).
¿Estás seguro de que no te perdiste nada?

Supongo que se está refiriendo al 2d, 3er y 4to bit en el protocolo de entramado base. En cuyo caso sí, tal vez me equivoqué. Podría ser un problema de Unicode / ASCII. Echaré otro vistazo.

Probé algunos otros convertidores en línea ... Estoy obteniendo esto ahora:
hex = ef bf bd 7e ef bf bd
binario = 11101111 10111111 10111101 01111110 11101111 10111111 10111101

Si de acuerdo con 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_.

Entonces parece que RSV1 y RSV2 se están configurando en 1, como sugiere, a menos que se esté negociando alguna extensión. No tengo idea.

El número de caracteres en el documento JSON es 1703

El RFC dice esto sobre la longitud de la 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".

Entonces, dado todo eso, ¿a dónde vamos ahora? Si el servidor tiene muerte cerebral y no cumple con RFC, entonces tengo que solucionarlo como claramente pueden hacer otros clientes ... ¿Pueden ofrecerme alguna sugerencia?

Todavía parece sospechoso.
La única extensión conocida es la compresión WebSocket que utiliza RSV1. No sé qué extensión usa RSV2.
Además, el código de operación FF también está reservado y no debe usarse.

A menos que no sepa lo que envía el servidor, no hay forma de "arreglar" un cliente.

@asvetlov Probé la biblioteca websockets y funciona ... Así que voy a seguir con eso, ya que no puedo dedicar más tiempo a depurar esta biblioteca contigo ...

aoihttp - no 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())

No hay cargo por cerrar este ticket si lo desea, pero es posible que desee mantenerlo abierto ya que parece ser un error ... O al menos una situación que no obedece a la ley de Postel.

Agradezco su ayuda para tratar de solucionar este problema.

Todavía parece sospechoso.
La única extensión conocida es la compresión WebSocket que utiliza RSV1. No sé qué extensión usa RSV2.
Además, el código de operación FF también está reservado y no debe usarse.

Hola @asvetlov

A menos que no sepa lo que envía el servidor, no hay forma de "arreglar" un cliente.

Creo que quería decir "a menos, que saben lo que envía un servidor, no se puede arreglar un cliente."

En cuyo caso, estoy completamente en desacuerdo con este punto.

¿Está familiarizado con el principio de robustez ?

"Sea conservador en lo que envíe y liberal en lo que reciba".

Independientemente de los MUST, DEBERÍAN y NO DEBE, en el RFC, creo que está interpretando y esperando que las entidades cumplan con el RFC _completamente _ ... Claramente no lo hacen, y muchos servidores y clientes de Internet, de varios tipos, han horribles medias implementaciones bastardas de protocolos.

Una buena implementación de biblioteca / protocolo debe perdonarlos en la medida de lo posible. Consulte RFC1122 . Es completamente posible escribir un cliente de protocolo para perdonar (algunas) violaciones del protocolo sin tener acceso al otro participante en la comunicación.

Siento que este no es el caso aquí, parece que está adoptando la posición de línea dura de que si un host no cumple al 100%, entonces es una lástima, no hablaremos con él. Esto es una lástima. Es como decir: 'Solo hablo el inglés de la reina, y si vienes a hablar conmigo en algún dialecto extraño del inglés, no te hablaré'.

Claramente, este no es un buen enfoque si el objetivo de la biblioteca es facilitar la comunicación.

Mi sugerencia, por lo tanto, es considerar dónde puede relajar los requisitos estrictos del protocolo (tal vez a través del método kwargs, que activa el manejo "relajado"), y ver si puede hacer que las cosas hablen incluso cuando la otra parte no se está comportando correctamente. .

Aparte de esta crítica, me gustaría agradecerles a ustedes y a los colaboradores de aio-libs por todo su trabajo para la comunidad. 👍 🥇

@asvetlov Solo una actualización sobre esto ... Me di cuenta de que mi servidor (no compatible) requiere un encabezado Upgrade: mayúsculas antes de que funcione. Solo pensé en mencionarlo en caso de que ustedes estén considerando el tema de los encabezados de Title Case ... Este es un caso real de una violación de protocolo de un servidor mal implementado que hace que el cliente websocket no funcione.