Aiohttp: Klien Websocket menggantung / memblokir?

GitMate.io berpikir kemungkinan masalah terkait adalah https://github.com/aio-libs/aiohttp/issues/2200 (latar belakang websockets Klien tergantung di SIGINT), https://github.com/aio-libs/aiohttp/issues/ 1002 (Respons Websocket .close () dapat hang tanpa batas waktu), https://github.com/aio-libs/aiohttp/issues/376 (ProactorEventLoop hang), https://github.com/aio-libs/aiohttp/issues / 3027 (ws_connect hang), dan https://github.com/aio-libs/aiohttp/issues/265 (Menerapkan websocket sisi klien).

sepertinya client_ws.py # L204 tidak kembali ... ada ide?

Server adalah kotak set-top SkyQ, jadi mungkin tidak sepenuhnya implementasi WS yang sesuai dengan RFC. Misalnya, itu tidak menghormati ping / poings ... Dan ada �~� yang aneh dalam muatannya ... Tidak yakin apakah itu opcode atau beberapa quirk lainnya ...

Websocket adalah protokol biner �~� mengkodekan jenis dan panjang pesan.
Maaf, saya tidak dapat membantu Anda tanpa partisipasi Anda dalam mendekodekan dan membandingkan dengan ukuran muatan sebenarnya.

�~� adalah 001111110111111000111111 dalam biner, yaitu: 3F7E3F dalam hex.

byte-byte itu terlihat seperti ini ujung-ke-ujung ...
00111111
01111110
00111111

Saya bukan ahli di RFC, tapi apa yang dikatakan ini dalam hal jenis dan panjang?

Apakah menurut Anda masalahnya ada pada hal itu? Yaitu, itu tidak menyetujui panjang muatan yang sebenarnya, dan hal yang menunggu bingkai tambahan, misalnya?

Menariknya, klien cli soket web ini , ditulis dalam go, menangani output dengan baik, termasuk hal-hal biner di atas:

``
ws ws: // skyq: 9006 / as / system / status
<{
"camessage": {
"alasan": "tidak ada pesan",
"state": "tidak tersedia"
},
"drmstatus": {
"state": "tersedia"
},
"hak" : [
"ANALYTICS",
"BIGBASIC",
"ETHAN_APP_1",
"HD",
"PDL",
"SKY_DRM_CE",
"SKY_DRM_MR",
"SKY_IPPV",
"ULTRA +",
"SKY +",
"GATEWAYENABLER",
"SIDELOAD"
],
"epginfobits": {
"epginfobits": "0xFDE5FFC0",
"topeng": "0x5FFA003F",
"state": "tersedia"
},
"gatewayservices": {
"negara bagian": "tersedia"
},
"HDMI": {
"2160p10bitCapable": salah,
"otentikasiHDCP": "TIDAK ADA",
"alasan": "Porta keluaran HDMI dinonaktifkan",
"sinkHDCP": "NONE",
"sinkHLG": salah,
"sinkUHD": salah,
"state": "tidak tersedia",
"uhdConfigured": salah
},
"jaringan": {
"negara bagian": "tersedia"
},
"nssplayback": {
"negara bagian": "tersedia"
},
"pvr": {
"negara bagian": "tersedia"
},
"susunan acara" : {
"lastdate": "20181003",
"state": "tersedia"
},
"servicelist": {
"negara bagian": "tersedia"
},
"kartu pintar" : {
"aktif": benar,
"buket": "4101",
"countryCode": "GBR",
"currency": "GBP",
"cwe": benar,
"rumah tangga": "10947783",
"berpasangan": benar,
"state": "tersedia",
"subbouquet": "1",
"transactionlimit": 65535,
"melihatCardNumber": "725 325 260"
},
"swupdate": {
"alasan": "IDLE",
"state": "tidak tersedia"
},
"pembaruan sistem" : {
"hak": 2,
"instal": 1,
"servicegenres": 1,
"smartcard": 1
},
"tugas pembaharuan": {
"alasan": "tidak ada pembaruan",
"state": "tidak tersedia"
}
}

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

Protokol mengatakan: 3F byte pertama dalam pesan WS dilarang (dicadangkan untuk penggunaan di masa mendatang).
Anda yakin tidak melewatkan sesuatu?

Saya berasumsi bahwa Anda mengacu pada bit 2d, 3 dan 4 dalam protokol framing dasar. Dalam hal ini ya, mungkin saya salah. Ini bisa menjadi masalah unicode / ASCII. Saya akan melihat lagi.

Saya sudah mencoba beberapa konverter online lainnya ... Saya mendapatkan ini sekarang:
hex = ef bf bd 7e ef bf bd
biner = 11101111 10111111 10111101 01111110 11101111 10111111 10111101

Jika menurut 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_.

Maka sepertinya RSV1 dan RSV2 disetel ke 1, seperti yang Anda sarankan, kecuali beberapa etxension sedang dinegosiasikan? Saya tidak punya ide.

Jumlah karakter dalam dokumen JSON adalah 1703

RFC mengatakan ini tentang panjang muatan:

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

Jadi, mengingat semua itu, kemana kita pergi selanjutnya? Jika server mati otak dan tidak sesuai dengan RFC, maka saya perlu mengatasinya karena klien lain jelas dapat melakukannya ... Dapatkah Anda menawarkan saran?

Masih terlihat mencurigakan.
Satu-satunya ekstensi yang diketahui adalah kompresi WebSocket yang menggunakan RSV1. Saya tidak tahu ekstensi apa yang menggunakan RSV2.
Selain itu, opcode FF juga dicadangkan dan tidak boleh digunakan.

Kecuali Anda tidak tahu apa yang dikirim server, tidak ada cara untuk "memperbaiki" klien.

@asvetlov Saya mencoba perpustakaan websockets dan berhasil ... Jadi saya akan melakukannya, karena saya tidak dapat menghabiskan lebih banyak waktu untuk men-debug perpustakaan ini dengan Anda ...

aoihttp - tidak berfungsi

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

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

Bebas biaya untuk menutup tiket ini jika Anda mau, tetapi Anda mungkin ingin tetap membukanya karena tampaknya merupakan bug ... Atau setidaknya situasi yang tidak mematuhi hukum Postel.

Saya menghargai bantuan Anda dalam mencoba mengatasi ini.

Masih terlihat mencurigakan.
Satu-satunya ekstensi yang diketahui adalah kompresi WebSocket yang menggunakan RSV1. Saya tidak tahu ekstensi apa yang menggunakan RSV2.
Selain itu, opcode FF juga dicadangkan dan tidak boleh digunakan.

Halo @asvet

Kecuali Anda tidak tahu apa yang dikirim server, tidak ada cara untuk "memperbaiki" klien.

Saya pikir Anda berarti "kecuali, Anda tahu apa server mengirimkan, Anda tidak dapat memperbaiki klien."

Dalam hal ini, saya sama sekali tidak setuju dengan hal ini.

Anda akrab dengan Prinsip Kekokohan ?

"Bersikaplah konservatif dalam apa yang Anda kirim, dan liberal dalam apa yang Anda terima."

Terlepas dari KEHARUSAN dan HARUS dan HARUS TIDAK, di RFC, saya pikir Anda menafsirkan dan mengharapkan entitas untuk mematuhi RFC _secara lengkap _... Jelas tidak, dan banyak server dan klien internet di luar sana, dari berbagai jenis, memiliki implementasi setengah-setengah protokol yang menghebohkan.

Implementasi perpustakaan / protokol yang baik harus memaafkan ini sejauh mungkin. Lihat RFC1122 . Sangat mungkin untuk menulis klien protokol untuk memaafkan (beberapa) pelanggaran protokol tanpa memiliki akses ke peserta lain dalam komunikasi.

Saya merasa ini tidak terjadi di sini, Anda tampaknya mengambil pandangan garis keras bahwa jika tuan rumah tidak 100% patuh maka sayang sekali, kami tidak akan membicarakannya. Ini sangat buruk. Ini seperti mengatakan: 'Saya hanya berbicara bahasa Inggris Ratu, dan jika Anda datang berbicara dengan saya dalam dialek bahasa Inggris yang aneh, saya tidak akan berbicara dengan Anda.'

Jelas ini bukan pendekatan yang baik jika inti dari perpustakaan adalah memfasilitasi komunikasi.

Saran saya, oleh karena itu, adalah untuk mempertimbangkan di mana Anda dapat melonggarkan persyaratan ketat dari protokol (mungkin melalui metode kwargs, yang mengaktifkan penanganan "santai"), dan melihat apakah Anda dapat membuat segala sesuatunya berbicara bahkan ketika pihak lain tidak berperilaku dengan benar .

Selain kritik ini, saya ingin berterima kasih kepada Anda dan kontributor dari aio-libs atas semua pekerjaan Anda untuk komunitas. 👍 🥇

@asvetlov Hanya pembaruan tentang ini ... Saya menemukan bahwa server saya (tidak sesuai) memerlukan header Upgrade: huruf besar sebelum berfungsi. Hanya berpikir saya akan menyebutkannya jika masalah header Kasus Judul sedang dipertimbangkan oleh kalian ... Ini adalah kasus nyata pelanggaran protokol dari server yang diimplementasikan dengan buruk yang menyebabkan klien websocket tidak berfungsi ..