मैं Node.js में ECONNRESET में त्रुटि कैसे दर्ज करूं?


288

मैं एक चैट वेबऐप के लिए Socket.io का उपयोग करके एक Express.js एप्लिकेशन चला रहा हूं और 24h के दौरान मुझे लगभग 5 बार बेतरतीब ढंग से निम्नलिखित त्रुटि मिलती है। नोड प्रक्रिया हमेशा के लिए लपेटी जाती है और यह तुरंत ही फिर से चालू हो जाती है।

समस्या यह है कि एक्सप्रेस को फिर से शुरू करने से मेरे उपयोगकर्ता अपने कमरे से बाहर निकल जाते हैं और कोई भी ऐसा नहीं चाहता है।

वेब सर्वर HAProxy द्वारा अनुमानित है। कोई सॉकेट स्थिरता मुद्दे नहीं हैं, बस वेबसोकेट और फ्लैशस्कॉक ट्रांसपोर्ट का उपयोग कर रहे हैं। मैं इस उद्देश्य पर पुन: पेश नहीं कर सकता।

यह नोड के साथ त्रुटि है v0.10.11:

    events.js:72
            throw er; // Unhandled 'error' event
                  ^
    Error: read ECONNRESET     //alternatively it s a 'write'
        at errnoException (net.js:900:11)
        at TCP.onread (net.js:555:19)
    error: Forever detected script exited with code: 8
    error: Forever restarting script for 2 time

EDIT (2013-07-22)

दोनों सॉकेट को जोड़ा गया। क्लाइंट त्रुटि हैंडलर और अनकैप्ड अपवाद हैंडलर। लगता है कि यह एक त्रुटि पकड़ता है:

    process.on('uncaughtException', function (err) {
      console.error(err.stack);
      console.log("Node NOT Exiting...");
    });

इसलिए मुझे संदेह है कि यह सॉकेट.आईओ समस्या नहीं है, लेकिन एक अन्य सर्वर से HTTP अनुरोध है जो मैं करता हूं या एक MySQL / Redis कनेक्शन। समस्या यह है कि त्रुटि स्टैक मुझे अपने कोड समस्या की पहचान करने में मदद नहीं करता है। यहाँ लॉग आउटपुट है:

    Error: read ECONNRESET
        at errnoException (net.js:900:11)
        at TCP.onread (net.js:555:19)

मुझे कैसे पता चलेगा कि यह क्या कारण है? मैं त्रुटि से अधिक कैसे प्राप्त करूं?

ठीक है, बहुत क्रिया नहीं है लेकिन यहाँ Longjohn के साथ स्टैकट्रेस है:

    Exception caught: Error ECONNRESET
    { [Error: read ECONNRESET]
      code: 'ECONNRESET',
      errno: 'ECONNRESET',
      syscall: 'read',
      __cached_trace__:
       [ { receiver: [Object],
           fun: [Function: errnoException],
           pos: 22930 },
         { receiver: [Object], fun: [Function: onread], pos: 14545 },
         {},
         { receiver: [Object],
           fun: [Function: fireErrorCallbacks],
           pos: 11672 },
         { receiver: [Object], fun: [Function], pos: 12329 },
         { receiver: [Object], fun: [Function: onread], pos: 14536 } ],
      __previous__:
       { [Error]
         id: 1061835,
         location: 'fireErrorCallbacks (net.js:439)',
         __location__: 'process.nextTick',
         __previous__: null,
         __trace_count__: 1,
         __cached_trace__: [ [Object], [Object], [Object] ] } }

यहाँ मैं फ़्लैश सॉकेट नीति फ़ाइल परोसता हूँ:

    net = require("net")
    net.createServer( (socket) =>
      socket.write("<?xml version=\"1.0\"?>\n")
      socket.write("<!DOCTYPE cross-domain-policy SYSTEM \"http://www.macromedia.com/xml/dtds/cross-domain-policy.dtd\">\n")
      socket.write("<cross-domain-policy>\n")
      socket.write("<allow-access-from domain=\"*\" to-ports=\"*\"/>\n")
      socket.write("</cross-domain-policy>\n")
      socket.end()
    ).listen(843)

क्या इसका कारण हो सकता है?


3
@GOTZ शायद यह मदद कर सकता है (नोड js के भीतर काम करने वाले किसी व्यक्ति से बात की गई) gist.github.com/samsonradu/1b0c6feb438f5a53e30e । मैं आज सॉकेट.रोर हैंडलर तैनात करूँगा और आपको बताऊँगा।
सैमसन

1
@Gottz socket.error हैंडल नहीं करता है, लेकिन process.on ('uncaughtException') त्रुटि पकड़ता है। यहाँ त्रुटि के console.log है: { 'पढ़ा' [त्रुटि: पढ़ने ECONNRESET] कोड: 'ECONNRESET', errno:: 'ECONNRESET', syscall}
सैमसन

1
ECONNRESET नेटवर्क समस्या से हो सकता है। जैसा कि आप जानते हैं कि परीक्षण करते समय सभी अपवादों को पकड़ना असंभव है। कुछ आपके उत्पादन सर्वर पर दिखाई देंगे। आपको अपने सर्वर को मजबूत बनाना होगा। आप Redis को स्टोरेज के रूप में उपयोग करके सत्र विलोपन को संभाल सकते हैं। आपके नोड सर्वर के कम हो जाने के बाद भी यह आपके सत्र को बनाए रखता है।
user568109

1
सत्र विलोपन से संबंधित क्यों है? वे वैसे भी रेडिस द्वारा नियंत्रित किए जाते हैं।
सैमसन

3
आपके पास कम से कम एक टीसीपी सॉकेट है जिसे सुनने के लिए हैंडलर सेट नहीं है। तो अब यह जाँचने का समय है कि वह कहाँ है: D
Moss

जवाबों:


253

आपने पहले ही अनुमान लगा लिया होगा: यह एक कनेक्शन त्रुटि है।

"ECONNRESET" का अर्थ है कि टीसीपी वार्तालाप के दूसरे पक्ष ने अचानक कनेक्शन का अपना अंत बंद कर दिया। यह संभवतः एक या अधिक एप्लिकेशन प्रोटोकॉल त्रुटियों के कारण है। आप एपीआई सर्वर लॉग को देखने के लिए देख सकते हैं कि क्या यह किसी चीज़ के बारे में शिकायत करता है।

लेकिन जब से तुम भी त्रुटि जाँच और संभावित समस्या डिबग करने के लिए एक तरह से तलाश कर रहे हैं, तो आप पर एक नज़र रखना चाहिए " डिबग करने के लिए कैसे एक सॉकेट NodeJS? में त्रुटि लटका " जो एक समान रूप से प्रश्न के संबंध में stackoverflow पर तैनात थे।

विकास के लिए त्वरित और गंदा समाधान :

लॉन्गजोन का उपयोग करें , आपको लंबे स्टैक के निशान मिलते हैं जिसमें एसिंक्स ऑपरेशन होंगे।

स्वच्छ और सही समाधान : तकनीकी रूप से, नोड में, जब भी आप एक 'error'घटना का उत्सर्जन करते हैं और कोई भी इसे सुनता है, तो यह फेंक देगा । इसे फेंकने के लिए नहीं, इस पर एक श्रोता डालें और इसे स्वयं संभालें। इस तरह आप अधिक जानकारी के साथ त्रुटि लॉग कर सकते हैं।

कॉल के एक समूह के लिए एक श्रोता होना आप डोमेन का उपयोग कर सकते हैं और रनटाइम पर अन्य त्रुटियों को भी पकड़ सकते हैं। सुनिश्चित करें कि http (सर्वर / क्लाइंट) से संबंधित प्रत्येक async ऑपरेशन कोड के अन्य भागों की तुलना में अलग-अलग डोमेन संदर्भ में है, डोमेन स्वचालित रूप से errorघटनाओं को सुनेगा और इसे अपने स्वयं के हैंडलर को प्रचारित करेगा। तो आप केवल उस हैंडलर को सुनें और त्रुटि डेटा प्राप्त करें। आपको मुफ्त में अधिक जानकारी भी मिलती है।

EDIT (2013-07-22)

जैसा कि मैंने ऊपर लिखा है:

"ECONNRESET" का अर्थ है कि टीसीपी वार्तालाप के दूसरे पक्ष ने अचानक कनेक्शन का अपना अंत बंद कर दिया। यह संभवतः एक या अधिक एप्लिकेशन प्रोटोकॉल त्रुटियों के कारण है। आप एपीआई सर्वर लॉग को देखने के लिए देख सकते हैं कि क्या यह किसी चीज़ के बारे में शिकायत करता है।

यह भी हो सकता है: यादृच्छिक समय में, दूसरा पक्ष अतिभारित होता है और परिणामस्वरूप कनेक्शन को मार देता है। अगर ऐसा है, तो इस बात पर निर्भर करता है कि आप वास्तव में किससे जुड़ रहे हैं ...

लेकिन एक बात सुनिश्चित है: आपके पास वास्तव में आपके टीसीपी कनेक्शन पर एक रीड एरर है जो अपवाद का कारण बनता है। आप अपने संपादन में पोस्ट किए गए त्रुटि कोड को देखकर देख सकते हैं, जो इसकी पुष्टि करता है।


इसका मतलब 'अचानक बंद' होना नहीं है। यह आमतौर पर एक कनेक्शन को लिखने से होता है जो सहकर्मी पहले से ही सामान्य रूप से बंद हो गया था। यह एक आरएसटी जारी करने का कारण होगा।
लोर्ने

1
@EJP एक अच्छा कारण था कि मैंने "अचानक" लिखा था। त्रुटि (चेतावनी नहीं) बताती है कि कनेक्शन सहकर्मी द्वारा रीसेट किया गया था। एक मौजूदा कनेक्शन को दूरस्थ सहकर्मी द्वारा जबरन बंद कर दिया गया था। अप्रत्याशित के बाद से एक जबरन बंद है! (यह सामान्य रूप से परिणाम होता है यदि दूरस्थ मशीन पर सहकर्मी का आवेदन अचानक बंद हो जाता है, मशीन को रिबूट किया जाता है, या सहकर्मी अनुप्रयोग ने रिमोट सॉकेट पर "हार्ड क्लोज़" का उपयोग किया है। यह त्रुटि तब भी हो सकती है यदि "रखने-जीवित" गतिविधि के कारण कनेक्शन टूट गया था। असफलता का पता लगाने के दौरान एक या एक से अधिक ऑपरेशन जारी हैं ... ये ऑपरेशन और उसके बाद के ऑपरेशन विफल हो जाएंगे।)
ई-सुशी

2
मुझे यह त्रुटि तब होती है जब मैं परीक्षण के लिए ब्राउज़र (क्रोम) से समवर्ती लगभग 100 एपीआई कॉल भेजता हूं। मुझे लगता है कि क्रोम को तब अतिभारित होना चाहिए और कुछ कनेक्शनों को मारना चाहिए ... @ सैमसन - अपने स्वयं के डोमेन में प्रत्येक अनुरोध को संसाधित करने और सर्वर को पुनरारंभ किए बिना डोमेन त्रुटियों को पकड़ने में क्या गलत है?
सुपरशैनी

2
@supershnee आपको अपने डेटा, एप्लिकेशन और नोड के बाद से लगभग हमेशा अपने सर्वर को बिना किसी अपवाद के पुनः आरंभ करना चाहिए। स्वयं ही अज्ञात स्थिति में है। अपवाद के बाद जारी रहना आपके डेटा को जोखिम में डालता है। यदि आप अधिक जानकारी प्राप्त करना चाहते हैं, तो प्रक्रिया पर नोड के डॉक्स या डोमेन पर नोड के डॉक्स देखें
c1moore

39

फ्लैश नीति फ़ाइल की सेवा के लिए मेरे पास एक साधारण tcp सर्वर यह कारण था। अब मैं एक हैंडलर का उपयोग कर त्रुटि पकड़ सकता हूं:

# serving the flash policy file
net = require("net")

net.createServer((socket) =>
  //just added
  socket.on("error", (err) =>
    console.log("Caught flash policy server socket error: ")
    console.log(err.stack)
  )

  socket.write("<?xml version=\"1.0\"?>\n")
  socket.write("<!DOCTYPE cross-domain-policy SYSTEM \"http://www.macromedia.com/xml/dtds/cross-domain-policy.dtd\">\n")
  socket.write("<cross-domain-policy>\n")
  socket.write("<allow-access-from domain=\"*\" to-ports=\"*\"/>\n")
  socket.write("</cross-domain-policy>\n")
  socket.end()
).listen(843)

2
क्या कोड में कुछ भी गड़बड़ है? क्या मुझे जांचना चाहिए कि क्या लेखन से पहले सॉकेट लिखने योग्य है?
सैमसन

दोह, नहीं देखा कि तुम पहले से ही समाधान मिल गया इससे पहले कि मैं एक ही बात पोस्ट किया :) अपने प्रश्न के रूप में, हालांकि, भले ही आप जाँच करें कि सॉकेट लिखने योग्य है, यह तब नहीं हो सकता है जब आप इसे बाद में microseconds पर लिखते हैं और अभी भी एक त्रुटि है, तो यह सुनिश्चित करने के लिए "रास्ता" है।
जोआचिम इस्कसन

ठीक है, और क्या यह सुरक्षित तरीका है? त्रुटि हैंडलर के अंदर सॉकेट.क्लोज () की तरह? क्योंकि मुझे लगता है कि इन त्रुटियों के बाद मेरा सीपीयू लोड बढ़ रहा है (निश्चित नहीं)
सैमसन

2
मैंने हमेशा socket.destroy()सुनिश्चित करने के लिए त्रुटि हैंडलर में कॉल किया है। दुख की बात यह है कि मुझे दस्तावेज़ीकरण नहीं मिल रहा है कि क्या इसकी आवश्यकता है, लेकिन यह ऐसा करने के लिए एक त्रुटि का उत्सर्जन नहीं करता है।
जोआचिम इस्कासन

socket.destroy () ने मेरा दिन बचाया, जो भी काम करता है !! धन्यवाद!
फिरास अब्द अल्रहमान

27

मेरे पास एक ऐसी ही समस्या थी जहां एप्स को नोड के अपग्रेड के बाद इरेट करना शुरू कर दिया। मेरा मानना ​​है कि यह इस आइटम को Node रिलीज़ v0.9.10 पर वापस लाया जा सकता है:

  • शुद्ध: ECONNRESET (बेन नूर्डहिस) का दमन न करें

पिछले संस्करण क्लाइंट से रुकावटों पर त्रुटि नहीं करेंगे। क्लाइंट से कनेक्शन में एक ब्रेक नोड में त्रुटि ECONNRESET फेंकता है। मेरा मानना ​​है कि यह नोड के लिए इच्छित कार्यशीलता है, इसलिए फिक्स (मेरे लिए कम से कम) त्रुटि को संभालना था, जो मुझे विश्वास है कि आपने बिना किसी अपवाद के किया था। हालांकि मैं इसे net.socket हैंडलर में संभालता हूं।

आप इसे प्रदर्शित कर सकते हैं:

एक साधारण सॉकेट सर्वर बनाएं और Node v0.9.9 और v0.9.10 प्राप्त करें।

require('net')
    .createServer( function(socket) 
    {
           // no nothing
    })
    .listen(21, function()
     {
           console.log('Socket ON')
    })

V0.9.9 का उपयोग करके इसे प्रारंभ करें और फिर इस सर्वर पर FTP का प्रयास करें। मैं FTP और पोर्ट 21 का उपयोग केवल इसलिए कर रहा हूं क्योंकि मैं विंडोज पर हूं और मेरे पास एफ़टीपी क्लाइंट है, लेकिन कोई टेलनेट क्लाइंट नहीं है।

फिर क्लाइंट की तरफ से, बस कनेक्शन को तोड़ दें। (मैं सिर्फ Ctrl-C कर रहा हूं)

जब आप नोड v0.9.9 का उपयोग कर रहे हैं, और नोड v.0.9.10 और ऊपर का उपयोग करते समय आपको ERROR नहीं देखना चाहिए।

उत्पादन में, मैं v.0.10 का उपयोग करता हूं। कुछ और यह अभी भी त्रुटि देता है। फिर से, मुझे लगता है कि यह इरादा है और समाधान आपके कोड में त्रुटि को संभालने के लिए है।


3
धन्यवाद, मैं इसे खुद को nailed! यह महत्वपूर्ण है कि त्रुटियों को बिना किसी अपवाद के प्रचारित न होने दें क्योंकि यह पूरे ऐप को अस्थिर करता है। उदाहरण के लिए लगभग 10 ECONNRESET त्रुटियों को पकड़ने के बाद सर्वर कभी-कभी अप्रतिसादी हो जाता है (बस फ़्रिज़ और किसी भी कनेक्शन को हैंडल नहीं करता है)
सैमसन

नोड संस्करण परिवर्तन के बारे में भी पता था कि कोई भी त्रुटि नहीं दबाती है, लेकिन इतने सारे मुद्दों को देखते हुए और प्रत्येक संस्करण को हल करने के बजाय मैं नवीनतम के लिए जाता हूं। मैं V0.10.13 अब btw का उपयोग कर रहा हूँ
सैमसन

16

आज भी यही समस्या थी। कुछ शोध के बाद मुझे एक बहुत उपयोगी --abort-on-uncaught-exceptionनोड.जेएस विकल्प मिला । न केवल यह बहुत अधिक वर्बोज़ और उपयोगी त्रुटि स्टैक ट्रेस प्रदान करता है, बल्कि आगे की डिबग की अनुमति देते हुए एप्लिकेशन क्रैश पर कोर फ़ाइल भी बचाता है।


4
अजीब है कि इस पुराने प्रश्न का एक नया उत्तर मुझे दिखना चाहिए - लेकिन यह बहुत अच्छा है, धन्यवाद
अर्धविराम

13

मैं एक ही मुद्दे का सामना कर रहा था, लेकिन मैंने इसे कम कर दिया:

server.timeout = 0;

पहले server.listenserverयहाँ एक HTTP सर्वर है। डिफ़ॉल्ट समय एपीआई प्रलेखन के अनुसार 2 मिनट है ।


5
यह एक समाधान नहीं है, बल्कि एक त्वरित उपसर्ग है जो बिना किसी त्रुटि के चीजों को तोड़ देगा।
निशांत घोडके

9

एक और संभावित मामला (लेकिन दुर्लभ) हो सकता है यदि आपके पास सर्वर संचार के लिए सर्वर है और server.maxConnectionsबहुत कम मूल्य पर सेट है।

नोड के मूल परिवाद net.js में यह कॉल clientHandle.close()करेगा जो त्रुटि का कारण भी होगा ECONNRESET:

if (self.maxConnections && self._connections >= self.maxConnections) {
  clientHandle.close(); // causes ECONNRESET on the other end
  return;
}

शानदार कॉल, लेकिन maxConnectionsडिफ़ॉल्ट मान है Infinity। यह केवल मामला होगा (जैसा कि आपने कहा) यदि आपने उस मूल्य को स्पष्ट रूप से ओवरराइड किया है।
गजस

7

हां, पॉलिसी फ़ाइल की आपकी सेवा निश्चित रूप से दुर्घटना का कारण बन सकती है।

दोहराने के लिए, बस अपने कोड में देरी जोड़ें:

net.createServer( function(socket) 
{
    for (i=0; i<1000000000; i++) ;
    socket.write("<?xml version=\"1.0\"?>\n");

... और telnetपोर्ट से कनेक्ट करने के लिए उपयोग करें। यदि आपने विलंब समाप्त होने से पहले टेलनेट को डिस्कनेक्ट कर दिया है, तो सॉकेट.राइट को एक त्रुटि फेंके जाने पर आपको एक दुर्घटना (बिना अपवाद के) मिल जाएगी।

यहां दुर्घटना से बचने के लिए, सॉकेट को पढ़ने / लिखने से पहले एक त्रुटि हैंडलर जोड़ें:

net.createServer(function(socket)
{
    for(i=0; i<1000000000; i++);
    socket.on('error', function() { console.log("error"); });
    socket.write("<?xml version=\"1.0\"?>\n");
}

जब आप उपरोक्त डिस्कनेक्ट की कोशिश करते हैं, तो आपको क्रैश के बजाय बस लॉग संदेश मिलेगा।

और जब आप कर लें, तो देरी को दूर करने के लिए याद रखें।


6

मुझे अपने विकास के दौरान ECONNRESET त्रुटि भी मिलती है, जिस तरह से मैं इसे हल करता हूं वह मेरे सर्वर को शुरू करने के लिए नोडमॉन का उपयोग नहीं करके है, बस "node server.js"मेरे सर्वर को मेरी समस्या को शुरू करने के लिए उपयोग करें।

यह अजीब है, लेकिन यह मेरे लिए काम करता है, अब मैं कभी भी ECONNRESET त्रुटि नहीं देखता।


4

मेरे पास यह त्रुटि भी थी और डीबगिंग और विश्लेषण के दिनों के बाद इसे हल करने में सक्षम था:

मेरा समाधान

मेरे लिए VirtualBox (Docker के लिए) समस्या थी। मेरे VM पर पोर्ट अग्रेषण कॉन्फ़िगर किया गया था और त्रुटि केवल अग्रेषित पोर्ट पर हुई थी।

सामान्य निष्कर्ष

निम्नलिखित टिप्पणियों से आप उन दिनों के काम को बचा सकते हैं जो मुझे निवेश करने थे:

  • मेरे लिए समस्या केवल एक पोर्ट पर लोकलहोस्ट से लोकलहोस्ट के कनेक्शन पर हुई। -> जाँच करें कि इनमें से कोई भी स्थिरांक समस्या को हल करता है।
  • मेरे लिए समस्या केवल मेरी मशीन पर हुई है -> किसी और को इसे आज़माने दें।
  • मेरे लिए समस्या केवल थोड़ी देर बाद हुई और मज़बूती से पुन: पेश नहीं की जा सकी
  • मेरी समस्या को किसी भी नोड या एक्सप्रेस (डीबग-) टूल के साथ निरीक्षण नहीं किया जा सकता है। -> इस पर समय बर्बाद मत करो

-> यह पता लगाएँ कि क्या कुछ आपके नेटवर्क (-settings) के साथ गड़बड़ कर रहा है, जैसे VMs, Firewalls आदि, यह शायद समस्या का कारण है।


2

मैंने बस एक अलग नेटवर्क से कनेक्ट करके समस्या का हल किया । यह संभावित समस्याओं में से एक है।

जैसा कि ऊपर चर्चा की गई है, ECONNRESET अर्थ है कि टीसीपी वार्तालाप ने अचानक कनेक्शन के अपने अंत को बंद कर दिया।

आपका इंटरनेट कनेक्शन आपको कुछ सर्वरों से जुड़ने से रोक सकता है। मेरे मामले में, मैं mLab (क्लाउड डेटाबेस सेवा जो MongoDB डेटाबेस को होस्ट करता है) से कनेक्ट करने का प्रयास कर रहा था। और मेरा आईएसपी इसे रोक रहा है।


इसने मेरे लिए काम किया, मेरा कोड जो कुछ घंटे पहले ठीक काम कर रहा था अचानक काम करना बंद कर दिया, पता चला, नेटवर्क परिवर्तन ने समस्या का कारण बना
अक्लंक जैन

2

मैंने इस समस्या को हल कर दिया था:

  • मेरे वाईफाई / ईथरनेट कनेक्शन को बंद करें और चालू करें।
  • मैंने टाइप किया: npm updateटर्मिनल में एनपीएम को अपडेट करने के लिए।
  • मैंने सत्र से लॉग आउट करने और फिर से लॉग इन करने का प्रयास किया

उसके बाद मैंने उसी npm कमांड की कोशिश की और अच्छी बात यह थी कि इस पर काम किया गया। मुझे यकीन नहीं था कि यह इतना आसान है।

मैं CENTOS 7 का उपयोग कर रहा हूं


0

मेरे पास एक ही मुद्दा था और ऐसा प्रतीत होता है कि Node.js संस्करण समस्या थी।

मैंने Node.js (10.14.2) के पिछले संस्करण को स्थापित किया है और सब कुछ एनवीएम का उपयोग करके ठीक था (आप नोडोड के कई संस्करण स्थापित करने की अनुमति देते हैं और जल्दी से एक संस्करण से दूसरे पर स्विच करते हैं)।

यह एक "साफ" समाधान नहीं है, लेकिन यह आपको अस्थायी रूप से सेवा दे सकता है।


0

मैंने अभी यह पता लगाया है, कम से कम मेरे उपयोग के मामले में।

मैं ला रही थी ECONNRESET । यह पता चला कि जिस तरह से मेरे क्लाइंट को सेट किया गया था, वह सर्वर को एपीआई कॉल के साथ वास्तव में जल्दी से एक टन बार मार रहा था - और इसे केवल एक बार समापन बिंदु को हिट करने की आवश्यकता थी।

जब मैंने तय किया कि, त्रुटि हो गई थी।


-2

इन विकल्पों को socket.io में जोड़ने का प्रयास करें:

const options = { transports: ['websocket'], pingTimeout: 3000, pingInterval: 5000 };

उम्मीद है इससे आपको मदद मिलेगी !

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.