Aiohttp: Websocket 클라이언트 중단 / 차단?

GitMate.io 는 관련 문제가 https://github.com/aio-libs/aiohttp/issues/2200 (백그라운드 클라이언트 웹 소켓이 SIGINT에서 중단됨), https://github.com/aio-libs/aiohttp/issues/ 라고 생각합니다. 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를 존중하지 않습니다 ... 그리고 페이로드에 이상한 �~� 가 있습니다 ... 그것이 opcode인지 또는 다른 특이한 지 확실하지 않습니다 ...

Websocket은 바이너리 프로토콜입니다. �~� 는 메시지 유형과 길이를 인코딩합니다.
죄송합니다. 디코딩에 참여하고 실제 페이로드 크기와 비교하지 않으면 도와 드릴 수 없습니다.

�~� 이다 001111110111111000111111 : 인 이진 3F7E3F 진수있다.

이러한 바이트는이 엔드 투 엔드처럼 보입니다.
00111111
01111110
00111111

나는 RFC의 전문가는 아니지만 유형과 길이 측면에서 무엇을 말하는가?

그게 문제라고 생각하세요? 즉, 실제 페이로드 길이에 동의하지 않고 추가 프레임을 기다리는 것과 같은 것입니까?

흥미롭게도 go로 작성된 이 웹 소켓 cli 클라이언트 는 상단에있는 바이너리를 포함하여 출력을 잘 처리합니다.

```
ws ws : // skyq : 9006 / as / system / status
<{
"camessage": {
"reason": "메시지 없음",
"상태": "사용할 수 없음"
},
"drmstatus": {
"상태": "사용 가능"
},
"entitlements": [
"해석학",
"BIGBASIC",
"ETHAN_APP_1",
"HD",
"PDL",
"SKY_DRM_CE",
"SKY_DRM_MR",
"SKY_IPPV",
"ULTRA +",
"SKY +",
"GATEWAYENABLER",
"사이드로드"
],
"epginfobits": {
"epginfobits": "0xFDE5FFC0",
"마스크": "0x5FFA003F",
"상태": "사용 가능"
},
"gatewayservices": {
"상태": "사용 가능"
},
"hdmi": {
"2160p10bitCapable": 거짓,
"authenticatedHDCP": "없음",
"reason": "HDMI 출력 포트 비활성화 됨",
"sinkHDCP": "없음",
"sinkHLG": 거짓,
"sinkUHD": 거짓,
"상태": "사용할 수 없음",
"uhdConfigured": false
},
"네트워크": {
"상태": "사용 가능"
},
"nssplayback": {
"상태": "사용 가능"
},
"pvr": {
"상태": "사용 가능"
},
"일정": {
"lastdate": "20181003",
"상태": "사용 가능"
},
"servicelist": {
"상태": "사용 가능"
},
"스마트 카드" : {
"활성": 참,
"꽃다발": "4101",
"countryCode": "GBR",
"통화": "GBP",
"cwe": 참,
"가정용": "10947783",
"paired": 참,
"상태": "사용 가능",
"subbouquet": "1",
"transactionlimit": 65535,
"viewingCardNumber": "725325260"
},
"swupdate": {
"reason": "IDLE",
"상태": "사용할 수 없음"
},
"시스템 업데이트" : {
"entitlements": 2,
"설치": 1,
"servicegenres": 1,
"스마트 카드": 1
},
"updatetask": {
"reason": "업데이트 없음",
"상태": "사용할 수 없음"
}
}

^ C
일시 정지
✔ [ brad @ bradmac : ~] $```

프로토콜에 따르면 WS 메시지의 첫 번째 3F 바이트는 금지되어 있습니다 (향후 사용을 위해 예약 됨).
당신은 뭔가를 놓친 것이 확실합니까?

기본 프레이밍 프로토콜에서 2d, 3rd 및 4th 비트를 참조한다고 가정합니다. 어떤 경우에는 예, 아마도 내가 잘못했을 것입니다. 유니 코드 / ASCII 문제 일 수 있습니다. 다시 한번 살펴 볼게요.

몇 가지 다른 온라인 변환기를 사용해 보았습니다 ... 지금 받고 있습니다.
16 진수 = 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를 준수하지 않는 경우 다른 클라이언트가 분명히 할 수있는 것처럼 문제를 해결해야합니다. 제안 할 수 있습니까?

여전히 의심스러워 보입니다.
알려진 유일한 확장은 RSV1을 사용하는 WebSocket 압축입니다. 어떤 확장 프로그램이 RSV2를 사용하는지 모르겠습니다.
또한 opcode 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())

원하는 경우이 티켓을 무료로 닫을 수 있지만 버그로 보이기 때문에 열어 두는 것이 좋습니다. 또는 적어도 Postel의 법을 준수하지 않는 상황.

이 문제를 해결하는 데 도움을 주셔서 감사합니다.

여전히 의심스러워 보입니다.
알려진 유일한 확장은 RSV1을 사용하는 WebSocket 압축입니다. 어떤 확장 프로그램이 RSV2를 사용하는지 모르겠습니다.
또한 opcode FF도 예약되어 있으므로 사용해서는 안됩니다.

안녕하세요 @asvetlov

서버가 무엇을 전송하는지 모르지 않는 한 클라이언트를 "고칠"방법이 없습니다.

나는 당신이 의미 생각 ", 당신은 서버가 보내는 알고하지 않는 한, 당신은 클라이언트를 해결할 수 없습니다."

어떤 경우에는이 점에 완전히 동의하지 않습니다.

견고성 원칙에 대해 잘 알고 있습니까?

"보내는 것은 보수적이며받는 것은 자유로 워야합니다."

반드시해야 할 것,해야하는 것,하지 말아야 할 것에 관계없이, RFC에서 엔티티가 RFC _completely _...를 준수 할 것으로 해석하고 기대하고 있다고 생각합니다. 분명히 그들은 그렇지 않으며 다양한 유형의 많은 인터넷 서버와 클라이언트가 끔찍한 멍청한 프로토콜의 절반 구현.

좋은 라이브러리 / 프로토콜 구현은 가능한 한이를 용서해야합니다. RFC1122를 참조하십시오. 통신에서 다른 참가자에게 액세스하지 않고도 (일부) 프로토콜 위반을 용서하도록 프로토콜 클라이언트를 작성할 수 있습니다.

여기서는 그렇지 않다고 생각합니다. 호스트가 100 % 규정을 준수하지 않으면 너무 나쁘면 이야기하지 않을 것이라는 강경 한 견해를 가지고있는 것 같습니다. 이것은 너무 나쁘다. 그것은 마치 '나는 여왕의 영어 만 할 줄 압니다. 당신이 이상한 영어 방언으로 나에게 말하면 나는 당신에게 말하지 않을 것입니다.'

도서관의 전체 요점이 의사 소통을 용이하게하는 것이라면 분명히 이것은 좋은 접근 방식이 아닙니다.

따라서 내 제안은 프로토콜의 엄격한 요구 사항을 완화 할 수있는 곳을 고려하고 (아마도 "완전한"처리를 켜는 방법 kwargs를 통해) 상대방이 제대로 작동하지 않을 때도 말을 할 수 있는지 확인하는 것입니다. .

이 비평 외에도 커뮤니티를위한 모든 작업에 대해 aio-libs 의 기여자 및 귀하에게 감사드립니다. 👍 🥇

@asvetlov 이것에 대한 업데이트입니다 ... 제 (비 규격) 서버가 작동하기 전에 대문자 Upgrade: 헤더가 필요하다는 것을 알아 냈습니다. 제목 케이스 헤더 문제를 고려하는 경우에 언급 할 것이라고 생각했습니다. 이것은 제대로 구현되지 않은 서버의 프로토콜 위반으로 인해 웹 소켓 클라이언트가 작동하지 않는 실제 사례입니다 ..