Aiohttp: Websocket क्लाइंट हैंगिंग / ब्लॉकिंग?

GitMate.io को लगता है कि संभवतः संबंधित मुद्दे https://github.com/aio-libs/aiohttp/issues/2200 (पृष्ठभूमि ग्राहक वेबसाइकेट SIGINT पर लटके हुए हैं), https://github.com/aio-libs/aiohttp/issues/ 1002 (Websocket response .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 नहीं लौट रहा है ... कोई विचार?

सर्वर एक स्काईक्यू सेट-टॉप बॉक्स है, इसलिए पूरी तरह से डब्ल्यूएस के आरएफसी-अनुपालन कार्यान्वयन नहीं हो सकता है। उदाहरण के लिए, यह पिंग / कविताओं का सम्मान नहीं करता है ... और पेलोड में अजीब �~� है ... निश्चित नहीं है कि यह एक ओपकोड या कुछ अन्य क्विक है ...

Websocket एक बाइनरी प्रोटोकॉल �~� एक संदेश प्रकार और लंबाई एन्कोड करता है।
क्षमा करें, मैं इसे डिकोड करने और वास्तविक पेलोड आकार की तुलना में आपकी भागीदारी के बिना आपकी मदद नहीं कर सकता।

�~� बाइनरी में 001111110111111000111111 है, जो है: हेक्स में 3F7E3F ।

उन बाइट्स इस अंत करने के लिए की तरह लग रहे हो ...
00111111
01111110
00111111

मैं वें RFC का विशेषज्ञ नहीं हूं, लेकिन यह प्रकार और लंबाई के संदर्भ में क्या कह रहा है?

क्या आपको लगता है कि समस्या इसके साथ है? यानी, यह वास्तविक पेलोड लंबाई से सहमत नहीं है, और एक अतिरिक्त फ्रेम के लिए इंतजार कर रही चीज, उदाहरण के लिए?

दिलचस्प है, यह वेब सॉकेट क्ली क्लाइंट , जो लिखा है, आउटपुट आउटपुट को संभालता है, जिसमें शीर्ष पर बाइनरी सामान शामिल है:

`` `
ws ws: // skyq: 9006 / as / system / स्थिति
<{
"छलावा": {
"कारण": "कोई संदेश नहीं",
"राज्य": "अनुपलब्ध"
},
"ड्रमस्टैटस": {
"राज्य": "उपलब्ध"
},
"हकदार": [
"विश्लेषण",
"BIGBASIC",
"ETHAN_APP_1",
"एचडी",
"पीडीएल",
"SKY_DRM_CE",
"SKY_DRM_MR",
"SKY_IPPV",
"अल्ट्रा +",
"SKY +",
"GATEWAYENABLER",
"सिडलॉड"
],
"एपिनेफोबिट्स": {
"एपिनेफोबिट्स": "0xFDE5FFC0",
"मास्क": "0x5FFA003F",
"राज्य": "उपलब्ध"
},
"द्वारपाल": {
"राज्य": "उपलब्ध"
},
"hdmi": {
"2160p10bitCapable": गलत,
"प्रमाणीकृतHDCP": "कोई नहीं",
"कारण": "एचडीएमआई आउटपुट पोर्ट अक्षम है",
"सिंकएचडीसीपी": "नोन",
"सिंकएचएलजी": गलत,
"सिंकयूएचडी": गलत,
"राज्य": "अनुपलब्ध",
"uhdConfigured": असत्य
},
"नेटवर्क" : {
"राज्य": "उपलब्ध"
},
"nssplayback": {
"राज्य": "उपलब्ध"
},
"pvr": {
"राज्य": "उपलब्ध"
},
"अनुसूची" : {
"अंतिम तिथि": "20181003",
"राज्य": "उपलब्ध"
},
"सर्विसलिस्ट": {
"राज्य": "उपलब्ध"
},
"स्मार्ट कार्ड" : {
"सक्रिय": सच,
"गुलदस्ता": "4101",
"देशकोड": "GBR",
"मुद्रा": "GBP",
"cwe": सच है,
"गृहस्थ": "10947783",
"बनती": सच,
"राज्य": "उपलब्ध",
"सबबॉकेट": "1",
"लेन-देन संबंधी": 65535,
"व्यूअरकार्डनंबर": "725 325 260"
},
"स्वपद": {
"कारण": "IDLE",
"राज्य": "अनुपलब्ध"
},
"सिस्टम अपडेट" : {
"एंटाइटेलमेंट": 2,
"इंस्टॉल करें": 1,
"सेवायोजन": 1,
"स्मार्टकार्ड": 1
},
"updatetask": {
"कारण": "कोई अद्यतन नहीं",
"राज्य": "अनुपलब्ध"
}
}

^ सी
इंटरप्ट
✔ [ ब्रैड @ ब्रैडमैक : ~] $ `` `

प्रोटोकॉल कहता है: WS संदेश में पहला 3F बाइट निषिद्ध है (भविष्य के उपयोग के लिए आरक्षित)।
क्या आप वाकई कुछ याद नहीं कर रहे हैं?

मुझे लगता है कि आप बेस फ्रेमिंग प्रोटोकॉल में 2d, 3rd और 4th बिट का जिक्र कर रहे हैं। किस मामले में हां, शायद मुझे गलत लगा। यह एक यूनिकोड / 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 किस एक्सटेंशन का उपयोग करता है।
इसके अलावा, 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())

यदि आप चाहें तो इस टिकट को बंद करने के लिए शुल्क मुक्त कर सकते हैं, लेकिन आप इसे खुला रखना चाह सकते हैं क्योंकि यह एक बग प्रतीत होता है ... या कम से कम ऐसी स्थिति जो पोस्टेल के नियम का पालन नहीं करती है।

मैं इसे संबोधित करने की कोशिश में आपकी मदद की सराहना करता हूं।

अभी भी संदिग्ध लग रहा है।
एकमात्र ज्ञात एक्सटेंशन WebSocket संपीड़न है जो RSV1 का उपयोग करता है। मुझे नहीं पता कि RSV2 किस एक्सटेंशन का उपयोग करता है।
इसके अलावा, opcode FF भी आरक्षित है और इसका उपयोग नहीं किया जाना चाहिए।

हाय @ सत्सलोव

जब तक आप नहीं जानते कि सर्वर क्या भेजता है, तो क्लाइंट को "ठीक" करने का कोई तरीका नहीं है।

मुझे लगता है कि आपका मतलब था "जब तक, आप नहीं जानते कि एक सर्वर क्या भेजता है, आप एक ग्राहक को ठीक नहीं कर सकते।"

इस मामले में, मैं इस बात से पूरी तरह असहमत हूं।

आप रोबस्टनेस सिद्धांत से परिचित हैं?

"जो आप भेजते हैं, उसमें रूढ़िवादी रहें और जो आप प्राप्त करते हैं उसमें उदार हो।"

MFC और SHOULDs और MUST NOTs के बावजूद, RFC में, मुझे लगता है कि आप RFC के साथ अनुपालन की अपेक्षा कर रहे हैं और अपेक्षा कर रहे हैं _completely _... स्पष्ट रूप से वे नहीं करते हैं, और कई इंटरनेट सर्वर और क्लाइंट विभिन्न प्रकारों के हैं, भयावह bastardised प्रोटोकॉल के आधे-कार्यान्वयन।

एक अच्छा पुस्तकालय / प्रोटोकोल कार्यान्वयन इनको इस सीमा तक क्षमा कर देना चाहिए। RFC1122 देखें। संचार में दूसरे प्रतिभागी तक पहुंच के बिना (कुछ) प्रोटोकॉल के उल्लंघन को माफ करने के लिए एक प्रोटोकॉल क्लाइंट लिखना पूरी तरह से संभव है।

मुझे लगता है कि यहां ऐसा नहीं है, आप हार्ड-लाइन को देखते हुए कहते हैं कि यदि कोई मेजबान 100% अनुपालन नहीं करता है, तो इसके लिए बहुत बुरा है, हम इसके बारे में बात नहीं करेंगे। यह बहुत बुरा है। यह कहने जैसा है: 'मैं केवल महारानी की अंग्रेजी बोलता हूं, और यदि आप मुझसे अंग्रेजी की कुछ अजीब बोली में बात करते हैं, तो मैं आपसे बात नहीं करूंगा।'

स्पष्ट रूप से यह एक अच्छा दृष्टिकोण नहीं है यदि पुस्तकालय का पूरा बिंदु संचार की सुविधा के लिए है।

इसलिए मेरा सुझाव है कि आप इस बात पर विचार करें कि आप प्रोटोकॉल की कठोर आवश्यकताओं को कैसे शांत कर सकते हैं (हो सकता है कि विधि kwargs के माध्यम से, जो "आराम से निपटने" को चालू करें), और देखें कि क्या आप चीजों को तब भी बात कर सकते हैं जब दूसरा पक्ष ठीक से व्यवहार नहीं कर रहा हो। ।

इस समालोचना के अलावा, मैं समुदाय के लिए आपके सभी कार्यों के लिए aio-libs का योगदान देना चाहता हूं। 👍 👍

@asvetlov इस पर सिर्फ एक अपडेट ... मुझे लगा कि मेरे (गैर-आज्ञाकारी) सर्वर को काम करने से पहले एक Upgrade: हैडर की आवश्यकता होगी। मैंने सोचा था कि मैं इसका उल्लेख करूंगा कि शीर्षक केस हेडर के मुद्दे पर आप लोगों द्वारा विचार किया जा रहा है ... यह एक खराब कार्यान्वित सर्वर से प्रोटोकॉल उल्लंघन का एक वास्तविक मामला है जो वेबसोकेट क्लाइंट के काम न करने का कारण बनता है।