كإختراق سريع يمكنك استخدام "فرض اتصال جديد": تكوين خاطئ

لقد لاحظت أيضًا هذا الخطأ في طلبنا.
كان التكاثر هو التالي. في FF مع اتصال websocket ، حدث خطأ ما. ثم تم إنشاء واحد تلو الآخر من أحداث إعادة الاتصال الثلاثة. بعد ذلك ، تم إنشاء 3 اتصالات جديدة ، وتلقى المتصفح 3 رسائل بدلاً من رسالة واحدة.

ربما بعض الأخطاء في منطق إعادة الاتصال؟ شيء يولد عدة عمليات إعادة اتصال بدلاً من واحدة.

لقد رأيت مشكلات في المتصفحات القديمة التي لا تدعم مآخذ الويب (على سبيل المثال ، FF 3.6) حيث تؤدي تهيئة socket.io في حدث dom ready ("$ ()" في jQuery) إلى اتصالات متعددة أثناء التهيئة في النافذة اللاحقة. الحدث لا. لقد وجدت أن هذه المشكلة بالذات قابلة للتكرار باستمرار. لست متأكدًا مما إذا كان هو نفس الشيء الذي تراه ولكن الأعراض تبدو متشابهة جدًا.

نفس المشكلة هنا كذلك. المشكلة هي أنه في حالة تعطل الخادم لأي سبب ثم إعادة تشغيله ، ينتج عن إعادة الاتصال استجابات n + 1 في كل مرة. لذلك إذا قلنا أن 3 أعطال في الخادم ، فلدينا 4 استجابات في كل خادم يصدر تحديث الصفحة يحل المشكلة. هل وجد أحد حلاً لهذا [حتى لو كان مؤقتًا؟]

قد لا يكون هذا حلاً دائمًا ، لكنني قمت بإعادة ترتيب الكود الخاص بي بحيث يتم ربط كل حدث بشكل مستقل ويبدو أن مشكلة الازدواجية قد تم حلها عند إعادة الاتصال التلقائي

me.socket.on('connect', function () {
});

me.socket.on('message', function(data) {

});

me.socket.on('disconnect', function() {

});

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

باختصار ، منطق إعادة الاتصال هش للغاية. يعتمد ذلك على العديد من أجهزة ضبط الوقت التي يمكن أن تعمل بالتوازي وتؤدي إلى عدة عمليات إعادة توصيل. هذا السطر https://github.com/LearnBoost/socket.io-client/blob/master/lib/socket.js#L511 هو السبب الرئيسي لهذا الخطأ.

الآن استنساخ كامل:

1. تواصل مع العميل إلى الخادم.
2. ضع رمزًا بطيئًا في خادمك (يجب علينا تعليق node.js mainloop لمدة 4-8 ثوانٍ) عبر عاملي:
   وظيفة فيبو (ن) {
   إذا (n <2) إرجاع 1 ؛
   عودة فيبو (ن -2) + فيبو (ن -1) ؛
   }
   ضعه في قسم المصادقة. يجب استدعاء هذا عند المصافحة:
   io.set ('authorization'، function (data، Accept) {
   console.info ("Fibo ::" + fibo (41)) ؛
   يجب أن تجرب في وحدة تحكم العقدة الخاصة بك ، للعثور على fibo (N) ، والذي
   سيحجب الحلقة الرئيسية لمدة 4-8 ثوان.
3. الآن ، يجب عليك إعادة تشغيل الخادم بسرعة.
   سيتم تطبيق رمز بطيء للاتصال.
   يجب إخطار العميل بأنه لم يتم مصافحة باليد.
   والآن تحاول إعادة الاتصال.
   في وحدة التحكم ، سترى عدة محاولات لإعادة الاتصال (إذا قمت بتسجيل الدخول إلى "إعادة الاتصال / إعادة الاتصال").
   بعد اختراق تباطؤنا سوف يتكرر إلى الأبد.

في الحياة الواقعية ، تم استنساخ هذا من خلال تباطؤ رد الخادم لعدة ثوان على الأقل.
يمكن أن يحدث هذا عندما يكون node.js تحت حمل ثقيل ويستجيب مع بعض التأخير.
أو قد يؤدي بعض تباطؤ الشبكة أيضًا إلى مثل هذا السلوك.
يمكن أيضًا إعادة إنتاجه بعد إعادة تشغيل الخادم.

هذا الخط (socket.js، 511):
self.reconnectionTimer = setTimeout (ربما إعادة الاتصال ، self.reconnectionDelay) ؛

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

لقد أجريت إصلاحًا ، لكن لم يتم اختباره ويبدو أنه غير قوي جدًا. المشكلة الرئيسية - كيفية معرفة سبب تشغيل رد الاتصال / المؤقت بشكل متزامن مع وظيفة ربما إعادة الاتصال.
هذا السطر: https://github.com/LearnBoost/socket.io-client/blob/master/lib/socket.js#L490 يمكن أن يؤدي أيضًا إلى اتصال مكرر.

يمكن أن يكون تفكير عميل Socket.io أكثر بساطة ، إذا كان سيتم إعادة تشكيله لاستخدام بعض أجهزة State. تنتشر الحالة حاليًا عبر أعلام مختلفة (متصلة ، متصلة ، إعادة الاتصال ، إلخ). وفي العديد من الوظائف رأيت حراسًا مثل "if (! self.reconnecting)" والعديد من الوظائف الأخرى.
يمكن لآلة الدولة تبسيط هذا المنطق للحصول على مجموعة من الحالات والأحداث. ويمكن استخدام أجهزة ضبط الوقت فقط لإطلاق الحدث. إذا وصل هذا الحدث إلى حالة غير صحيحة ، فيمكن لجهاز الحالة تجاهل هذا الحدث وعدم إزعاج نفسه.

لم أجد STM جيدة لـ JS ، ولكن هذا واحد من Ruby يمكن نقله بسهولة إلى JS: https://github.com/geekq/workflow

بالتأكيد +1 على إصلاح هذه المشكلة. لقد كنت أعمل على محاولة إيجاد حل لهذه المشكلة دون تعديل socket.io أو socket.io-client مباشرة ، لكن للأسف الطريقة الوحيدة التي توصلت إليها بشكل موثوق هي تعطيل إعادة الاتصال فقط. وهو بالتأكيد ليس حلاً جيدًا ، خاصة مع الاستخدام المتزايد للأجهزة المحمولة ، تعد إعادة الاتصال مطلبًا كبيرًا.

هل لدى أي شخص أي فكرة عن كيفية إدراج هذا في قائمة أولويات المطورين؟

آه. يبدو أنه تم تعيين هذه المشكلة إلى 3rd-Eden من الإصدار: https://github.com/LearnBoost/socket.io/issues/430

لقد أجريت إصلاحًا لأحد العملاء وأرسلت طلب سحب. إنه يعمل بشكل جيد في 0.8.4 ويمكن أن يعمل بشكل جيد في الإصدارات الأخرى. ولكنه يتطلب تعطيل القدرة في المصادر على استخدام AJAX (أو CORS) للمصافحة. انظر هذا: https://github.com/LearnBoost/socket.io-client/pull/342 للحصول على التفاصيل.

آسف لإحياء مثل هذه القضية القديمة. أنا أستخدم أحدث إصدار من socket.io (أو على الأقل ، قمت بتثبيت npm socket.io). لا تزال هذه المشكلة تحدث بالنسبة لي ، فأنا جديد نسبيًا على socket.io و node.js ككل. لقد واجهت أيضًا مشكلات في بعض الأحيان حيث يكون الاتصال الأول (من الاثنين اللذين حدثا في أي وقت واحد فقط) به خطأ قراءة. إذا كنت محقًا في قول cris ، فإن الإصلاح الخاص بك كان ملتزمًا ، لذا لا ينبغي أن يحدث بعد الآن ولكنه لا يزال يحدث إلا إذا فاتني عامل مهم؟

تعديل -

يبدو أن cris forked socket.io وأجرى إصلاحًا على ذلك ولم يكن الإصلاح ملتزمًا بمقبس socket.io الأصلي؟

JTallis لدي نفس المشكلة مثل gdiz وكان اقتراحه جيدًا. إذا كانت مشكلتك متشابهة ، أقترح عليك تجربتها وإعلامنا بكيفية عملها.

أواجه هذه المشكلة أيضًا مع 0.9.16 والتي أعتقد أنها أحدث إصدار. كيف يعمل gdiz على منع حدوث ذلك؟ لم أفهمها تمامًا.

omg ... أقضي عدة ساعات لمعرفة الخطأ في تطبيقي ، ولماذا تتكرر الرسائل بين الخادم والعميل بعد انقطاع الاتصال وتجديده ...

باستخدام 0.9.16 يمكنني تأكيد هذه المشكلة

يمكنني الحصول على حدث اتصال مزدوج حسب الرغبة مع رمز العميل والخادم التاليين في نفس ملف node.js:

"use strict";
var server = require('socket.io');
var client = require('socket.io-client');

setTimeout(function () {
    var io = server.listen(8888);

    io.of('/chat').on('connection', function (socket) {
        console.log('Server: /chat connection');
    });

    io.sockets.on('connection', function (socket) {
        console.log('Server: connection');
    });
}, 2000);

var socketAddress = 'http://localhost:8888/chat';
var socket = client.connect(socketAddress);

socket.on('connect', function () {
    console.log("Client: connect");
});

socket.on('error', function () {
    console.log("Client: error");
    socket.socket.reconnect();
});

زوجان من الأشياء الغريبة:

1) إذا قمت بتغيير الاتصال ذي مساحة الاسم إلى اتصال عادي عن طريق إزالة "/ chat" من عنوان url ، فسيكون هناك حدث اتصال واحد فقط.

2) إذا قمت بتشغيل الخادم على الفور ، فقم بتغيير وقت setInterval إلى الصفر ، فلا يوجد خطأ اتصال أولي وحدث اتصال واحد فقط.

أي عمل حول أو إصلاحات لهذا؟

وجود نفس المشكلة. إذا تمت إعادة تشغيل خادم socket.io بشكل غير متوقع ، يقوم العميل بإعادة الاتصال مرتين بحيث تتم معالجة كل رسالة من قبل العميل مرتين. حقا عبث حساباتي على العميل.

لدي نفس المشكلة مع الإصدار 1.0.0-pre2. لديّ "400 طلب غير صالح" عندما أستعيد socket.io.

سوف ننظر في هذا اليوم!

سوف ننظر في هذا اليوم!

لا تتردد إذا كنت بحاجة إلى مزيد من التفاصيل أو السجلات أو الشاشات! ليس كل مرة.

في client socket.io.js على 1.0.6 على السطر 2755:

Request.prototype.create = وظيفة (isBinary ، supportBinary) {
var xhr = this.xhr = XMLHttpRequest جديد ({agent: this.agent، xdomain: this.xd}) ؛
...
}

أعتقد أنها فكرة جيدة أن تحدد:
xhr.timeout = مثيل Manager._timeout - 10 مللي ثانية
بهذه الطريقة تمنع إنشاء عدة مقابس للعميل من جانب العميل.
على جانب الخادم ، ستنهي مآخذ توصيل ضربات القلب.

يحتوي المثال الأساسي socket.io "Getting Started" (http://socket.io/get-started/chat/) على مشكلة اتصال مقبس مزدوج.

ينتج عن أحد الأمور التالية (بترتيب الاحتمالية المتزايد) اتصال مقبس مزدوج من اتصال علامة تبويب متصفح واحدة:
أ) عند الاتصال بالمضيف المحلي: 3000 ، من علامة تبويب المتصفح الأولى نفسها
ب) عند الاتصال بالمضيف المحلي: 3000 ، من علامة تبويب المتصفح الثانية
ج) إبقاء وحدة تحكم المتصفح مفتوحة ، قبل الاتصال بـ (localhost: 3000)

ملاحظات إضافية:

 io.on('connection', function(socket){
    console.log('a user connected: ' + socket.id);
    socket.on('disconnect', function(){
       console.log('a user disconnected');
       console.log(socket.nickname + ' has disconnected from the chat.');
    });
});

1. هناك نوعان مختلفان من socket.id ينبعان من طلب علامة تبويب متصفح واحد.
2. ينفصل اتصال المقبس "المكرر" عن نفسه ، في غضون دقيقة تقريبًا باستخدام console.log لـ "تم قطع اتصال undefined من المحادثة."
3. باستخدام المولد السريع 4.2 (باستخدام Morgan) ثم تنفيذ مثال "Getting Started" ، ينتج عن اتصالات المتصفح "الجيدة" سجلات صريحة لخط واحد مثل "GET / 304 1ms". ولكن عندما يكون هناك اتصال بمقبس "مزدوج" ، يوجد سجلين صريحين ، "GET / 304 1ms" و "GET / 200 3ms - 386b"

أنا أستخدم Mac و Chrome و Express 4.2 وأحدث socket.io.

يوجد فرق توقيت بين إنشاء السجلين. يتم تشغيل السجل الأول عندما يكمل Chrome تلقائيًا "lo" إلى " localhost: 3000 " ويتم تشغيل السجل الثاني عندما أضغط على زر الإدخال.

تلقيت رسالة في سجل وحدة التحكم "X مستخدمين متصلون" وكنت مزعجًا للغاية عندما أطلق المتصفح الخاص بي إشعارات اتصال مستخدمين أو ثلاثة.

الآن ، يجب أن أعترف بأن حل المشكلة كان التعليق خارج سطر console.log. لكن استمروا في العمل الجيد يا رفاق.

ما زلت أرى هذه المشكلة في أحدث إصدار. أي تحديثات على هذا؟

أرى هذه المشكلة مع 1.0 أيضًا

لا يمكن إعادة إنتاجه على الإطلاق. هل يمكن لشخص أن ينشر مثالا كاملا؟

يوم الجمعة 14 نوفمبر 2014 الساعة 2:44:50 صباحًا Rex Pechler [email protected]
كتب:

أرى هذه المشكلة مع 1.0 أيضًا

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

سأرى ما إذا كان بإمكاني تقديم مثال بسيط غدًا.

قد أعيد إنتاجه. أنا أستخدم socket.io 1.3.5 و express 4.12.4.

يقع تطبيقي السريع على 127.0.0.1:3000 وأفتح المتصفح واكتب عنوان IP هذا وفتح socket.io مقبس ويب واحد فقط.

لدي مجال مثل abc.com وأرسله إلى 127.0.0.1. أفتح abc.com على متصفحي وفي ملف index.html يوجد السطر ؛

<script>
        var socket = io('http://localhost:3000/mysql');

        socket.on('processlist', function (data){
            console.log(data);
        });
</script>

هذا يفتح 2 مآخذ ويب.

لم أجرب nginx مع الوكيل حتى الآن. سأخبرك بمجرد أن أحاول.

لا تزال تواجه هذه المشكلة. بالنسبة لي ، حدث ذلك عند إعادة تشغيل الخادم - كنت أرفق معالجات الأحداث socket.on ('message') الخاصة بي عند تشغيل حدث الاتصال الأولي من الخادم ، وإذا تم إعادة تشغيل الخادم أثناء فتح العميل ، فقد تم تشغيل هذا الحدث عدة مرات (المزيد من الوقت لفترة أطول كان العميل ينتظر إعادة تشغيل الخادم).

لقد كان إصلاحي في الوقت الحالي هو "إبطال" حدث المقبس المرفق بحيث يحدث فقط عند الاتصال الأول بالخادم ، مثل:

client.socketEventsAttached = false;

socket.on('connect',function(){
     if (!client.socketEventsAttached){
          attachSocketEvents();
     }
});

يمكنك أيضًا وضع مستمعي حدث رسالتك خارج socket.on ('connect') مستمع كما اقترح gdiz . لقد واجهت للتو بعض المشكلات مع إطلاق أحداث مأخذ التوصيل قبل أن يكون الخادم أو العميل جاهزًا لها.

bbcollinsworth ما هو كائن العميل؟

لا تزال تواجه هذه المشكلة مع المقبس الجديد والمثال الأساسي.

ما زلت أواجه هذه المشكلة وفقًا لاتباع المثال الأساسي.

تحرير: لقد وجدت إصلاحًا ، على الرغم من أنني لست متأكدًا من أنه مناسب تمامًا. كل ما يتطلبه الأمر هو استخدام

io.once('connection', ...)

بدلا من

io.on('connection', ...)

brandonraphael ، هل يمكنك من فضلك تقديم مثال لإعادة إنتاج مشكلتك (على سبيل المثال https://github.com/darrachequesne/socket.io-fiddle) وفتح إصدار جديد؟

أي تحديث لا يزال يحدث ويخلق مشاكل في التطبيق

هذه هي السجلات -
0 | خادم Api | متصل !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! DKap3hUYFSpKBRr7AFgc 4351 2018-12-26 10:58:25
0 | خادم Api | متصل !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! VS98DBFVTNF6ifzmAFgd 4351 2018-12-26 10:58:25

4351 هو معرف المستخدم وعدد الاتصالات أيضًا ليس ثابتًا مثل 2 في حالة المستخدم 4351.
يظهر سجل آخر 6 اتصالات في نفس الوقت لنفس المستخدم.

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

أي مساعدة ستكون رائعة حقًا.
شكرا لك مقدما.

ما زلت أواجه هذه المشكلة وفقًا لاتباع المثال الأساسي.

تحرير: لقد وجدت إصلاحًا ، على الرغم من أنني لست متأكدًا من أنه مناسب تمامًا. كل ما يتطلبه الأمر هو استخدام

io.once('connection', ...)

بدلا من

io.on('connection', ...)

شكرا لك على هذا

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

كانت تواجه نفس المشكلة وكانت تدفعني للجنون. بالتأكيد لم يتم إعادة تسجيل مستمعي الحدث على العميل أيضًا. في الإعداد الخاص بي ، لدي خادم nodejs يستضيف نقطة نهاية socketio ولدي أيضًا خادم nodejs آخر يعمل كعميل socketio الخاص بي. كانت الحيلة هي توصيل جانب العميل بنقل websocket واستخدام forceNode . مثال

// client side
const socket = io('<url>', {
  transports: ['websocket'],
  forceNode: true,
});

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

كل شيء يعمل بشكل رائع ، ولكن إذا غادرت الغرفة ثم أدخلتها مرة أخرى ، فسيتم إرسال رسالة المقدمة _ مرتين_. إذا غادرت الغرفة مرة أخرى وأعدت الدخول إليها مرة أخرى ، فسيتم إرسال رسالة المقدمة ثلاث مرات ، وهكذا. كل _reconnection_ إلى _نفس الغرفة ينتج عنه رسالة مقدمة مكررة. ومع ذلك ، إذا دخلت إلى غرفة _different_ ، فإنني أرى رسالة المقدمة مرة واحدة فقط.

استخدام io.once('connection', ...) لم ينجح معي. في الواقع ، توقفت جميع أحداثي عن العمل.

استخدام طريقة "debounce" لم ينجح أيضًا. مرة أخرى ، لم يتم تسجيل أي من أحداثي.

أخيرًا ، استخدام جانب عميل option forceNode: true لم ينجح أيضًا.

أنا أستخدم 2.2.0 على كل من الخادم والعميل. هل هناك شيء مفقود؟

كنت أتساءل عن نفس المشكلة ، ولكن في النهاية ، ساعدني إخبار العميل بالاتصال فقط once .

إليك التكوين الخاص بي للعميل:

var socket = io.connect("http://localhost:3000/test", 
    { upgrade: false, transports: ['websocket'], reconnection: true, forceNew: false});
socket.once('connect', socketConn => {
    socket.on('message', data => {
        console.log(data);
    });
}); 

سيتم تسجيل العميل للتو once connect لحدث

لذلك يجب تعيين io.once من جانب العميل ، وليس من جانب الخادم.

أنا أستخدم إصدار العميل 2.1. أجد أنه من السهل جدًا تشغيله في بيئة التطوير الخاصة بي. في كل مرة يتم فيها إعادة تشغيل خادم العقدة (على سبيل المثال باستخدام nodemon) ، يقوم العميل دائمًا بتشغيل العديد من أحداث إعادة الاتصال ثم الاتصال حتى. لكن لا يمكنني معرفة السبب الجذري

أنا أستخدم إصدار العميل 2.1. أجد أنه من السهل جدًا تشغيله في بيئة التطوير الخاصة بي. في كل مرة يتم فيها إعادة تشغيل خادم العقدة (على سبيل المثال باستخدام nodemon) ، يقوم العميل دائمًا بتشغيل العديد من أحداث إعادة الاتصال ثم الاتصال حتى. لكن لا يمكنني معرفة السبب الجذري

كنت أواجه نفس المشكلة التي تستخدم أيضًا nodemon نفسها. ولكن في النهاية ، ساعد إخبار العميل بالاتصال فقط once .
جرب الرمز من ردي أعلاه. لقد ساعدني ذلك وفي كل مرة يتم فيها إعادة تشغيل الخادم ، يحصل العملاء على اتصالات جديدة.

كانت مشكلتي بسيطة

كان لدي نفس التطبيق من جانب العميل مفتوحًا في علامتي تبويب. وجه الفتاة

لدي نفس المشكلة ايضا ومع ذلك ، بالنسبة لي ، فقد وضعت معالجات جانب العميل الخاصة بي عن طريق الخطأ داخل وظيفة رد الاتصال socket.on('connection', cb) .

إليك مقتطف للتوضيح:

client.js (في node.js)

const client = require('socket.io-client');
const socket = client('my_endpoint', {
  transports: [ 'websockets' ]
});

socket.on('connect', () => {
  console.log('connected');
  socket.on('myEvent', (message) => {
    console.log(`message: ${message}`);
  });
});

عند حدوث قطع الاتصال وإعادة الاتصال ، فإنه سيستدعي socket.on('connect', cb) مرة أخرى ، وسيسجل المعالج myEvent معالجًا ثانيًا بنفس الاسم. لذلك عندما أرسل الخادم myEvent مرة أخرى ، سيكون لدي سجلي وحدة تحكم للرسالة نفسها.

لحل المشكلة ، اضطررت إلى وضع معالجاتي الأخرى خارج المعالج connect .

const client = require('socket.io-client');
const socket = client('my_endpoint', {
  transports: [ 'websockets' ]
});

socket.on('connect', () => {
  console.log('connected');
});

socket.on('myEvent', (message) => {
  console.log(`message: ${message}`);
});

أعتقد أن ارتباكي جاء من كيفية إظهار المستندات من جانب الخادم وضع أحداث socket.on داخل الحدث connect . هذا علي لأنني لم أقرأ المستندات بعناية أكبر ، لكنني اعتقدت أنني سأضع هذا هنا في حال ارتكب شخص آخر نفس الخطأ.

أيضًا ، على الرغم من أنني رأيت هذه المشكلة في node.js على وجه التحديد ، فأنا متأكد من أن هذه ستكون مشكلة في المتصفح أيضًا.