يبدو اني ازعجتك بكثرة اسئلتي اليوم
اعذرني :)
ببساطة لا، ولا فرق بين الـWebSocket وSSE الإثنان في النهاية socket على طبقة TCP الفرق أنّ الـSSE على بروتوكول HTTP يوفر تواصل من جهة واحدة، WebSocket صُممَ لحل هذه المشكلة للويب بدون إتاحة إنشاء Socket خام على بيئة المتصفح.
عمومًا إرسال الرسائل وفتح الـSocket لا يسبب أي ضغط، المشكلة في عملية التحديث وكيف ستجلبه، PHP كلاسيكيًا لأنها لغة صممت لتصنع صفحات الوِب -لا تحمّلها أكثر من هذا- يكون كل طلب منفصل لا يوجد طريقة واضحة للتواصل بين طلب وآخر، ولا يتاح إنشاء Socket مباشر في أغلب الاستضافات وبيئات PHP، لهذا NodeJS مثلًا أفضل في هذه الحالات لأنه وببساطة يكون هنالك طريقة مباشرة للتواصل بين العمليات بما أنها في تطبيق واحد والمتصنت بداخل التطبيق، PHP -أظنك تستخدمها الآن- يكون كل طلب في Thread مختلف ومنفصل تمامًا -هذا هو الشائع باستثناء أي Hack- فلا يوجد طريقة مثلًا لمعرفة متى يرسل الفلاني رسالة، ثم تحديثها إلى المستخدم العلاني، الضغط يبدأ من ما يحدث داخل عملية التحديث، كيف ستجلب التحديثات هل ستجلبها من قاعدة البيانات؟ طلبات متعددة مستمرة من مئة مستخدم على قاعدة البيانات للتحديث؟ فكرة استخدام SSE مع PHP على خادوم Apache لعمل شات مثلًا سيئة.
إذا كنت مصرًا على استخدام PHP: يمكنك مثلًا صناعة متصنت باستخادم PHP Socket وصناعة تطبيق(implementation) لبرتوكول HTTP أو البحث عن واحد جاهز، مع استخدام Pthreads إذا كنت تريد حل لمشكلة الضغط على الخادوم بدون استخدام لغة غير PHP.
مشكور
هذه في حالة صفحات الويب
لكن انا استعمله في التطبيقات الهجينة (cordova/ionic )
استعمله في الشات وتلقي الاشعارات ؟
هل تراها فكرة سديدة او يوجد بديل؟
ليست المشكلة من أين يطلب (من صفحة وب، تطبيق هجين، حبّة بطاطا ..) ، ألن يكون الخادم على خادوم Nginx/Apache وكل طلب منفصل؟ عمومًا أنا كبرتُ من الأمر قليلًا -ربما كثيرًا :)- لن تلحظ الفرق بشكل كبير إلا عندما يكبر عدد المستخدمين لديك حينها ستكون تملك الامكانيات للتطوير، اِبدء به لا مشكلة، حاول بقدر الإمكان التقليل من العمليات بداخل Loop التحديث وتذكر انها تتكرر بعدد المستخدمين*وقت إعادة الدورة.
التعليقات