Socket.io: لماذا يستخدم socket.io اتصال websocket واستقصاء xhr بالتوازي؟

• "استقصاء XHR" ليس اتصالاً ، يمكن أن يستخدم أكثر من اتصال.
• لم تتم تهيئة عمليات نقل Websocket والاستقصاء بشكل متزامن ، حتى الآن. في الواقع ، هذا ما يفعله Engine.io وما سيفعله socket.io قريبًا بمجرد تنفيذه. اقرأ المزيد هنا وقد تعيد النظر في التصنيف "الغبي" ، ربما.

إذا كنت تواجه موقفًا يحتوي فيه socket.io 0.9 على وسيلتي نقل مفتوحتين في نفس الوقت ، فسيكون ذلك خطأ ، وسيكون موضع تقدير المزيد من المعلومات حول كيفية إعادة إنتاجه.

"استقصاء XHR" ليس اتصالاً ، يمكن أن يستخدم أكثر من اتصال.

نعم ، ولكن نظرًا لأن الاقتراع يعمل على نفس عنوان url لجميع الطلبات. أفترض أنه يجب أن يحاكي واحد.

إذا كنت تواجه موقفًا يحتوي فيه socket.io 0.9 على وسيلتي نقل مفتوحتين في نفس الوقت ، فسيكون ذلك خطأ ، وسيكون موضع تقدير المزيد من المعلومات حول كيفية إعادة إنتاجه.

لست متأكدًا مما إذا كنا نعني نفس الشيء ولكن: يظهر لي Chromium اتصال Websocket مفتوحًا ، بالإضافة إلى أنه يرسل طلبات الاقتراع إلى socket.io.
و"غبي" يعني الآن لا أستطيع أن اتباع الاستفادة من websocket صالحة للاستعمال ربط والاقتراع.
ألا يجب أن يكون اتصال websocket كافياً وأن يتم استخدام استقصاء xhr فقط كبديل؟

صححني إذا فاتني شيء

bodokaiser هل عمل اتصال websocket بالفعل أم أنه يرجع إلى الاقتراع؟

ضع في اعتبارك أن الاتصال هو HTTP عادي

يوضح لي Chrome أن اتصال Websocket معلق. لا توجد رسالة خطأ. أفترض أن ws يعمل. ومع ذلك ، كيف يمكنني التحقق مما إذا كان socket.io يتراجع؟

نعم ، إنها بالتأكيد ليست المصافحة. أرى في الكروم وفي وحدة تحكم العقدة كيف تتكرر طلبات الحصول كل 2000 مللي ثانية.

هل سيساعدك تسجيل node.js؟

يعتبر

افحص الإطارات التي تم تبادلها في اتصال ws (أعتقد أن Chrome فقط لديه هذا). إذا لم ترَ أي بيانات ، فهذا يعني أنها لم تنجح.

يبدو أن نعم يتراجع:

  debug - client authorized
   info  - handshake authorized yUEmr7drZfmWzWHdEZcp
GET /socket.io/1/?t=1344799805756 200 3ms
   debug - setting request GET /socket.io/1/xhr-polling/yUEmr7drZfmWzWHdEZcp?t=1344799815866
   debug - setting poll timeout
   debug - client authorized for 
   debug - clearing poll timeout
   debug - xhr-polling writing 1::
   debug - set close timeout for client yUEmr7drZfmWzWHdEZcp
GET /socket.io/1/xhr-polling/yUEmr7drZfmWzWHdEZcp?t=1344799815866 200 1ms
   debug - xhr-polling received data packet 5:::{"name":"hello","args":["world"]}
POST /socket.io/1/xhr-polling/yUEmr7drZfmWzWHdEZcp?t=1344799815871 200 1ms
   debug - setting request GET /socket.io/1/xhr-polling/yUEmr7drZfmWzWHdEZcp?t=1344799815872
   debug - setting poll timeout
   debug - discarding transport
   debug - cleared close timeout for client yUEmr7drZfmWzWHdEZcp
   debug - clearing poll timeout
   debug - xhr-polling writing 8::
   debug - set close timeout for client T9eCOR7gCe3pLNtiEZco
   debug - xhr-polling closed due to exceeded duration
GET /socket.io/1/xhr-polling/T9eCOR7gCe3pLNtiEZco?t=1344799800945 200 20002ms
   debug - clearing poll timeout
   debug - xhr-polling writing 8::
   debug - set close timeout for client yUEmr7drZfmWzWHdEZcp
   debug - xhr-polling closed due to exceeded duration

guille هل يمكن أن تقول لي لماذا هو الرجوع؟

ما المتصفح الذي تستخدمه؟

Chroms 21 لنظام التشغيل Mac OSX

أرى أيضًا نفس المشكلة على Chrome 21 / Windows 21.0.1180.79 م - هناك اتصال استقصاء JSONP (يبدو ناجحًا) مع اتصال WebSocket متزامن لا يتصل أبدًا - إنه دائمًا في حالة "معلق". يبدو الإصدار نفسه من Chrome على Mac جيدًا.

هذا لا يبدو جدار الحماية أو مكافحة الفيروسات ، كل الاختبارات تمر على websocketstest.org و websocket.org/echo.html.

أنا أستخدم socket.io 0.9 ، ولكن يبدو أيضًا أنه موجود في الإصدار الأخير أيضًا.

guille يبدو من السهل جدًا إعادة إنتاج هذه المشكلة أيضًا. لقد زرت للتو موقعًا يستخدم نقل WebSocket الخاص بـ socket.io:

http://beta.blaggart.com

لاحظ أنه في Chrome 21 على Windows على الأقل ، تكون حالة اتصال WS دائمًا "معلقة".

جرب مع socket.io master؟

فقط حاولت سيد ولدي نفس المشكلة. أعتقد أن هذه المشكلة قد تكون أيضًا خدعة لـ # 998.

أيضًا ، لما يستحقه ، فإن الحل الموضح في # 998 نجح في الحصول على اتصال لإنشاء - تعطيل مآخذ الويب واستخدام استقصاء xhr و jsonp فقط.

هل هذا في الواقع علة الكروم؟

عند إجراء اختبار على www.websocket.org/echo.html

الشيء المضحك هو أنه عندما أستخدم "مقبس الويب الآمن (TLS)" على نفس الموقع ، فإن مقبس الويب يعمل.

نفس السلوك تمامًا لكل من Chrome و Firefox .. غريب جدًا ..

الخادم:

socket.on('loginout',function(){
    socket.emit('loginout',{uname:socket.name});
});

socket.on ("تسجيل الدخول" ، الوظيفة (البيانات) {
socket.emit ('l_msg'، {uname: data.uname، Score: data.score، type: true})؛
}) ؛

مطبعة:
معلومات: أذن المصافحة 11012331592122282453
التصحيح: طلب الإعداد GET /socket.io/1/xhr-polling/11012331592122282453؟t=1353485202761
التصحيح: تحديد مهلة الاستطلاع
التصحيح: أذن العميل لـ
التصحيح: مسح مهلة الاستطلاع
التصحيح: كتابة الاستقصاء xhr 1 ::
تصحيح الأخطاء: تعيين مهلة الإغلاق للعميل 11012331592122282453
تصحيح: حزمة البيانات المستلمة لاستقصاء xhr 20 5 ::: {"name": "count"} 22 5 ::: {"name": "history"} 23 5 ::: {"name ":"قائمة المستخدم"}
التصحيح: طلب الإعداد GET /socket.io/1/xhr-polling/11012331592122282453؟t=1353485202792
التصحيح: تحديد مهلة الاستطلاع
التصحيح: تجاهل النقل
التصحيح: مسح مهلة الإغلاق للعميل 11012331592122282453
التصحيح: مسح مهلة الاستطلاع
التصحيح: كتابة الاستقصاء xhr 8 ::
تصحيح الأخطاء: تعيين مهلة الإغلاق للعميل 1896586469607627233
التصحيح: تم إغلاق الاستقصاء xhr بسبب تجاوز المدة
تصحيح: xhr-polling تلقي حزمة البيانات 5 ::: {"name": "login"، "args": [{"uname": "gjjn"، "pwd": "3f01728152a0225ff9806c401ffdbe77"}]}
التصحيح: مسح مهلة الاستطلاع
التصحيح: كتابة الاستقصاء xhr 5 ::: {"الاسم": "l_msg"، "args": [{"uname": "gjjn"، "type": true، "head": " http: //42.121. 14.234 / undefined "}]}
تصحيح الأخطاء: تعيين مهلة الإغلاق للعميل 11012331592122282453
التصحيح: حزمة البيانات المستلمة لاستقصاء xhr 5 ::: {"name": "loginout"}
التصحيح: كتابة websocket 5 ::: {"الاسم": "l_msg"، "args": [{"uname": "gregergre"، "type": true، "head": " http://42.121.14.234/ غير محدد "}]}
التصحيح: إصدار نبضات قلب للعميل 5207531891749391108
التصحيح: كتابة websocket 2 ::
تصحيح الأخطاء: تعيين مهلة ضربات القلب للعميل 5207531891749391108
التصحيح: حصلت على حزمة نبضات
التصحيح: مهلة مسح نبضات القلب للعميل 5207531891749391108
التصحيح: ضبط الفاصل الزمني لنبضات القلب للعميل 5207531891749391108
تصحيح: websocket كتابة 5 ::: {"الاسم": "تسجيل الدخول" ، "args": [{}]}

تلقى الاستقصاء xhr حزمة البيانات 5 ::: {"name": "loginout"}.
لكن ليس نتيجة.

نفس الشيء هنا. لقد استخدمت نفس الرمز ولكنه يعمل على Chrome MacOS ولكن ليس على Chrome Windows

كيفية التكاثر - https://gist.github.com/jonnsl/5021596

+1 ، الرجاء إصلاح هذه المشكلة ..LearnBoost

حتى أنني أرى هذا ، من جانبي أرى أنه اتصال Websocket وطلب XHR متكرر تم إرساله إلى خادم SOCKET.io

يبدو أن اتصال websocket أدى إلى النجاح ولكني أرى طلب XHR

Request URL:ws://localhost:5000/socket.io/?EIO=2&transport=websocket&sid=XcMblHoZ0x97QRn_AAAE
Request Method:GET
Status Code:101 Switching Protocols
Request Headers CAUTION: Provisional headers are shown.
Cache-Control:no-cache
Connection:Upgrade
Cookie:io=XcMblHoZ0x97QRn_AAAE
Host:localhost:5000
Origin:http://localhost:3000
Pragma:no-cache
Sec-WebSocket-Extensions:permessage-deflate; client_max_window_bits, x-webkit-deflate-frame
Sec-WebSocket-Key:EZixwYoUHpFFpgrEOqiS+w==
Sec-WebSocket-Version:13
Upgrade:websocket
User-Agent:Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/35.0.1916.153 Safari/537.36
Query String Parametersview sourceview URL encoded
EIO:2
transport:websocket
sid:XcMblHoZ0x97QRn_AAAE
Response Headers
Connection:Upgrade
Sec-WebSocket-Accept:WHsiBZoW9stmULt+YX8wmNK1wx8=
Upgrade:websocket

هنا كيف تبدو إطارات websocket
https://www.dropbox.com/s/v6szg9hka53erbc/Screenshot٪202014-07-09٪2011.12.33.png

وطلب الاقتراع الطويل

https://www.dropbox.com/s/pf7d56tp85864bg/Screenshot٪202014-07-09٪2011.15.47.png

أنا أعمل على Google Chrome 35.0.1916.153

وإصدار إصدار المقبس هو [email protected]

لدي نفس المشكلة. أي تحديثات؟ باستخدام SocketIO 1.0.6

الطلب الأول دائمًا هو XHR ، ثم نقوم _ بالترقية_ إلى WebSocket (إذا استطعنا). تم إحباط الاقتراع اللاحق (قد تكون هناك دورة اقتراع إضافية في بعض الحالات ، ولكن ليس أكثر من 1)

guille بالنسبة لما

مرحبا،

ما الحل لحل هذه المشكلة؟

rohittailor : أختبر هذا على العميل:

    <script src="/socket.io/socket.io.js"></script>
    <script>
        var socket = io.connect({transports: ['websocket']});
    </script>

وحتى الآن جيد جدًا. إنه يتجنب تمامًا اتصال XHR.

أدى هذا إلى حل مشكلتي أيضًا ، كان Websocket يعمل بشكل جيد ولكن كان هناك أيضًا استطلاع XHR قذر. شكرا gonzalodiaz

أود حقًا أن أرى سيناريو يتم فيه الترقية إلى WS بنجاح ولكن دورات استطلاع XHR تستمر إلى أجل غير مسمى في Web Inspector!

(عرض توضيحي ، فيديو ، صورة gif متحركة ، أي شيء يعمل)

يمكنني منحك وصولاً تجريبيًا إلى موقع الويب الخاص بي ، المستضاف على MS Azure cloud غدًا. هل يمكنك تزويدنا بعنوان URL للاختبار ومزيد من التفاصيل حول كيفية استضافة socket.io؟

guille ماذا عن هذا

هنا كيف تبدو إطارات websocket
https://www.dropbox.com/s/v6szg9hka53erbc/Screenshot٪202014-07-09٪2011.12.33.png

وطلب الاقتراع الطويل

https://www.dropbox.com/s/pf7d56tp85864bg/Screenshot٪202014-07-09٪2011.15.47.png

هل يستمر هؤلاء في الذهاب إلى أجل غير مسمى؟ هل توجد إطارات مكررة في ملف
استجابات؟ هل يمكنك نشر سجل الخادم المقابل باستخدام DEBUG = * و
سجل المتصفح باستخدام localStorage.debug='*' عندما يحدث هذا الموقف؟

-
غييرمو راوخ -rauchg https://twitter.com/rauchg

يوم الثلاثاء ، 14 أكتوبر 2014 الساعة 10:59 مساءً ، Viren Negi [email protected]
كتب:

guille https://github.com/guille ماذا عن هذا

هنا كيف تبدو إطارات websocket

https://www.dropbox.com/s/v6szg9hka53erbc/Screenshot٪202014-07-09٪2011.12.33.png

وطلب الاقتراع الطويل

https://www.dropbox.com/s/pf7d56tp85864bg/Screenshot٪202014-07-09٪2011.15.47.png

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
https://github.com/Automattic/socket.io/issues/991#issuecomment -59161273
.

guille أرى استجابة xhr تتكرر إلى أجل غير مسمى لست متأكدًا من تكرار الإطار ، دعني أرى ما إذا كان بإمكاني تقديم كل ما تحتاجه

لست متأكدًا من مدى مساعدتي ، لكنني ألاحظ أنه لا يمكنني الاتصال بمقبس الويب إلا إذا كان آمنًا. هل كانت هناك بعض التغييرات الأمنية الأخيرة التي تتطلب رأسًا (مثل CORS) للسماح باتصالات WebSocket غير الآمنة؟

عملت WebSockets منذ شهر مضى بالنسبة لي ، والآن تعمل فقط مع اتصالات wss: //.
Chrome 38.0.2125.104 - Windows 8.1.1

تحرير: قد تكون هذه النتائج في الواقع مشكلة في http://www.websocket.org/echo.html
لم أتمكن من الاختبار في مكان آخر

يعتمد نجاح اتصال WS حقًا على إمكانيات الشبكة / الخادم. يضمن SSL أنه لا شيء يمكنه كسرها قبل فك تشفير البيانات (لا يزال بإمكان الوكلاء / موازنات التحميل اللاحقة كسرها).

لقد لاحظت أنه كان في الواقع خطأ في الكود ، ولم يقم حتى باستقصاء اتصال WS ، وقمت بإجراء تغيير ثم نجح. إذا كنت أتذكر ، فسوف ألقي نظرة على المصدر المعدل الليلة.

ولكن إذا كان يعمل مع أي شخص آخر ، فقد يكون هناك خطأ آخر في الإعداد الخاص بي ، لكنه لم يكن يحاول الاتصال لأنه اعتقد أن WS لم يكن متاحًا دون محاولة ، وتغيير a && إلى || تم التصليح.

أود أن أسمع المزيد!

لا تزال مشكلة (صغيرة) ، يقوم العميل دائمًا بتقديم طلبات الاستطلاع بدلاً من تجربة وسائل نقل أخرى. لا بد لي من التحديد

{transports: ['websocket']}

لجعلها تعمل ، ولكن يجب على العميل تجربة جميع وسائل النقل للعثور على الأفضل ، أليس كذلك؟

كانت هذه المشكلة هي السبب في أنني بدأت مرة أخرى في 2012/13 للعمل على حزمة مقبس ويب "نقية".

هل تم حل هذه المشكلة؟ أرى شيئًا مشابهًا ، لكن قبل أن أبدأ في البحث العميق أردت إجراء بحث سريع ... تعليق؟

لقد تغير الرمز قليلاً منذ أن علّقت آخر مرة على هذه المسألة. من غير المحتمل أن يكون نفس الخطأ. لا يمكنني العثور على الخط الذي كنت أشتبه في أنه يسبب المشكلة في المرة الأخيرة. هذا لا يعني أنه تم إصلاحه.

رمز socket.io الخاص بي محظور حاليًا بواسطة bug engine.io-client لذا لم أستخدم s.io لبضعة أشهر حتى الآن ، لذا لا يمكنني الجزم بما إذا كانت هذه مشكلة ما زالت.

nevercast تعليقك حول عمل wss لكن لم يكن الأمر صحيحًا تمامًا في حالتي. نشكرك على الإشارة إلى أنني كنت أبحث عن هذه المشكلة لأكثر من أسبوع. وجدت أنه بطريقة ما تم حظر أي اتصال ws على شبكتي ولكن wss كان يعمل بشكل جيد.

موقع الويب هذا رائع: http://websocketstest.com/ فهو يخبرك بالمنافذ التي يمكنها تشغيل مآخذ ويب على أي شبكة معينة. نوصي بفحص هذا قبل الانخراط بشكل كبير في تصحيح أخطاء مقبس الويب.

لدي مشكلة مع socket io ولكن لست متأكدًا من الخطأ.

توضح الصورة أعلاه أنها تعمل بشكل جيد محليًا ولكن تم التقاط الصورة أدناه أثناء المحاولة في بيئة AWS.

لدي مشكلة مع socket io ولكن لست متأكدًا من الخطأ.

توضح الصورة أعلاه أنها تعمل بشكل جيد محليًا ولكن تم التقاط الصورة أدناه أثناء المحاولة في بيئة AWS.

تواجه نفس المشكلة