त्वरित हैक के रूप में आप "नए कनेक्शन को मजबूर कर सकते हैं": गलत कॉन्फ़िगरेशन

मैंने अपने आवेदन में इस बग का अवलोकन किया।
रेप्रोड्यूस अगले था। WebFcket कनेक्शन के साथ FF में, कुछ त्रुटि हुई। फिर अन्य 3 पुन: जोड़ने की घटनाओं के बाद एक उत्पन्न हुआ था। इसके बाद 3 नए कनेक्शन स्थापित किए गए, और ब्राउज़र को एक के बजाय 3 संदेश प्राप्त हुए।

शायद पुनः तर्क तर्क में कुछ बग? कुछ, जो एक के बजाय कई पुनरावर्तन उत्पन्न करता है।

मैंने पुराने ब्राउज़रों में उन मुद्दों को देखा है जो वेबसोकेट (जैसे, एफएफ 3.6) का समर्थन नहीं करते हैं, जहां डोम रेडी इवेंट में सॉकेट.आईओ ("$ ()" को इनिशियलाइज़ करना) कई कनेक्शन का कारण बनता है, जबकि बाद के विंडो में लोड करना। घटना नहीं है। मैंने इस विशेष मुद्दे को लगातार प्रतिलिपि प्रस्तुत करने योग्य पाया है। यकीन नहीं होता कि यह वही चीज़ है जिसे आप देख रहे हैं लेकिन लक्षण बहुत समान दिखते हैं।

एक ही मुद्दा यहाँ भी। समस्या यह है कि यदि सर्वर किसी भी कारण से दुर्घटनाग्रस्त हो जाता है और फिर वापस चालू हो जाता है, तो हर बार 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. अपने सर्वर में धीमा कोड डालें (हमें 4-8 सेकंड के लिए नोड.जेएस मेनलूप को निलंबित करना चाहिए)
   समारोह फाइब्रो (एन) {
   if (n <2) वापसी 1;
   वापसी फाइब्रो (एन -2) + फाइब्रो (एन -1);
   }
   इसे ऑर्ट-सेक्शन में डालें। इसे हाथ मिलाना चाहिए:
   io.set ('प्राधिकरण', फ़ंक्शन (डेटा, स्वीकार) {
   कंसोल.info ("फ़िबो ::" + फाइबो (41));
   आपको अपने नोड कंसोल में प्रयोग करना चाहिए, फाइब्रो (एन) को खोजने के लिए, जो
   4-8 सेकंड के लिए मुख्य-लूप को ब्लॉक करेगा।
3. अब, आपको अपने सर्वर का तेजी से पुनः आरंभ करना चाहिए।
   कनेक्शन के लिए स्लो कोड लागू होगा।
   ग्राहक को यह सूचित किया जाना चाहिए कि वह हैंडसम नहीं है।
   और अब यह फिर से कनेक्ट करने की कोशिश करता है।
   कंसोल में आपको कई रीकनेक्ट अटैक्स दिखाई देंगे (यदि आप "कॉलबैक / फिर से कनेक्ट / कॉलबैक" पर लॉगिंग डालते हैं)।
   हमारी सुस्ती हैक होने के बाद इसे हमेशा के लिए दोहराया जाएगा।

वास्तविक जीवन में यह कम से कम कई सेकंड के लिए सर्वर-उत्तर की मंदी के माध्यम से पुन: उत्पन्न होता है।
यह तब हो सकता है जब नोड.जेएस भारी-भार के अधीन होता है और कुछ देरी से प्रतिक्रिया करता है।
या कुछ नेटवर्क मंदी के कारण भी ऐसा व्यवहार हो सकता है।
सर्वर रिस्टार्ट होने के बाद भी इसे दोबारा बनाया जा सकता है।

यह पंक्ति (सॉकेट.जेएस, 511):
self.reconnectionTimer = setTimeout (हो सकता है, पुन: कनेक्ट करें, self.reconnectionDelay);

कनेक्ट कॉल के बाद शेड्यूल इवेंट। और अगर कनेक्ट-रिस्पॉन्स कम से कम एक सेकंड के लिए देरी हो रही है, तो यह ट्रिगर हो जाता है और कतार में नए पुन: कनेक्ट करता है। 2 सेकंड के बाद यह एक और एक जोड़ता है।

मैंने एक ठीक किया, लेकिन यह परीक्षण नहीं किया गया है और बहुत ठोस नहीं दिखता है। मुख्य मुद्दा - कैसे कारण है जिसके बारे में कॉलबैक / टाइमर को समवर्ती कार्य के लिए समवर्ती रूप से चलाया जा सकता है।
यह पंक्ति: https://github.com/LearnBoost/socket.io-client/blob/master/lib/socket.js#L490 भी डुप्लिकेट कनेक्शन को जन्म दे सकती है।

सॉकेट.आईओ ग्राहक के बारे में तर्क करने के लिए बहुत सरल हो सकता है, अगर यह कुछ राज्य मशीन का उपयोग करने के लिए फिर से शुरू किया जाएगा। वर्तमान में राज्य अलग-अलग झंडे (जुड़ा हुआ, कनेक्ट करना, फिर से जोड़ना, आदि) में फैला हुआ है। और कई कार्यों में मैंने गार्ड्स को देखा जैसे "if (self.reconnecting)" और कई अन्य।
राज्य मशीन राज्य और घटनाओं के सेट के लिए इस तर्क को सरल बना सकती है। और टाइमर का उपयोग केवल आग की घटना के लिए किया जा सकता है। यदि यह घटना गलत स्थिति में है, तो राज्य-मशीन इस घटना को अनदेखा कर सकती है और खुद को परेशान नहीं कर सकती है।

मुझे JS के लिए अच्छा STM नहीं मिला है, लेकिन Ruby से यह आसानी से JS में पोर्ट किया जा सकता है: https://github.com/geekq-workflow

निश्चित रूप से इस मुद्दे को सुधारने पर +1। मैं सीधे सॉकेट.आईओ या सॉकेट.आईओ-क्लाइंट को संशोधित किए बिना इस समस्या के लिए चारों ओर एक काम खोजने की कोशिश कर रहा हूं, लेकिन दुर्भाग्य से एकमात्र तरीका है जिसके साथ मैं भरोसेमंद रूप से आया हूं, बस पुन: कनेक्ट करने में अक्षम है। जो निश्चित रूप से एक अच्छा समाधान नहीं है, विशेष रूप से मोबाइल उपकरणों के बढ़ते उपयोग के साथ, फिर से कनेक्ट करना एक बड़ी आवश्यकता है।

क्या किसी को भी पता है कि यह डेवलपर्स प्राथमिकता सूची में कैसे आता है?

आह। ऐसा लगता है कि इस मुद्दे को इस मुद्दे से 3rd-Eden को सौंपा गया है: https://github.com/LearnBoost/socket.io/issues/430

मैंने एक क्लाइंट के लिए एक फिक्स किया है और पुल अनुरोध भेजा है। यह 0.8.4 में अच्छा काम करता है और अन्य संस्करणों में अच्छा काम कर सकता है। लेकिन इसे हैंडशेक के लिए AJAX (या CORS) का उपयोग करने की स्रोत क्षमता में अक्षम करना होगा। इसे देखें: https://github.com/LearnBoost/socket.io-client/pull/342 विवरण के लिए।

इतने पुराने मुद्दे को पुनर्जीवित करने के लिए क्षमा करें। मैं उपयोग कर रहा हूँ मुझे विश्वास है कि सॉकेट का नवीनतम संस्करण .io (या कम से कम, मैंने npm स्थापित किया सॉकेट। यह समस्या अभी भी मेरे लिए है, मैं सॉकेट के लिए अपेक्षाकृत नया हूँ। एक पूरे के रूप में। मेरे पास ऐसे मुद्दे भी हैं जहां कभी-कभी पहला कनेक्शन (दोनों में से जो मैंने केवल किसी एक समय में हुआ है) में एक रीड एरर है। यदि मैं कुरकुरा कहने में सही हूं, तो आपका सुधार प्रतिबद्ध था, इसलिए ऐसा नहीं होना चाहिए, लेकिन यह तब भी होता है जब तक कि मैं एक महत्वपूर्ण कारक नहीं छूट जाता?

संपादित करें -

यह सॉरी फोर्क सॉकेट प्रतीत होता है ।io और उस पर एक फिक्स किया गया था और यह फिक्स मूल सॉकेट के लिए प्रतिबद्ध नहीं था।

@JTallis मेरे पास @gdiz जैसा ही मुद्दा था और उनके सुझाव ने अच्छा काम किया। यदि आपका मुद्दा समान है, तो मेरा सुझाव है कि आप इसे आज़माएं और हमें बताएं कि यह कैसे काम करता है।

मैं भी 0.9.16 के साथ इस मुद्दे पर चल रहा हूँ जो मुझे लगता है कि सबसे वर्तमान संस्करण है। यह होने से रोकने के आसपास gdiz कैसे काम करता है? पूरी तरह से समझ नहीं आया।

omg ... मैं यह जानने के लिए कई घंटे बिताता हूं कि मेरे ऐप में क्या गड़बड़ है, और कनेक्शन खो जाने और नवीनीकरण के बाद सर्वर और क्लाइंट के बीच संदेशों की नकल क्यों होती है ...

0.9.16 का उपयोग करके मैं इस मुद्दे की पुष्टि कर सकता हूं

मैं एक ही फाइल नोड.जेएस फ़ाइल में निम्नलिखित क्लाइंट और सर्वर कोड के साथ एक डबल कनेक्शन इवेंट प्राप्त कर सकता हूं:

"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) यदि मैं url से "/ चैट" को हटाकर नामांकित कनेक्शन को सामान्य में बदल देता हूं तो केवल एक कनेक्शन घटना है।

2) यदि मैं तुरंत सर्वर शुरू करता हूं, तो सेट इन्टरवल समय को शून्य में बदल दें, कोई प्रारंभिक कनेक्शन त्रुटि नहीं है और केवल एक कनेक्शन घटना है।

किसी भी काम के आसपास या इसके लिए सुधार?

एक ही मुद्दा रहा। यदि सॉकेट.io सर्वर अनपेक्षित रूप से क्लाइंट को दो बार फिर से जोड़ देता है तो क्लाइंट द्वारा प्रत्येक संदेश को दो बार संसाधित किया जाता है। वास्तव में ग्राहक अंत पर मेरे मायने रखता है।

मुझे 1.0.0-प्री 2 रिलीज के साथ एक ही समस्या है। जब मैं सॉकेट को पुनर्स्थापित करता हूं तो मेरे पास दो "400 खराब अनुरोध" होते हैं।

आज इस पर गौर करेंगे!

आज इस पर गौर करेंगे!

यदि आपको अधिक विवरण, लॉग या स्क्रीन की आवश्यकता है तो संकोच न करें! यह हर बार नहीं है।

क्लाइंट में सॉकेट.io.js 1.0.6 ऑन लाइन 2755:

Request.prototype.create = function (isBinary, supportBinary) {
var xhr = this.xhr = new XMLHttpRequest ({एजेंट: this.agent, xdomain: this.xd});
...
}

मेरा मानना ​​है कि इसे स्थापित करना एक अच्छा विचार है:
xhr.timeout = Manager._timeout का उदाहरण - 10 एमएस
इस तरह से आप क्लाइंट साइड पर कई क्लाइंट सॉकेट निर्माण को रोकते हैं।
सर्वर की ओर से कई सॉकेट्स दिल की धड़कन का समय समाप्त कर देंगे।

मूल सॉकेट.आईओ "गेटिंग स्टार्टेड" उदाहरण (http://socket.io/get-started/chat/) में यह डबल सॉकेट कनेक्शन समस्या है।

निम्न में से एक (संभाव्यता के बढ़ते क्रम में) एकल ब्राउज़र टैब कनेक्शन से डबल सॉकेट कनेक्शन में परिणाम होता है:
a) पहले ब्राउज़र टैब से ही लोकलहोस्ट: 3000 से जुड़ने पर
b) एक दूसरे ब्राउज़र टैब से, लोकलहोस्ट: 3000 से कनेक्ट करने पर
ग) कनेक्ट करने से पहले ब्राउज़र कंसोल को खुला रखें (लोकलहोस्ट: 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. "डुप्लिकेट" सॉकेट कनेक्शन खुद को डिस्कनेक्ट करता है, कंसोल के साथ लगभग एक मिनट में "अपरिभाषित" चैट से डिस्कनेक्ट हो गया है।
3. एक्सप्रेस जनरेटर 4.2 (मॉर्गन का उपयोग करके) का उपयोग करना और फिर "गेटिंग स्टार्ट" उदाहरण को लागू करना, "अच्छा" ब्राउज़र कनेक्शन का परिणाम एकल लाइन जैसे "गेट / 304 1ms" के एक्सप्रेस लॉग में होता है। लेकिन जब भी, यह "डबल" सॉकेट कनेक्शन होता है, दो एक्सप्रेस लॉग होते हैं, "GET / 304 1ms" और "GET / 200 3ms - 386b"

मैं मैक, क्रोम, एक्सप्रेस 4.2 और नवीनतम सॉकेट.आईओ का उपयोग कर रहा हूं।

दो लॉग के निर्माण के बीच एक समय का अंतर है। पहला लॉग तब निकाल दिया जाता है जब Chrome ने "लो" को " लोकलहोस्ट: 3000 " पर

मेरे पास "X उपयोगकर्ता जुड़े" कंसोल लॉग संदेश था और जब मेरा खुद का ब्राउज़र 2 या 3 उपयोगकर्ता कनेक्शन नोटिस ट्रिगर हो गया था तो बहुत गुस्सा आ रहा था।

अब, मुझे स्वीकार करना होगा कि मेरी समस्या का हल कंसोल.लॉग लाइन पर टिप्पणी कर रहा था। लेकिन अच्छे काम करते रहो, दोस्तों।

मैं अभी भी नवीनतम संस्करण में इस मुद्दे को देखता हूं। इस पर कोई अपडेट?

मैं इस मुद्दे को 1.0 के साथ भी देख रहा हूं

बिल्कुल इसे पुन: पेश नहीं कर सकते। क्या कोई पूर्ण उदाहरण पोस्ट कर सकता है?

शुक्र 14 नवंबर 2014 को 2:44:50 बजे रेक्स पाइक्लर नोटिफिकेशन @github.com पर
लिखा था:

मैं इस मुद्दे को 1.0 के साथ भी देख रहा हूं

-
इस ईमेल का उत्तर सीधे दें या इसे GitHub पर देखें
https://github.com/Automattic/socket.io/issues/474#issuecomment -62928229
।

मैं देखूंगा कि क्या मैं कल एक सरल उदाहरण कोड़ा मार सकता हूं।

मैं इसे पुन: पेश कर सकता हूं। मैं socket.io 1.3.5 और एक्सप्रेस 4.12.4 का उपयोग कर रहा हूं।

मेरा एक्सप्रेस ऐप 127.0.0.1:3000 पर बैठता है और मैं अपने ब्राउज़र को खोलता हूं और टाइप करता हूं कि आईपी एड्रेस और सॉकेट.आईओ केवल एक वेबसैट खोलता है।

मेरे पास एक डोमेन है जैसे 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 की कोशिश नहीं की है। मैं कोशिश करते ही आपको बता दूंगा।

अभी भी इस मुद्दे का सामना। मेरे लिए यह सर्वर रिस्टार्ट पर हुआ - मैं सर्वर से आरंभिक कनेक्शन इवेंट निकालते समय अपने सॉकेट.ऑन ('मैसेज') ईवेंट हैंडलर संलग्न कर रहा था, और यदि क्लाइंट फिर से शुरू होता है तो क्लाइंट उस इवेंट को कई बार निकालता है (अधिक समय अब ग्राहक सर्वर के पुनः आरंभ होने की प्रतीक्षा कर रहा था)।

अब के लिए मेरा फिक्स सॉकेट ईवेंट को 'डिसाइड' करना है, इसलिए यह केवल पहले सर्वर कनेक्ट पर होता है, जैसे:

client.socketEventsAttached = false;

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

आप अपने संदेश ईवेंट श्रोताओं को भी सॉकेट के बाहर रख सकते हैं। ('कनेक्ट') श्रोता के रूप में @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', ...)

इसके लिए शुक्रिया

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

एक ही समस्या थी और यह मुझे पागल कर रहा था। निश्चित रूप से ग्राहक पर घटना श्रोताओं को फिर से पंजीकृत नहीं कर रहा था। मेरे सेटअप में, मेरे पास सॉकेटियो एंडपॉइंट की मेजबानी करने वाला एक नोडज सर्वर है और मेरे सॉकेटियो क्लाइंट के रूप में कार्य करने वाला एक अन्य नोडज सर्वर भी है। चाल ग्राहक पक्ष को वेबसैट परिवहन से जोड़ने और forceNode उपयोग करने के लिए

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

मुझे विश्वास है कि मैं यह एक ही मुद्दा रहा हूँ। मैं एक चैट रूम बना रहा हूं और जब कोई कमरे में शामिल होता है, तो मैं "कमरे में शामिल हो गया है "कमरे में संदेश।

सब कुछ बहुत अच्छा काम करता है, लेकिन अगर मैं कमरे को छोड़ देता हूं और फिर दूसरी बार दर्ज करता हूं, तो इंट्रो संदेश _twice_ उत्सर्जित होता है। यदि मैं कमरे को फिर से छोड़ता हूं और इसे तीसरी बार फिर से दर्ज करता हूं, तो इंट्रो संदेश तीन बार उत्सर्जित होता है, और इसी तरह। प्रत्येक _reconnection_ से _same_ कमरे में डुप्लिकेट परिचय संदेश मिलता है। हालाँकि, अगर मैं एक _different_ कक्ष में प्रवेश करता हूं, तो मुझे केवल एक बार परिचय संदेश दिखाई देता है।

io.once('connection', ...) का उपयोग करना मेरे लिए कारगर नहीं रहा। वास्तव में, मेरी सभी घटनाओं ने काम करना बंद कर दिया।

"पराजय" विधि का उपयोग करने से भी काम नहीं किया। फिर, मेरी कोई भी घटना भी दर्ज नहीं हुई।

अंत में, 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 संस्करण का उपयोग कर रहा हूं। मुझे लगता है कि यह मेरे देव दूत में बहुत आसान है। जब भी मेरा नोड सर्वर पुनरारंभ होता है (उदा। नोडमॉन का उपयोग करके) क्लाइंट हमेशा कई रीकनेक्ट घटना को ट्रिगर करता है तब भी कनेक्ट होता है। लेकिन मैं इसका मूल कारण नहीं जान सकता

मैं क्लाइंट 2.1 संस्करण का उपयोग कर रहा हूं। मुझे लगता है कि यह मेरे देव दूत में बहुत आसान है। जब भी मेरा नोड सर्वर पुनरारंभ होता है (उदा। नोडमॉन का उपयोग करके) क्लाइंट हमेशा कई रीकनेक्ट घटना को ट्रिगर करता है तब भी कनेक्ट होता है। लेकिन मैं इसका मूल कारण नहीं जान सकता

मैं एक ही मुद्दा है कि खुद को भी nodemon का उपयोग कर रहा था। लेकिन अंततः, क्लाइंट को केवल once कनेक्ट करने में मदद करने के लिए कह रहा है।
ऊपर दिए गए मेरे उत्तर से कोड का प्रयास करें। इसने मेरी और हर बार सर्वर रिस्टार्ट होने में मदद की, ग्राहकों को नए कनेक्शन मिल रहे हैं।

मेरी समस्या सरल थी

मेरे पास 2 टैब पर एक ही क्लाइंट-साइड ऐप खुला था। उफ़

मेरे पास भी यही मुद्दा था। हालांकि, मेरे लिए, मैंने गलती से अपने क्लाइंट-साइड हैंडलर को socket.on('connection', cb) कॉलबैक फ़ंक्शन के अंदर डाल दिया।

यहाँ प्रदर्शित करने के लिए एक स्निपेट है:

client.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 घटना। डॉक्स को और अधिक ध्यान से न पढ़ने के लिए मुझ पर यह है, लेकिन मुझे लगा कि मैं इसे यहां डालूंगा अगर कोई और गलती करता है।

हालांकि, भले ही मैंने नोड में इस मुद्दे को देखा था। विशेष रूप से, मुझे यकीन है कि यह ब्राउज़र में भी एक समस्या होगी।