Aiohttp: Зависание / блокировка клиента websocket?

GitMate.io считает, что, возможно, связанные проблемы: https://github.com/aio-libs/aiohttp/issues/2200 (фоновые клиентские веб-сайты зависают на SIGINT), https://github.com/aio-libs/aiohttp/issues/ 1002 (ответ Websocket .close () может зависать бесконечно), https://github.com/aio-libs/aiohttp/issues/376 (зависает ProactorEventLoop), https://github.com/aio-libs/aiohttp/issues / 3027 (зависание ws_connect) и https://github.com/aio-libs/aiohttp/issues/265 (реализация веб-сокета на стороне клиента).

похоже, client_ws.py # L204 не возвращает ... какие-нибудь идеи?

Сервер представляет собой телеприставку SkyQ, поэтому реализация WS может не полностью соответствовать RFC. Например, он не соблюдает ping / poings ... И в полезной нагрузке есть странный �~� ... Не уверен, что это код операции или какая-то другая причуда ...

Websocket - это двоичный протокол. �~� кодирует тип и длину сообщения.
Извините, я не могу вам помочь без вашего участия в его расшифровке и сравнении с фактическим размером полезной нагрузки.

�~� - это 001111110111111000111111 в двоичном формате, то есть 3F7E3F в шестнадцатеричном формате.

эти байты выглядят как сквозные ...
00111111
01111110
00111111

Я не эксперт по RFC, но что там говорится о типе и длине?

Как вы думаете, проблема в этом? Т.е. это не согласие с реальной длиной полезной нагрузки, а то, что ожидает, например, лишнего кадра?

Интересно, что этот клиент cli веб-сокета , написанный на go, отлично обрабатывает вывод, включая двоичный материал вверху:

``
WS WS: // SkyQ: 9006 / как / система / статус
<{
"camessage": {
"причина": "нет сообщения",
"состояние": "недоступно"
},
"drmstatus": {
"состояние": "доступно"
},
"права": [
«АНАЛИТИКА»,
"BIGBASIC",
"ETHAN_APP_1",
"HD",
«ПДЛ»,
"SKY_DRM_CE",
"SKY_DRM_MR",
"SKY_IPPV",
"УЛЬТРА +",
"НЕБО +",
"ШЛЮЗИНАБЛЕР",
"SIDELOAD"
],
"epginfobits": {
"epginfobits": "0xFDE5FFC0",
"маска": "0x5FFA003F",
"состояние": "доступно"
},
"gatewayservices": {
"состояние": "доступно"
},
"hdmi": {
"2160p10bitCapable": false,
"AuthenticatedHDCP": "НЕТ",
"причина": "Выходной порт HDMI отключен",
"inkHDCP ":" НЕТ ",
"inkHLG ": ложь,
"inkUHD ": ложь,
"состояние": "недоступно",
"uhdConfigured": ложь
},
"сеть" : {
"состояние": "доступно"
},
"nssplayback": {
"состояние": "доступно"
},
"pvr": {
"состояние": "доступно"
},
"расписание" : {
"lastdate": "20181003",
"состояние": "доступно"
},
"перечень услуг" : {
"состояние": "доступно"
},
"интеллектуальная карточка" : {
"активный": правда,
«букет»: «4101»,
"countryCode": "GBR",
«валюта»: «фунты стерлингов»,
"cwe": правда,
"homeid": "10947783",
"парный": правда,
"состояние": "доступно",
"суббукет": "1",
«transactionlimit»: 65535,
"viewCardNumber": "725 325 260"
},
"swupdate": {
"причина": "ПРОСТОЙ",
"состояние": "недоступно"
},
"системные обновления" : {
«права»: 2,
«установить»: 1,
"servicegenres": 1,
«смарт-карта»: 1
},
"updatetask": {
"причина": "нет обновлений",
"состояние": "недоступно"
}
}

^ C
Прерывать
✔ [ brad @ bradmac : ~] $ `` `

Протокол гласит: первый байт 3F в WS-сообщении запрещен (зарезервирован для использования в будущем).
Вы уверены, что что-то не пропустили?

Я предполагаю, что вы имеете в виду 2-й, 3-й и 4-й бит в базовом протоколе кадрирования. В таком случае да, возможно, я ошибся. Это может быть проблема с Unicode / ASCII. Я посмотрю еще раз.

Я пробовал несколько других онлайн-конвертеров ... Я получаю вот что:
шестнадцатеричный = ef bf bd 7e ef bf bd
двоичный = 11101111 10111111 10111101 01111110 11101111 10111111 10111101

Если в соответствии с 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_.

Тогда похоже, что RSV1 и RSV2 устанавливаются в 1, как вы предлагаете, если не ведутся переговоры о каком-то etxension? Я понятия не имею.

Количество символов в документе JSON: 1703

RFC говорит о длине полезной нагрузки:

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

Итак, учитывая все это, куда мы пойдем дальше? Если сервер «мертвый мозг» и не соответствует RFC, то мне нужно обойти это, поскольку другие клиенты явно могут это сделать ... Можете ли вы предложить какие-либо предложения?

По-прежнему выглядит подозрительно.
Единственное известное расширение - это сжатие WebSocket, использующее RSV1. Я не знаю, какое расширение использует RSV2.
Более того, код операции FF тоже зарезервирован и не должен использоваться.

Если вы не знаете, что отправляет сервер, невозможно «исправить» клиента.

@asvetlov Я попробовал библиотеку websockets и она работает ... Так что я собираюсь пойти с ней, так как я не могу тратить больше времени на отладку этой библиотеки с вами ...

aoihttp - не работает

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 - работает

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

Вы можете бесплатно закрыть этот билет, если хотите, но вы можете оставить его открытым, поскольку он действительно выглядит ошибкой ... Или, по крайней мере, ситуацией, которая не подчиняется закону Постела.

Я ценю вашу помощь в попытке решить эту проблему.

По-прежнему выглядит подозрительно.
Единственное известное расширение - это сжатие WebSocket, использующее RSV1. Я не знаю, какое расширение использует RSV2.
Более того, код операции FF тоже зарезервирован и не должен использоваться.

Привет @asvetlov

Если вы не знаете, что отправляет сервер, невозможно «исправить» клиента.

Я думаю, вы имели в виду «если вы не знаете, что отправляет сервер, вы не можете исправить клиента».

В таком случае я полностью не согласен с этим.

Вы знакомы с принципом устойчивости ?

«Будьте консервативными в том, что вы посылаете, и либеральными в том, что получаете».

Независимо от ДОЛЖЕН, ДОЛЖЕН и НЕ ДОЛЖЕН, в RFC, я думаю, вы интерпретируете и ожидаете, что объекты будут соответствовать RFC _ полностью _... Ясно, что они этого не делают, и многие многие интернет-серверы и клиенты различных типов имеют ужасные ублюдочные полуреализации протоколов.

Хорошая реализация библиотеки / протокола должна прощать их по мере возможности. См. RFC1122 . Вполне возможно написать клиента протокола, прощающего (некоторые) нарушения протокола, не имея доступа к другому участнику связи.

Я считаю, что здесь дело обстоит не так, похоже, вы придерживаетесь жесткой точки зрения, что если хост не на 100% соответствует требованиям, то это плохо для него, мы не будем с ним разговаривать. Это очень плохо. Это как сказать: «Я говорю только на королевском английском, и если вы заговорите со мной на каком-то странном диалекте английского языка, я не стану с вами разговаривать».

Ясно, что это не лучший подход, если вся задача библиотеки - облегчить общение.

Поэтому я предлагаю подумать, где вы можете ослабить строгие требования протокола (возможно, с помощью метода kwargs, который включает "расслабленную" обработку), и посмотреть, сможете ли вы заставить вещи говорить, даже когда другая сторона не ведет себя должным образом. .

Помимо этой критики, я хотел бы поблагодарить вас и участников из aio-libs за всю вашу работу для сообщества. 👍 🥇

@asvetlov Просто обновите это ... Я понял, что моему (несовместимому) серверу требуется заголовок Upgrade: в верхнем регистре, прежде чем он заработает. Просто подумал, что упомяну об этом, если проблема заголовков Title Case рассматривается вами, ребята ... Это реальный случай нарушения протокола из-за плохо реализованного сервера, из-за которого клиент websocket не работает ..