Socket.io: قطع اتصال "نهاية النقل" غير المبررة بعد الترقية

يمكن أن يكون 0.9.1 قد تسبب في حدوث خلل في ضربات القلب مما يؤدي إلى قطع الاتصال المبكر.
أنا أبحث في الأمر وقد يكون لدي 0.9.2 غدًا

نفس الشيء. مشاهدة عمليات قطع الاتصال / إعادة الاتصال المتكررة في Chrome & FF على جهاز Mac والعميل والخادم على نفس الجهاز.
يمكن رؤيتها بسهولة من أمثلة socket.io في الملف التمهيدي ، الإعدادات الافتراضية دون تغيير.

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

كان الحل البديل بالنسبة لي هو تعيين مهلة الإغلاق يدويًا:

io.configure( function() {
    io.set('close timeout', 60*60*24); // 24h time out
});

كنت أواجه هذه المشكلة أيضا. شكرا steffenwt على الحل.

نعم ، لدي هذا الخطأ أيضًا. لقد بدأت في تعلم socket.io منذ بضعة أيام وظننت في البداية أنني أفعل شيئًا خاطئًا.

الرجوع إلى 0.9.0 يعمل.

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

heartbeat2 gets sent and recieved all fine
heartbeat3 gets sens but never gets recieved
disconnect

سجل هنا:

   debug - emitting heartbeat for client 18615332192056708826
   debug - websocket writing 2::
   debug - set heartbeat timeout for client 18615332192056708826
   info  - transport end
   debug - set close timeout for client 18615332192056708826
   debug - cleared close timeout for client 18615332192056708826
   debug - cleared heartbeat timeout for client 18615332192056708826
   debug - discarding transport

لدي مشكلة أيضا.

أنا استخدم 0.91-1.

أحاول ذلك ، لكن عنده هذه المشكلة.

io.configure (الوظيفة () {
io.set ("مهلة الإغلاق" ، 60_60_24) ؛ // 24 ساعة
}) ؛

نفس المشكلة هنا

هل قمت بالرجوع إلى 0.9.0؟ لقد حددته الآن على أنه الأحدث في NPM

نفس المشكلة هنا لـ 0.9.1-1 ، تم تخفيض التصنيف إلى 0.9.0 ، واختفت المشكلة.

كحل بديل ، يمكنك إرسال بعض عناصر الحماية من العميل ، على سبيل المثال 20 ثانية والإجابة على الفور على هؤلاء من الخادم:

العميل: setInterval (function () {socket.emit ("keep-live"، null)}، 20 * 1000)؛
server: socket.on ('keep-live'، function (data) {socket.emit ('keep-life'، null)؛})؛

FWIW: إذا كنت تخدم العميل من خادم مختلف ، ولم يتم تخفيض رمز العميل إلى 0.9.0 ، فستظل ترى المشكلة.

لقد خفضت تصنيف "socket.io" إلى 0.9.0 وما زلت أرى المشكلة. ثم قمت بإرجاع إصدار socket.io-client إلى 0.9.0 ولم أحصل على قطع الاتصال.

أيضًا ، عمليات النقل التي جربتها والتي فشلت هي مآخذ الويب واستقصاء xhr.

يجب إغلاق هذه القضية ، أليس كذلك؟

لدي نفس المشكلة. لكنني لاحظت أن السبب في ذلك هو أن لدي هابروكسي.

مشكلتي هنا:

frontend all 0.0.0.0:80
    default_backend www_backend
    acl is_websocket path_beg /socket.io
    acl is_websocket hdr(Upgrade) -i WebSocket
    acl is_websocket hdr_beg(Host) -i ws
    timeout client 1000

مباشرة في السطر "timeout client 1000" (لقد غيرته إلى ثانية واحدة لمعرفة ما إذا كانت هذه هي المشكلة ، وكانت ...).

لذا فأنا الآن أبحث عما إذا كانت هناك طريقة لتغييرها فقط للخلفيات ذات المقبس الشبكي.

آمل أن يساعد هذا شخصًا ما: +1:

لمعلوماتك ، ما زلت أرى هذه المشكلة أيضًا مع استقصاء xhr و 0.9.14. هناك فصل قسري كل 25 ثانية. السجل مطابق لما ورد أعلاه.

يمكنني أيضًا التحقق من أن هذا يحدث مع خادم 0.9.14 وعميل 0.9. على الرغم من أنه لا ينقطع كل 25 ثانية ، إلا أنه ينقطع بشكل متقطع. لقد قمت بتتبع ذلك إلى Stream.emit ('end')؛ في node.js '_stream_readable.js. أعتقد أنه نتيجة قراءة EOF في المخزن المؤقت.

citosid لماذا قد تتسبب مهلة العميل haproxy في حدوث ذلك؟

يحدث مع 0.9.16. نفس الشيء بالنسبة لـ BoarK

هل دعم socket.io ميت؟

joefaron يجب أن يكون هناك دعم قبل أن يموت. لذا لا ، دعم Socket.IO لم يمت ، لم يكن موجودًا أبدًا.

نفس المشكلة هنا مع Socket.io 0.9.16 - مشاهدة الاتصالات تنخفض كل 25 ثانية تقريبًا والسجلات تعرض "تجاهل النقل" في نفس الوقت.

الرجوع إلى مستوى 0.8.6 ثابت في الأساس كل شيء بالنسبة لي .. وأنا أستخدمه
jsonp- الاقتراع بدلاً من الاستقصاء xhr كنسخة احتياطية لمقبس الويب .. يبدو بعيدًا
أكثر استقرارًا.

يوم الأحد 26 كانون الثاني (يناير) 2014 الساعة 10:16 صباحًا ، آران ريكس إخطارات github.com

نفس المشكلة هنا مع Socket.io 0.9.16 - رؤية الاتصالات تنخفض كل 25 ~
الثواني والسجلات تظهر "تجاهل النقل" في نفس الوقت.

-
قم بالرد على هذه الرسالة الإلكترونية مباشرة أو tHubhttps: //github.com/LearnBoost/socket.io/issues/777#issuecomment -33325205
.

مرحبًا joefaron ، صحتك لمساعدتك.

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

لقد تمكنت من تكرار هذا الخطأ في كل من Firefox والبنية المستقرة الحالية لـ Chrome (32.0.1700.76 م).

في البداية حاولت تعطيل دقات القلب تمامًا بالنسبة لتطبيقنا لم تكن مطلوبة حقًا ، ويمكن القيام بذلك على النحو التالي (وفقًا للمستندات الحالية ، على الرغم من أنني عندما حاولت ذلك ، بدا لي أنه أزال جميع طرق النقل وانتهى به الأمر باستمرار تحطم وإعادة).
io.set('heartbeats', false);

نظرًا لأن هذا فشل ، كانت محاولتي التالية هي زيادة المهلة بين طلبات نبضات القلب والتي يمكن إجراؤها باستخدام ما يلي داخل app.js:
io.set('heartbeat timeout', 99999); // 99999 being the time between requests in seconds - Default is 25, please choose your value as applicable for your applications

لقد نجح هذا في التعامل مع تطبيقنا لأننا لا نهتم بفصل العملاء ، وقد لا يكون هذا خيارًا قابلاً للتطبيق في بيئتك.

بالنسبة لأي شخص آخر يعاني من هذه المشكلة في حالة ما إذا كان ذلك مفيدًا ، فإن بيئتي هي كما يلي:
NodeJS: v0.10.24 Socket.io: v0.9.16 Centos 6.5

أعتقد أن هذه مسألة ملحة / حرجة حقًا. لماذا لم يتم حلها بعد؟ لقد مرت سنتان منذ بداية موضوع هذا الموضوع.

أواجه هذه المشكلة أيضًا:

NodeJS: v0.10.24
Socket.io: v0.9.16

d-oliveros: أقترح بشدة تخفيض التصنيف إلى 0.8.6. لم يكن لدي هذا
المشكلة .. ولا أعتقد أن الإصدار الأخير سيتم إصلاحه في المستقبل القريب.

يوم السبت 15 فبراير 2014 الساعة 8:55 مساءً ، d-oliveros [email protected]

أعتقد أن هذه مسألة ملحة / حرجة حقًا. لماذا لم يكن
حل بعد؟ لقد مرت سنتان منذ بداية موضوع هذا الموضوع.

أواجه هذه المشكلة أيضًا:

NodeJS: v0.10.24
Socket.io: v0.9.16

قم بالرد على هذه الرسالة الإلكترونية مباشرة أو tHubhttps: //github.com/LearnBoost/socket.io/issues/777#issuecomment -35177466
.

يرجى تجربة master ، لقد ولت هذه المشكلة.

هل سيكون هناك إصدار 0.9.17 يتضمن إصلاحًا لهذه المشكلة؟

fgnass هل يمكنك إعادة إنتاجه بـ 1.0.0-pre ؟

guille تبدو جيدة حتى الآن! سأخبرك إذا حدث مرة أخرى.

مرحبًا guille ، هل هناك أي طريقة يمكن من خلالها تقديم هذا الإصلاح إلى 0.9.16؟ فقط أننا نستخدم node.js / socket.io في بيئة إنتاج راسخة وسأواجه صعوبة في تبرير استخدام إصدارات ما قبل النشر لأي جانب من جوانب نظامنا الأساسي. إذا كان من الممكن إجراء تصحيح لـ 0.9.16 أو ، إذا كان من المقرر إصدار 1.0.0 في المستقبل القريب (جدًا) ، فسيكون هذا أفضل بكثير.

+1 لـ eggysplat

@ aran112000 شكرًا على الحل البديل heartbeat timeout . يعمل بالنسبة لي على الإصدار 0.9.16.

في الواقع لقد وجدت سبب وجود هذه المشكلة. محرج للغاية ، اعتقدت أنني كنت أستخدم v0.9.16 بينما في الواقع كنت أستخدم v0.9.0 الذي يحتوي على هذا الخطأ. تم إصلاحه في الإصدار 0.9.2 بواسطة https://github.com/LearnBoost/socket.io/commit/57a0b2406004e46ec34729392ee289191a4f78e7 و https://github.com/LearnBoost/socket.io/commit/df5f23d3091df3bbf296aeb952609df28

الرجاء التأكد من عدم وجود heartbeat interval أكبر من heartbeat timeout كما كان في الإصدار 0.9.0.

تحرير المنشور حتى يتم إعلام الآخرين:

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

المنشور ذي الصلة موجود هنا بالفعل ولكن من الصعب جدًا العثور عليه.
https://github.com/LearnBoost/socket.io/wiki/Socket.IO-and-firewall-software

أنا من النوع المبتدئ إلى socket.io واستغرق ذلك أكثر من يومين. بعد إرسال / استقبال البيانات ، يقوم العميل بفصل الاتصال وإعادة الاتصال حتى تتغير قيمة socket.id

socket.io:client client close with reason transport close +39s
socket.io:socket closing socket - reason transport close +44s
.
.
.
socket.io:namespace adding socket to nsp / +4.1m
socket.io:socket socket connected - writing packet +1s

أخيرًا ، وجدت أن هناك استثناءً داخل رد الاتصال ، لذا يقوم socket.io بقطع الاتصال وإعادة الاتصال بالنظام بصمت.

socket.on('someEvent', function(){
    var a = null;
    a.b; //You won't be aware of this error, this error is suppressed and won't be shown on console. 
         //Moreover, it disconnects and reconnects
})

انظر أيضا إلى هذا التعليق

لذلك ، فإنه يكتشف الخطأ بصمت ولا يُظهر لي أي شيء على وحدة التحكم. لماذا يمنع الخطأ ويفصل / يعيد الاتصال دون إخطاري؟

1.3.5 لا تزال هناك أخطاء

فعلا؟

نعم ، لا تزال المشكلة موجودة في 1.3.5 ...

لا تزال المشكلة قائمة

نعم ، لا تزال المشكلة تحدث في 1.3.5 ، يرجى الإصلاح

أعتقد أن هذه مشكلة مهلة عميل haproxy كما أشار

لدي نفس المشكلة ، لكنني لا أستخدم haproxy. لا أحد يعرف الإصدار الأخير حيث كان هذا يعمل؟

حسنًا ، أتلقى أيضًا تقارير تفيد بأن المشكلة لم يتم إصلاحها بنسبة 100٪ في نظامنا. الشيء المضحك هو أنه يمكنني إعادة إنتاج المشكلة بشكل موثوق من خلال تعيين "timeout client 1" في haproxy على ثانية واحدة ، وتجربة الخطأ في الواجهة الأمامية.

بدافع من هذا ، قمت بزيادة "العميل المهلة" إلى عدد أكبر واعتقدت أن المشكلة ستختفي ، حيث سيكون لدى socket.io keepalive / heartbeat وقت كافٍ لتحديث الاتصال. من المحتمل أن يكون هذا الافتراض خاطئًا ، وسأبقيكم على اطلاع إذا اكتشفت المزيد من الأشياء.

لقد قمت بنشر هذا في منشور Stackoverflow وقد يؤدي هذا إلى حله بالنسبة للبعض منكم:
"يبدو أن كلا من HackTimer.js و ccapture.js كلاهما يستبدل window.setTimeout بوظيفة مخصصة. يبدو أن HackTimer.js يعمل بشكل جيد إذا تم تنفيذه قبل أي JavaScript آخر. بالنسبة إلى ccapture.js ، قد ترغب في محاولة التأكد من أنه كذلك تشغيل كأول نص برمجي. لذلك ، يستخدم SocketIO أولاً setTimeout الأصلية في متصفحك والتي يتم تفجيرها بعد ذلك بواسطة setTimeout المخصص الذي يكسر أيًا من أجهزة ضبط الوقت قيد التشغيل حاليًا. "

ابحث في الكود الخاص بك عن لمعرفة ما إذا كانت إحدى مكتباتك ستحل محله:

ag 'window.setTimeout\s*='

يمكنك أيضًا اختبار وحدة التحكم الخاصة بك لمعرفة ما إذا تم تعديل setTimeout على الإطلاق:

/native/.test(window.setTimeout) // returns true for the native function and false for a custom one

هل هذا الخطأ لا يزال يخرج؟ قمت بالترقية إلى الإصدار الرئيسي وقطع اتصال أي جهاز محمول في حوالي دقيقتين مع إشعار إغلاق النقل ..

هذا ما جعله يبتعد عن socket.io 1> وأبقاني على socket.io 0.9.17. لكنني الآن أحاول مرة أخرى ، قم بتعيين لعبة ping pong يدويًا على الخادم لإبقائها حية ، والآن قطع الاتصال بعد 19 دقيقة .. الفاصل الزمني كل 35 ثانية ..

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

utan ما هي خطوات التكاثر؟

مرحبًا rauchg ،

شكرا لردك..

1) قم بتثبيت socket.io 1.4.0
2) اضبط تهيئة nginx على الوكيل

                        proxy_set_header Upgrade $http_upgrade;
                proxy_set_header Connection "upgrade";
                proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
                proxy_set_header Host $host;
                proxy_http_version 1.1;
                proxy_pass http://io_nodes;

3) قم بتعيين العميل الخاص بك باستخدام socket.io 1.4.0 / 2015-11-28
4) التوصيل بجهاز محمول ..
5) اترك متصفح الهاتف المحمول متصلاً بالتطبيق الخاص بك ثم اترك هاتفك خاملاً.

ثم سجلات

  engine:polling compressing +0ms
  engine:socket executing batch send callback +1ms
PuTTY  engine intercepting request for path "/socket.io/" +95ms
  engine handling "GET" http request "/socket.io/?EIO=3&transport=polling&t=L8YVUt6&sid=DJNvvkhmCQew_3vGAAAB" +0ms
  engine setting new request for existing client +0ms
  engine:polling setting request +0ms
  engine:socket transport error +6s
  engine:polling closing +2ms
  engine:polling transport writable - closing right away +0ms
  engine:polling writing "�1" +0ms
  socket.io:client client close with reason transport error +0ms
  socket.io:socket closing socket - reason transport error +0ms

يتم قطع الاتصال بعد 3 4 دقائق ..

إذا كنت تستخدم الاقتراع تحصل على سجل الخطأ هذا ؛

 engine:socket executing batch send callback +1ms
PuTTY  engine intercepting request for path "/socket.io/" +106ms
  engine handling "GET" http request "/socket.io/?EIO=3&transport=polling&t=L8YXgi6&sid=skadf3It4qBRi0S0AAAC" +1ms
  engine setting new request for existing client +0ms
  engine:polling setting request +0ms
  engine:socket transport error +3s
  engine:polling closing +0ms
  engine:polling transport writable - closing right away +0ms
  engine:polling writing "�1" +0ms
  socket.io:client client close with reason transport error +1ms
  socket.io:socket closing socket - reason transport error +2ms
  engine intercepting request for path "/socket.io/" +373ms
  engine handling "POST" http request "/socket.io/?EIO=3&transport=polling&t=L8YXhdB&sid=skadf3It4qBRi0S0AAAC" +0ms

لذلك أغلق rauchg ذلك؟

حقًا لا أعتقد أنه يجب عليك ذلك.

أنا لم أفعل.

rauchg ،
فهل هذا سلوك طبيعي لـ socket.io الآن؟ هل تغير شيء ما في بروتوكول WS الذي يؤدي الآن إلى قطع اتصال المستخدمين في الأجهزة المحمولة إذا لم يكونوا مكونًا إضافيًا وكانوا في وضع الخمول؟

أنا أضغط رأسي على الحائط بهذه المشكلة ، فلن يسمح لي بإكمال ترقية .. وإعادة تشكيل الكود الخاص بي بمقبس جديد ...
خادمي Ubuntu 10.10
إصدار Nginx: Nginx / 1.8.0
العقدة v0.10.31 // إذا قمت بالترقية إلى 4.0 هي نفس الشيء ..

باستخدام https و Nginx proxing socket.io ..

هل هناك أي شخص آخر لديه نفس المشاكل أم أنه أنا فقط؟

أعتقد أنني قد أكون كذلك .. من الصعب جدًا تحديد حالتي على الرغم من ذلك. أنا أستخدم sails.js مع socket.io.

أوبونتو 14.04.2018
عقدة v5.3.0
npm v 3.3.12
أشرعة. [email protected]
socket.io@~1.4.3

موكلي هو مزيج من socket.io-client و sails.io.js:

var socketIOClient = require('socket.io-client');
var sailsIOClient = require('sails.io.js');
var io = sailsIOClient(socketIOClient);
io.socket.on('connect', function(data){....})

لذا فإن الاتصال الأولي يستمر إلى الأبد ... ولكن بعد ذلك بعد مرور. . تعتقد أنها لا تزال متصلة.

محبط جدا.

أواجه مشكلة مماثلة ، ولكن فقط إذا استخدمت مقبسًا آمنًا (wss بدلاً من ws). مع ws كل شيء يعمل بشكل جيد ولكن مع wss يتم قطع الاتصال بشكل متقطع في أوقات عشوائية (حوالي 15 دقيقة). لا جدران حماية ، ولا وكلاء.

شكرًا لك @ andrin-n-dream ، أعتقد أن ملكي مرتبط بـ SSL أيضًا. لدي جهاز windows كعميل وجهاز ubuntu vm الخاص بي (نفس الجهاز) كخادم. محول الشبكة الموصّل. لم أواجه أي مشاكل مع اتصال الشبكة العام.

يحدث على SSL بغض النظر عما إذا كنت أستخدم إنهاء SSL لـ nginx أو sails.js.

NAVER - http://www.naver.com/

تم إرسال بريد إلكتروني إلى

لقد حظر المستلم استلام بريدك الإلكتروني.

لقد قمت بتصحيح الأخطاء إلى الأبد ولم أجد حلًا آخر لـ SSL ولكن لإعادة الاتصال يدويًا. سيكون رائعًا إذا قام Engine.io بذلك من أجلي وأعد المحاولة عند إغلاق النقل.

هل هناك حل لهذا؟ أواجه نفس المشكلة بالضبط. بعد بضع ثوانٍ ، أحصل على مهلة نبضات القلب في سجل تصحيح الأخطاء من الخادم ولكن العميل لا يزال يعتقد أنه متصل.

حسنًا ، نظرًا لقضايا ملحة أخرى ، فقد قمت بترقية مستوى حسدتي وهذا الآن في الخلفية. سيكون من الجيد معرفة ما إذا كانت العقدة 6.5.0 تحدث أي فرق. قام Sails.js بتحديث بعض الحزم وغير استخدامه لهذه الوظائف ذات المستوى المنخفض ...

ليس لدي الوقت للغطس في هذا مرة أخرى في الوقت الحالي لأنني أقوم بترحيل قدر هائل من C ++ القديمة. ربما في وقت لاحق من هذا العام أو يناير.

لا يزال هذا يحدث في 2.0.3 ...
https://github.com/socketio/socket.io/issues/3025

بدون حل بديل ، فإن socket.io غير قابل للاستخدام أساسًا لأن 25٪ من عملائك سيواجهون هذه المشكلة.

io.set ("مهلة ضربات القلب" ، 99999) ؛

@ Aaron1011 هل هذا يعني أن يكون رمز من جانب الخادم أو العميل؟ إذا كان جانب الخادم الخاص به ، فهل يلزم تغيير أي شيء من جانب العميل؟

حاول:
io.set ("مهلة ضربات القلب" ، 99999) ؛
على جانب الخادم ولم يتم إصلاح المشكلة باستخدام socket.io v 2.0.3. سأحاول الرجوع إلى 0.8.6 التالي.

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

هل لدى أي شخص أي أفكار / إصلاحات للإصدار 2.03؟ الأشياء التي جربتها:

• اضبط pingInterval على 9999999
• اضبط pingTimeout على 99999999
• إرسال الرسائل تلقائيًا كحفاظ على الحياة. أرسل رسالة كل ثانية ، لكني ما زلت أحصل على قطع الاتصال العشوائي.
• جدار حماية معطل
• تمت المحاولة مع تشغيل / إيقاف تشغيل استطلاع XHR
• تم تغيير المنفذ من شيء عشوائي إلى 80

أنا متأكد من أنه ليس خطأ ترميز ولكنه خاص بجهاز الكمبيوتر كما يحدث في البعض وليس في البعض الآخر. قد يكون لها علاقة بمحول الشبكة.

forhableSun ، يجب أن تكتب تطبيقك بناءً على Primus ، لقد أعدت تصميم تطبيقي باستخدام primus وحاليًا أستخدم socketJs معه ..

دعم بعض المشاريع الأخرى لا حاجة لتغيير الكود في أخرى لاستخدام أي مشروع آخر في الوقت الحقيقي ..

يعتبر.

utan أحب أن

npm تثبيت المتصفح - حفظ

var primus = new Primus (الخادم ، {محول: 'Browserchannel'}) ؛

https://github.com/primus/primus/blob/master/README.md#supported -real-time-framework

الأمل يساعد.

ما علاقة قناة المتصفح بـ socket.io؟

هذا مجرد مثال على كيفية التبديل إلى إطار عمل مختلف ..

كما طلبت مثالا ..

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

استمع ، socket.io عبارة عن عربات التي تجرها الدواب بعد> = 1 بها قطع اتصال غريبة ، أقترح استخدام primus حتى تتمكن من التبديل إلى إطار عمل مختلف ..

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

يعتبر

utan أرى ، كنت أفكر أنه كان محولًا للتبديل من إطار واحد إلى آخر مع كتابة التطبيق بالكامل في هذا الإطار (مثل المحول). لكن في الحقيقة ، إنه محول للتبديل بسلاسة إلى أطر العمل مع التطبيق بأكمله مكتوب في primus.

في الواقع ، لقد صعدت رأسي .. أنا لست بارعًا في معرفة الفرق ، اعتقدت أننا نتحدث عن نفس الشيء ..

يعتبر.

سجلات خادمي:
قطع اتصال العميل. سبب قطع الاتصال: "إغلاق النقل"
قطع اتصال العميل. سبب قطع الاتصال: "إغلاق النقل"
قطع اتصال العميل. سبب قطع الاتصال: "إغلاق النقل"
قطع اتصال العميل. سبب قطع الاتصال: "إغلاق النقل"
قطع اتصال العميل. سبب قطع الاتصال: "إغلاق النقل"
قطع اتصال العميل. سبب قطع الاتصال: "إغلاق النقل"
قطع اتصال العميل. سبب قطع الاتصال: "إغلاق النقل"
قطع اتصال العميل. سبب قطع الاتصال: "إغلاق النقل"
قطع اتصال العميل. سبب قطع الاتصال: "إغلاق النقل"
قطع اتصال العميل. سبب قطع الاتصال: "إغلاق النقل"
قطع اتصال العميل. سبب قطع الاتصال: "إغلاق النقل"
قطع اتصال العميل. سبب قطع الاتصال: "إغلاق النقل"
قطع اتصال العميل. سبب قطع الاتصال: "إغلاق النقل"
قطع اتصال العميل. سبب قطع الاتصال: "إغلاق النقل"
قطع اتصال العميل. سبب قطع الاتصال: "إغلاق النقل"
قطع اتصال العميل. سبب قطع الاتصال: "إغلاق النقل"
قطع اتصال العميل. سبب قطع الاتصال: "إغلاق النقل"
قطع اتصال العميل. سبب قطع الاتصال: "إغلاق النقل"
قطع اتصال العميل. سبب قطع الاتصال: "إغلاق النقل"
قطع اتصال العميل. سبب قطع الاتصال: "إغلاق النقل"
قطع اتصال العميل. سبب قطع الاتصال: "إغلاق النقل"
قطع اتصال العميل. سبب قطع الاتصال: "إغلاق النقل"
قطع اتصال العميل. سبب قطع الاتصال: "إغلاق النقل"
قطع اتصال العميل. سبب قطع الاتصال: "إغلاق النقل"
قطع اتصال العميل. سبب قطع الاتصال: "إغلاق النقل"
قطع اتصال العميل. سبب قطع الاتصال: "إغلاق النقل"
قطع اتصال العميل. سبب قطع الاتصال: "إغلاق النقل"
قطع اتصال العميل. سبب قطع الاتصال: "إغلاق النقل"
قطع اتصال العميل. سبب قطع الاتصال: "إغلاق النقل"
قطع اتصال العميل. سبب قطع الاتصال: "إغلاق النقل"

تم التبديل إلى ws (https://github.com/websockets/ws) والتي تضمنت عمليات إعادة كتابة ضخمة ، لكنني الآن أستخدم كائن متصفح websocket الأصلي على جانب العميل ويعمل كل شيء بشكل مثالي. لم يعد لدي مشكلة. socket.io طويل جدا!

كنت أحصل على قطع اتصال عشوائي بعد 10 إلى 30 دقيقة. تذكرت أن خدمة الاستضافة الخاصة بي تقوم بتشغيل NodeJS مع Passenger على خادم Apache المشترك. أنا لا أفهم ذلك حقًا ولكن من المفترض أن تكون هناك مشكلات في مآخذ الويب في هذا النوع من التكامل. أنا أختبر باستخدام إعدادات النقل: ["الاقتراع"] فقط ، بينما أجري على المضيف المحلي مع وسائل النقل: ['websockets' ، 'الاقتراع'] بدون أخطاء أو تسرب. حتى الآن جيد جدًا بعد 30 دقيقة ...