Aiohttp: Websocket Client hängen / blockieren?

GitMate.io glaubt, dass möglicherweise verwandte Probleme https://github.com/aio-libs/aiohttp/issues/2200 (Hintergrund-Client-Websockets hängen an SIGINT), https://github.com/aio-libs/aiohttp/issues/ sind. 1002 (Websocket-Antwort .close () kann unbegrenzt hängen bleiben), https://github.com/aio-libs/aiohttp/issues/376 (ProactorEventLoop hängt), https://github.com/aio-libs/aiohttp/issues / 3027 (ws_connect hang) und https://github.com/aio-libs/aiohttp/issues/265 (Implementieren des clientseitigen Websockets).

es sieht so aus, als würde client_ws.py # L204 nicht zurückkehren ... irgendwelche Ideen?

Der Server ist eine SkyQ-Set-Top-Box, daher ist WS möglicherweise nicht vollständig RFC-konform. Zum Beispiel werden Ping / Poings nicht berücksichtigt ... Und da ist das seltsame �~� in der Nutzlast ... Ich bin mir nicht sicher, ob das ein Opcode oder eine andere Eigenart ist ...

Websocket ist ein Binärprotokoll. �~� codiert einen Nachrichtentyp und eine Länge.
Entschuldigung, ich kann Ihnen nicht helfen, ohne dass Sie daran beteiligt sind, es zu dekodieren und mit der tatsächlichen Nutzlastgröße zu vergleichen.

�~� ist 001111110111111000111111 in binärer Form, dh: 3F7E3F in hex.

Diese Bytes sehen wie diese Ende-zu-Ende aus ...
00111111
01111110
00111111

Ich bin kein Experte für RFC, aber was sagt das in Bezug auf Typ und Länge aus?

Glaubst du, das Problem liegt darin? Dh es stimmt nicht mit der tatsächlichen Nutzlastlänge überein und das Ding wartet zum Beispiel auf einen zusätzlichen Frame?

Interessanterweise verarbeitet dieser in go geschriebene

`` `
ws ws: // skyq: 9006 / as / system / status
<{
"camessage": {
"Grund": "keine Nachricht",
"state": "nicht verfügbar"
},
"drmstatus": {
"state": "available"
},
"Ansprüche": [
"ANALYTICS",
"BIGBASIC",
"ETHAN_APP_1",
"HD",
"PDL",
"SKY_DRM_CE",
"SKY_DRM_MR",
"SKY_IPPV",
"ULTRA +",
"SKY +",
"GATEWAYENABLER",
"SIDELOAD"
],
"epginfobits": {
"epginfobits": "0xFDE5FFC0",
"Maske": "0x5FFA003F",
"state": "available"
},
"gatewayservices": {
"state": "available"
},
"hdmi": {
"2160p10bitCapable": false,
"authenticatedHDCP": "NONE",
"Grund": "HDMI-Ausgangsanschluss ist deaktiviert",
"sinkHDCP": "NONE",
"sinkHLG": falsch,
"sinkUHD": false,
"state": "nicht verfügbar",
"uhdConfigured": false
},
"Netzwerk": {
"state": "available"
},
"nssplayback": {
"state": "available"
},
"pvr": {
"state": "available"
},
"Zeitplan" : {
"lastdate": "20181003",
"state": "available"
},
"Serviceliste": {
"state": "available"
},
"Chipkarte" : {
"aktiv": wahr,
"Bouquet": "4101",
"countryCode": "GBR",
"Währung": "GBP",
"cwe": wahr,
"Haushalts-ID": "10947783",
"gepaart": wahr,
"state": "available",
"Subbouquet": "1",
"Transaktionslimit": 65535,
"ViewingCardNumber": "725 325 260"
},
"swupdate": {
"Grund": "LEERLAUF",
"state": "nicht verfügbar"
},
"Systemaktualisierung" : {
"Ansprüche": 2,
"install": 1,
"servicegenres": 1,
"Smartcard": 1
},
"updatetask": {
"Grund": "kein Update",
"state": "nicht verfügbar"
}}
}}

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

Das Protokoll besagt: Das erste 3F Byte in der WS-Nachricht ist verboten (für zukünftige Verwendung reserviert).
Bist du sicher, dass du etwas nicht verpasst hast?

Ich gehe davon aus, dass Sie sich auf das 2., 3. und 4. Bit im Basis-Framing-Protokoll beziehen. In diesem Fall ja, vielleicht habe ich es falsch verstanden. Es könnte sich um ein Unicode / ASCII-Problem handeln. Ich werde noch einen Blick darauf werfen.

Ich habe ein paar andere Online-Konverter ausprobiert ... Ich bekomme das jetzt:
hex = ef bf bd 7e ef bf bd
binär = 11101111 10111111 10111101 01111110 11101111 10111111 10111101

Wenn nach 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_.

Dann sieht es so aus, als würden RSV1 und RSV2 auf 1 gesetzt, wie Sie vorschlagen, es sei denn, es wird über eine gewisse Spannung verhandelt? Ich habe keine Ahnung.

Die Anzahl der Zeichen im JSON-Dokument beträgt 1703

Der RFC sagt dies über die Nutzlastlänge:

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".

Also, angesichts all dessen, wohin gehen wir als nächstes? Wenn der Server hirntot und nicht RFC-kompatibel ist, muss ich ihn umgehen, wie es andere Clients eindeutig können ... Können Sie Vorschläge machen?

Sieht immer noch verdächtig aus.
Die einzige bekannte Erweiterung ist die WebSocket-Komprimierung, bei der RSV1 verwendet wird. Ich weiß nicht, welche Erweiterung RSV2 verwendet.
Darüber hinaus ist auch der Opcode FF reserviert und sollte nicht verwendet werden.

Wenn Sie nicht wissen, was der Server sendet, können Sie einen Client nicht "reparieren".

@asvetlov Ich habe die websockets -Bibliothek ausprobiert und sie funktioniert ... Also werde ich damit weitermachen, da ich nicht mehr Zeit damit verbringen kann, diese Bibliothek mit Ihnen zu debuggen ...

aoihttp - funktioniert nicht

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 - funktioniert

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

Sie können dieses Ticket gerne schließen, wenn Sie möchten, aber Sie möchten es möglicherweise offen halten, da es sich anscheinend um einen Fehler handelt ... oder zumindest um eine Situation, die nicht dem Gesetz von Postel entspricht.

Ich schätze Ihre Hilfe bei dem Versuch, dies anzugehen.

Sieht immer noch verdächtig aus.
Die einzige bekannte Erweiterung ist die WebSocket-Komprimierung, bei der RSV1 verwendet wird. Ich weiß nicht, welche Erweiterung RSV2 verwendet.
Darüber hinaus ist auch der Opcode FF reserviert und sollte nicht verwendet werden.

Hallo @asvetlov

Wenn Sie nicht wissen, was der Server sendet, können Sie einen Client nicht "reparieren".

Ich denke, Sie meinten: "Wenn Sie nicht wissen, was ein Server sendet, können Sie keinen Client reparieren."

In diesem Fall stimme ich diesem Punkt überhaupt nicht zu.

Sie kennen das Robustheitsprinzip ?

"Seien Sie konservativ in dem, was Sie senden, und liberal in dem, was Sie empfangen."

Unabhängig von MUSTs und SHOULDs und MUST NOTs, im RFC, denke ich, dass Sie Entitäten interpretieren und erwarten, dass sie den RFC vollständig einhalten schreckliche bastardisierte Halbimplementierungen von Protokollen.

Eine gute Bibliotheks- / Protokollimplementierung muss diese so weit wie möglich verzeihen. Siehe RFC1122 . Es ist durchaus möglich, einen Protokollclient zu schreiben, um (einige) Protokollverletzungen zu verzeihen, ohne Zugriff auf den anderen Teilnehmer an der Kommunikation zu haben.

Ich bin der Meinung, dass dies hier nicht der Fall ist. Sie scheinen die harte Ansicht zu vertreten, dass wir nicht mit ihm sprechen werden, wenn ein Host nicht 100% konform ist. Das ist schade. Es ist wie zu sagen: "Ich spreche nur das Englisch der Königin, und wenn Sie mit mir in einem seltsamen Dialekt des Englischen sprechen, werde ich nicht mit Ihnen sprechen."

Dies ist eindeutig kein guter Ansatz, wenn der Sinn der Bibliothek darin besteht, die Kommunikation zu erleichtern.

Mein Vorschlag ist daher, zu überlegen, wo Sie die strengen Anforderungen des Protokolls lockern können (möglicherweise über Methodenkwargs, die die "entspannte" Handhabung aktivieren) und zu prüfen, ob Sie die Dinge zum Sprechen bringen können, auch wenn sich die andere Seite nicht richtig verhält .

Abgesehen von dieser Kritik möchte ich Ihnen und den Mitwirkenden von aio-libs für all Ihre Arbeit für die Community danken. 👍 🥇

@asvetlov Nur ein Update dazu ... Ich habe herausgefunden, dass mein (nicht kompatibler) Server einen Großbuchstaben Upgrade: bevor er funktioniert. Ich dachte nur, ich würde es erwähnen, falls das Problem der Titelfall-Header von euch in Betracht gezogen wird ... Dies ist ein realer Fall einer Protokollverletzung von einem schlecht implementierten Server, die dazu führt, dass der Websocket-Client nicht funktioniert.