Socket.io: استمرار "إغلاق النقل" على العميل
لقد قمت بإعداد socket.io v.1.4.5 w express ولم أتمكن من تتبع سبب قطع الاتصال غير المبرر على العملاء. السبب الذي قدمه حدث قطع الاتصال على العميل هو "إغلاق النقل". يحدث ذلك باستمرار مع بعض العملاء.
هل هناك أي تفسير لقيام العميل بقطع اتصال "إغلاق النقل" على ما يبدو أنه فترة زمنية محددة؟ يعيد العميل الاتصال على ما يرام ولكنه يسبب إزعاجًا شديدًا لأنه يحدث كثيرًا.
لقد جربت العديد من الإعدادات ، مثل تغيير pingInterval و pingTimeout والمنفذ لمآخذ الويب (أنا الآن أستخدم المنفذ 80). ولكن بغض النظر عما يبدو أنني أفعله ، فإن المشكلة لا تختفي أبدًا.
ForgeableSum
ال 48 كومينتر
تم التحديث إلى socket.io v2.0.3. وما زلت تواجه المشكلة. يبدو أنه يحدث فقط على أحد أجهزة الكمبيوتر الخاصة بي. لقد قمت أيضًا بتعطيل جدار حماية Windows ، لكن المشكلة لا تزال تحدث.
ForgeableSum
في ٤ أغسطس ٢٠١٧
تم التبديل إلى ws (https://github.com/websockets/ws) والتي تضمنت عمليات إعادة كتابة ضخمة ، لكنني الآن أستخدم كائن متصفح websocket الأصلي على جانب العميل ويعمل كل شيء بشكل مثالي. لم يعد لدي مشكلة. socket.io طويل جدا!
ForgeableSum
في ٨ أغسطس ٢٠١٧
تعاني من نفس الشيء. أنا حقًا لا أرغب في إعادة الكتابة. أي شخص لديه أي نجاح مع هذه القضية؟
matthewtmoran
في ١٠ أغسطس ٢٠١٧
لقد تعبت حقا من هذه المشكلة.
أعتقد أنكم يجب أن تتحققوا من إصدار "socket.io" مع "socket.io-client".
إذا كان إصدار الخادم / العميل غير متطابق ، فإن الاتصال كان غير مستقر للغاية.
أوصي ببساطة باستخدام CDN كما هو موضح أدناه للعميل.
@ref: https://cdnjs.com/libraries/socket.io
I hope it helps.
althjs
في ١٣ سبتمبر ٢٠١٧
الحروب الإقطاعية ديف ؟؟ إنه رائع.
أنا أيضا لدي هذه المشكلة أيضا.
تم قطع اتصال المستخدم بشكل عشوائي بسبب إغلاق النقل وانتهاء مهلة اختبار الاتصال.
حاولت أيضًا تغيير العديد من الخيارات (الفاصل الزمني ping ، مهلة ping ، النقل ...) لكنها لا تعمل.
راجعت إصدار الخادم و socket.io الخاص بالعميل
كثير من الناس يعانون من هذه المشكلة ولكن لا أجد أي حل.
dnwldbs84
في ٥ مارس ٢٠١٨
أي أخبار عن هذه المشكلة ، لأن لدي نفس المشكلة بالضبط!
talas9
في ٢٧ أبريل ٢٠١٨
لدي نفس المشكلة أيضًا عند النشر إلى k8ns ولكن عندما أقوم بالتشغيل محليًا ، فإنها تعمل بشكل جيد.
muhammadnasr
في ٣ مايو ٢٠١٨
أنا أيضًا أعاني من هذا ...
htamop
في ٤ مايو ٢٠١٨
@ talas9muhammadnasrhtamop الأسئلة الشائعة لتكون قادرة على التصحيح / إعادة إنشاء المشكلة:
- ما هو إصدار العميل / الخادم الذي تستخدمه؟
- أي متصفح؟
- هل هو قابل للتكرار مع الكمان ؟
شكرا!
darrachequesne
في ٤ مايو ٢٠١٨
لقد جربتها مع العميل والخادم 2.1.0 و 2.0.4. على الكروم وسفاري (الأحدث).
عندما أقوم بالتشغيل محليًا ، فإنه يعمل بشكل جيد (يمكن توصيله لأكثر من ساعة دون قطع الاتصال) ، ولكن عندما أقوم بالنشر إلى K8ns خلف أداة تحميل التحميل ، تحدث هذه المشكلة ...
يتم إغلاق اتصال FYI تمامًا بعد 25 ثانية في كل مرة ، انظر لقطة الشاشة
muhammadnasr
في ٦ مايو ٢٠١٨
@ talas9htamop @ dnwldbs84 الذي تستخدمه موازن تحميل؟
muhammadnasr
في ٧ مايو ٢٠١٨
darrachequesne ما هو موازن التحميل الذي توصي باستخدامه مع socket.io؟
muhammadnasr
في ٧ مايو ٢٠١٨
تضمين التغريدة
لقد استخدمت 2.1.0 Sever و 1.0.0 Client (android)
أحتاج إلى إبقاء الاتصال مستقرًا لمدة 8 إلى 9 ساعات ولكنه قطع الاتصال بشكل غير متوقع.
لقد غيرت كلا الإصدارين إلى 1.7.4 و 0.8.3؟ حسب آخر حل آخر. سأحاول اختبار ما إذا كان يعمل بشكل جيد غدا
htamop
في ٨ مايو ٢٠١٨
لم أستخدم موازن التحميل. استخدم كل من العميل والخادم الإصدار 2.0.3 من Socket.io (لا أتذكر كل الإصدارات التي استخدمتها). لا أعرف أي متصفح يسبب المشكلة ، ومع ذلك ، فقد استخدم معظم المستخدمين Chrome. في حالتي ، كان قطع الاتصال عشوائيًا لذا لا يمكنه التكاثر.
وتغيرت إلى ws. لست متأكدًا مما إذا كان قد تم حل المشكلة.
dnwldbs84
في ٨ مايو ٢٠١٨
muhammadnasrdarrachequesne @ dnwldbs84
أعتقد أنه تم حلها في حالتي.
أستخدم 0.8.3 socket.io-client في خدمة android الأمامية (api 26) وإصدار 1.3.5 في خادم nodejs.
ومع ذلك ، قد لا تكون المشكلة في الإصدار.
لقد غيرت pingInterval في الخادم إلى 10 مللي ثانية ويبدو أنه يعمل بشكل صحيح (لم يحدث انتهاء مهلة اختبار الاتصال والنقل)
var io = يتطلب ('socket.io') (http، {pingInterval: 10، pingTimeout: 4000}) ؛
htamop
في ٨ مايو ٢٠١٨
10 ميللي ثانية ضيقة للغاية ، وبهذه الطريقة ستغرق الشبكة.
muhammadnasr
في ١٣ مايو ٢٠١٨
يتم تضييق 10 مللي ثانية ، وبهذه الطريقة ستغرق الشبكة.
صيح!
muhammadnasr يجب أن يعمل أي موازن تحميل. يرجى الاطلاع على الأمثلة التالية:
- https://github.com/socketio/socket.io/tree/master/examples/cluster-haproxy
- https://github.com/socketio/socket.io/tree/master/examples/cluster-nginx
- https://github.com/socketio/socket.io/tree/master/examples/cluster-httpd
على الرغم من ذلك ، تكون الجلسة الثابتة مطلوبة ، إذا قمت بتمكين الاستقصاء (وهو الافتراضي).
darrachequesne
في ١٥ مايو ٢٠١٨
darrachequesne لدي نفس المشكلة ، بعد 8 ~ 9 ساعات
أنا استخدم:
Chrome: 61.0.3163.100
Electron: 2.0.2
Socket.io: 2.1.1
DannyFeliz
في ٦ يونيو ٢٠١٨
واجهت نفس المشكلة ، وتمكنت من إصلاحها باستخدام CDN من هذا التعليق https://github.com/socketio/socket.io/issues/3025#issuecomment -329024833 وتعيين المهلة والفاصل الزمني كما يلي:
io.set('heartbeat timeout', 60000);
io.set('heartbeat interval', 25000);
borisgern
في ٢ يوليو ٢٠١٨
مهلا،
لدينا نفس المشكلة مع socket.io عندما يعمل تحت Kubernetes و NGINX Ingress Controller.
عندما يتم إعادة تحميل تكوين nginx ، فإنه يعيد إنشاء العملية ويتم إسقاط جميع الاتصالات الموجودة ، مما تسبب في transport close ، وأي عمليات نشر أخرى تستخدم وحدة التحكم في الدخول قد تتسبب في إعادة تحميل التكوين
odeddoek
في ٨ يوليو ٢٠١٨
بادئ ذي بدء ، شكرًا حقًا على هذا المشروع الرائع.
نفس المشكلة هنا ، ربما سأحضر لك شيئًا جديدًا.
لدي خادم ws وعميل ws على عقدة js.
يتم استخدام عميل ws هذا من تطبيق node js حيث تكون خدمة (خدمة صغيرة).
يتواصل عملاء ws الآخرون من متصفحات الويب (من تطبيقات العميل) عبر خادم ws مع خدمة node js هذه.
كل شيء يعمل كما هو متوقع.
في اختبارات الإجهاد الآن (10 عملاء يسألون البيانات بشكل مكثف) ، في نهاية الاختبارات ، عندما تم الانتهاء من جميع الوظائف والمعاملات ، يتم إغلاق اتصال الخدمة مع الخطأ "إغلاق النقل". هذا لا يحدث دائما
هذا هو تكوين الخادم:
pingTimeout: 15000 ،
بينغ الفاصل الزمني: 20000 ،
يبدو أنه أثناء الحمل الثقيل فقدت بعض أدوات ping ...؟ أو لا أعرف.
هل هذا شيء يجب أن أتوقعه؟
أيضًا ، مع التكوين الافتراضي pingTimeout: 2000 ، كنت أتلقى هذا الخطأ في منتصف اختبار التحمل. كان هذا أيضًا غير متوقع تمامًا ، ولكن دعنا نقول أن الخادم كان محملاً بشكل زائد ولا يمكنه الاستجابة خلال ثانيتين (!) وقد نحصل على هذا الخطأ. ولكن الآن مع pingTimeout: 15000 يحدث ما يقرب من 50٪ وفقط بعد نهاية الاختبارات.
حسنًا ، أعتقد أن الخدمات الصغيرة يجب أن تتوقع هذا النوع من الأخطاء ، حتى لو كانت تعمل على نفس الشبكة المحلية ، لكن السؤال هو لماذا يحدث هذا؟
حاولت إنشاء إعداد صغير لإعادة إنتاج هذه المشكلة ولكن لم أتمكن من القيام بذلك.
كيف يتم تفعيل السجلات؟ التصحيح = socket.io * لا يعمل. على الرغم من تعيين المتغير ، إلا أنني لا أحصل على أي إخراج.
dennisat
في ١٠ يوليو ٢٠١٨
أعتقد بشدة أن هذا مرتبط بالرقم 2924.
تحدث عمليات إعادة الاتصال على العميل بسبب اختناق بعض المتصفحات (Safari و chrome) لأجهزة ضبط الوقت لعلامات التبويب غير النشطة لتوفير البطارية.
ينتج عن هذا تأخير رسائل نبضات القلب من العميل والخادم لإغلاق الاتصال بسبب pingTimeout.
تعمل زيادة pingTimeout إلى حد ما ولكني ما زلت أحصل على إعادة الاتصال في بيئة الإنتاج.
tilsander
في ٤ أغسطس ٢٠١٨
لدي نفس المشكلة أيضًا عند النشر إلى k8ns ولكن عندما أقوم بالتشغيل محليًا ، فإنها تعمل بشكل جيد.
muhammadnasr حيث يمكنك تجاوز مشكلة النشر على K8s؟ أنا أواجه مشاكل مماثلة.
bheema01
في ١٢ أكتوبر ٢٠١٨
@ bheema01 فقط تأكد من تمكين جلسة stickysession على الوكيل / loadbalancer الخاص بك ويجب أن تعمل
muhammadnasr
في ١٤ أكتوبر ٢٠١٨
حصلت على نفس الخطأ
Faizanq
في ٢٠ ديسمبر ٢٠١٨
نفس المشكلة ..... يقوم العملاء بالاتصال وقطع الاتصال بشكل متكرر عندما تكون نقطة نهاية مأخذ توصيل جانب الخادم خلف موازن التحميل. حتى بعد تكوين الجلسات اللاصقة ، لا تزال المشكلة قائمة. muhammadnasr هل استطعت حل المشكلة.
varunSabnis
في ١٢ يناير ٢٠١٩
لقد رأيت هذا الخطأ ، عندما تم حظر الخيط بشكل متكرر لأكثر من 200 مللي ثانية.
إذا حدث هذا بشكل متكرر ، فهذا سيء بالنسبة لـ socket.io _ وللتطبيق الخاص بك أيضًا_.
مهلة socket.io للتحقق من نبضات الاتصال.
إذا تم تجاوز هذه المهلة ، فسيتم إغلاق الاتصال ونحصل على هذا الخطأ.
dennisat
في ١٢ يناير ٢٠١٩
varunSabnis بعد تثبيت الجلسة اللاصقة ، كل شيء
muhammadnasr
في ١٣ يناير ٢٠١٩
dennisat حاولت التحقق من الوقت الذي استغرقه موكلي لتلقي حزمة بونغ. في كل مرة تجاوزت 200 مللي ثانية ، والتي تم اختبارها مع خادم مأخذ التوصيل في السحابة وخادم المقبس على مضيفي المحلي. لا يقوم الإعداد المحلي بفصل المقبس (كل شيء يعمل بشكل جيد) ، بينما في مقبس الإعداد السحابي يتصل باستمرار ويفصل. لذا ، لا أعتقد أن هذه هي المشكلة.
muhammadnasr حسنًا ، هذا رائع. لقد قمت بتمكينه بالفعل ولكن لا تزال تواجه بعض المشكلات.
varunSabnis
في ١٣ يناير ٢٠١٩
muhammadnasrdarrachequesne @ dnwldbs84
أعتقد أنه تم حلها في حالتي.
أستخدم 0.8.3 socket.io-client في خدمة android الأمامية (api 26) وإصدار 1.3.5 في خادم nodejs.
ومع ذلك ، قد لا تكون المشكلة في الإصدار.
لقد غيرت pingInterval في الخادم إلى 10 مللي ثانية ويبدو أنه يعمل بشكل صحيح (لم يحدث انتهاء مهلة اختبار الاتصال والنقل)
var io = يتطلب ('socket.io') (http، {pingInterval: 10، pingTimeout: 4000}) ؛
يعمل بطريقة سحرية ، شكرا !!!!!!!
EltonZhong
في ٣ فبراير ٢٠١٩
أجد أنني حصلت على "إغلاق النقل" كل فترة ping.
لقد تعبت حقا من هذه المشكلة.
أعتقد أنكم يجب أن تتحققوا من إصدار "socket.io" مع "socket.io-client".
إذا كان إصدار الخادم / العميل غير متطابق ، فإن الاتصال كان غير مستقر للغاية.أوصي ببساطة باستخدام CDN كما هو موضح أدناه للعميل.
@ref: https://cdnjs.com/libraries/socket.io
I hope it helps.
It works even more magically.
Seems that we can close this issue with your answer, haha
EltonZhong
في ١١ فبراير ٢٠١٩
أخيرًا ، اكتشفت أنه بسبب عدم تطابق إصدار العميل والخادم.
كل شيء يعمل بشكل جيد الآن عندما أجعل العميل والخادم يشتركان في نفس الإصدار من socket.io.
أعتقد أن منطق ping pong قد يختلف في إصدارات مختلفة من socket.io ، ولم يستقبل الخادم حدث ping من جانب العميل في فترة ping ، مما يعطي رسالة "إغلاق النقل".
EltonZhong
في ١١ فبراير ٢٠١٩
واجهت مشكلة فصل socket.io كل 30 ثانية بعد النشر إلى Google Cloud Platform (GCP). اتضح أنها مهلة http افتراضية يستخدمها Global Load Balancer. قالت وثائق برنامج "شركاء Google المعتمدون" أنه يجب عليك تغيير القيمة عند استخدام مآخذ الويب. تعليمات تغيير الإعداد هنا:
https://cloud.google.com/load-balancing/docs/backend-service#timeout -setting
CodeBishop
في ١٧ أبريل ٢٠١٩
لا تزال تواجه نفس المشكلة على "socket.io": "2.2.0" ،
"socket.io-client": "2.2.0"،
socket.io- العميل: إغلاق
FaizanZahid
في ٩ مايو ٢٠١٩
كذلك هنا. الخادم المحلي لا يواجه مشكلة. ولكن عند النشر خلف موازن التحميل ، يكون لها مهلة ping بشكل عشوائي. ربما 1 في 50 مرة. لقد حاولت استخدام إصدار CDN وإضافة الجلسة اللاصقة. المشكلة لا تزال قائمة.
alexyoux
في ٩ يوليو ٢٠١٩
لم ينجح شيء بالنسبة لي بخلاف بعض منطق إعادة الاتصال المخصص. إذا حصل العميل على حدث فتح مأخذ بمعرف مختلف عن السابق ، أرسل إلى الخادم حدث إعادة الاتصال بالمعرف القديم والجديد. ثم على الخادم فقط قم بتحديث معرف المقبس للاعب وأعد إرسال حالة اللعبة.
tmusaev
في ٤ أغسطس ٢٠١٩
tmusaev هل يمكنك نشر منطق إعادة الاتصال المخصص للعميل؟
Raagh
في ٨ أغسطس ٢٠١٩
لدي نفس المشكلة: "النقل قريب"
javaLuo
في ١٦ سبتمبر ٢٠١٩
لديك نفس المشكلة. أخيرًا أحلها. Nginx هو خادم الوكيل الخاص بي ، ولكن proxy_read_timeout للتكوين هو 60 ثانية ، فهذا يشير إلى أنه إذا لم يرسل العميل أو الخادم أي رسالة في 60 ثانية ، فسيتم قطع اتصال nginx ، لذلك يمكننا الحصول على transport close errorMsg.
الحل:
- زيادة
proxy_read_timeoutإلى 600s أو أكثر - باستخدام
setIntervalلإرسال بعض الرسائل في الواجهة الأمامية
ikitty
في ٣٠ سبتمبر ٢٠١٩
"react": "16.8.3",
"react-native": "^0.59.9",
"socket.io": "^2.2.0"
لقد استخدمت هذه المكتبة للدردشة والحصول على بعض الأحداث. إنه يعمل بشكل جيد في iOS ولكنه يخلق مشكلة في android. فقد الاتصال بالمقبس في أي وقت وأعد الاتصال. تعرض باستمرار نفس السلوك. وإعطاء هذا النقل خطأ إغلاق أو مهلة ping
jaydeep1992
في ١٨ أكتوبر ٢٠١٩
"react": "16.8.3", "react-native": "^0.59.9", "socket.io": "^2.2.0"لقد استخدمت هذه المكتبة للدردشة والحصول على بعض الأحداث. إنه يعمل بشكل جيد في iOS ولكنه يخلق مشكلة في android. فقد الاتصال بالمقبس في أي وقت وأعد الاتصال. تعرض باستمرار نفس السلوك. وإعطاء هذا النقل خطأ إغلاق أو مهلة ping
+1
BrijeshShiroya
في ١٨ أكتوبر ٢٠١٩
في حالتنا ، سبب المشكلة هو وكيل CDN. لقد قمت بحل هذه المشكلة عن طريق توصيل socket.io بالموقع الأصلي الذي لم يكن وكيل CDN.
picodoth
في ٩ نوفمبر ٢٠١٩
لقد عالجنا هذه المشكلة عن طريق تحديث وحدة تحكم إدخال nginx!
baflo
في ٢٩ نوفمبر ٢٠١٩
بعد قراءة العديد من التعليقات حول سلاسل الرسائل المختلفة ، جربت تقريبًا جميع الاقتراحات المقدمة للتخفيف من مشكلة
حاليًا ، يحتوي الخادم على التكوين التالي:
كما ذكر آخرون ، كلما قمت بتشغيل التطبيق محليًا ، لا يوجد انقطاع. لقد قرأت في خيط آخر أن الإصدار 3 من socket.io سيغير ping / pong لذا يتم إجراؤه للخادم وقد يساعد ذلك في إصلاح ذلك. هل لدى أي شخص أي أخبار أو تحديثات بخصوص هذه المسألة أو تاريخ محتمل لهذا الإصدار الجديد؟
Roderik-EY
في ٢٠ مايو ٢٠٢٠
لقد رأيت هذا الخطأ ، عندما تم حظر الخيط بشكل متكرر لأكثر من 200 مللي ثانية.
إذا حدث هذا بشكل متكرر ، فهذا سيء بالنسبة لـ socket.io _ وللتطبيق الخاص بك أيضًا_.
مهلة socket.io للتحقق من نبضات الاتصال.
إذا تم تجاوز هذه المهلة ، فسيتم إغلاق الاتصال ونحصل على هذا الخطأ.
بالنسبة لأولئك الذين يستخدمون Socket.IO لإرسال كميات كبيرة من البيانات ، تأكد من القيام بذلك بطريقة لا تمنع الخيط. لقد واجهت هذا اليوم باستخدام عميل مأخذ التوصيل على React Native وأنا أستخدمه لإرسال الملفات إلى الخادم. نظرًا للكيفية التي كتبنا بها إرسال الملفات عبر المقبس ، وهو في الأساس الكل في مرة واحدة بدلاً من التسلسل ، يختنق مؤشر ترابط JS ولا يمكنه إرسال pong مرة أخرى إلى الخادم ، وفصله ، مما يمنحنا هذا خطأ.
micahbule
في ١٦ يوليو ٢٠٢٠
لدي نفس المشكلة في تطبيقي ، لا أعتقد أنها مشكلة بينج بونج. أشك في أنه يجب أن يكون السبب من جانب الخادم الذي أغلق نقل المقبس.
robert-bitguild
في ٢١ أكتوبر ٢٠٢٠
نفس المشكلة. في متصفح Angular.
أدى هذا التكوين إلى تقليل عدد عمليات إعادة الاتصال بشكل كبير:
لقد استخدمت ForceJSONP بسبب الكور
ErnandesAJr
في ١١ ديسمبر ٢٠٢٠
بعد تحليلي ، وجدت المشكلة أدناه
مشكلة:
تعمل المآخذ بشكل جيد دون أي قطع اتصال محليًا ، ولكن عند نشرها في البيئات ، يتم قطع الاتصال مع "إغلاق النقل" كسبب لفصل الاتصال.
لقد رأيت هذه المشكلة فقط عند تشغيل تطبيق العقدة باستخدام خدمة مبتدئة أو خدمة systemmd ، إذا قمنا بتشغيل التطبيق مثل node app.js ، فأنا لا أرى هذه المشكلة.
إصلاح بسيط / حل بديل:
من جانب العميل ، عند فصل المقبس ، ينبعث من المقبس إضافة مستخدم (الزاوية 11)
self.socket.on('disconnect', (reason) => {
if(currentUser){
self.socket.emit('add user', currentUser);
}
})
مع السيناريو أعلاه ، يكون جميع المستخدمين دائمًا متصلين ومتصلين بالإنترنت ، وسيتم قطع اتصالهم عند تسجيل الخروج
ranupoju0126
في ٢٤ ديسمبر ٢٠٢٠
القضايا ذات الصلة
jloa
·
4تعليقات
thebinarypenguin
·
4تعليقات
adammw
·
4تعليقات
Elliot9
·
4تعليقات
karmac2015
·
3تعليقات
التعليق الأكثر فائدة
واجهت مشكلة فصل socket.io كل 30 ثانية بعد النشر إلى Google Cloud Platform (GCP). اتضح أنها مهلة http افتراضية يستخدمها Global Load Balancer. قالت وثائق برنامج "شركاء Google المعتمدون" أنه يجب عليك تغيير القيمة عند استخدام مآخذ الويب. تعليمات تغيير الإعداد هنا:
https://cloud.google.com/load-balancing/docs/backend-service#timeout -setting