الاستطلاع الطويل والتطور نحو البث
افهم الاستطلاع الطويل كتقنية جسر بين HTTP التقليدي ووسائط نقل البيانات الحديثة المباشرة، ومتى يظل مهمًا، وكيف يقارن بـ WebSockets وSSE.
الاستطلاع الطويل والتطور نحو البث درس مجاني في Real-Time Streaming Systems (WebRTC + Live Data) على CoddyKit. هذا هو الدرس 4 من أصل 4. يمكنك قراءة الدرس كاملاً أدناه مجاناً — ثم تمرن عليه مباشرة في المتصفح باستخدام محرر أكواد مدمج ومدرس ذكاء اصطناعي متاح 24/7. هذا الدرس جزء من مسار التعلم في Real-Time Streaming Systems (WebRTC + Live Data)، وتقدمك يتزامن عبر الويب وتطبيق CoddyKit. تتضمن دورة Real-Time Streaming Systems (WebRTC + Live Data) 4 دروس في المجموع.
بعض أجزاء هذا الدرس لم تُترجم بعد وتظهر باللغة الإنجليزية.
Why Long Polling Exists
Before WebSockets and SSE were widely supported, developers needed a way to push data to clients over plain HTTP. Long polling filled that gap.
With long polling, the client makes a request and the server holds it open until new data is available, instead of replying immediately.
Short Polling vs Long Polling
Short polling hammers the server on a fixed interval, wasting requests when nothing changed.
- Short polling: request, immediate empty reply, wait, repeat.
- Long polling: request, server waits, replies only when data arrives.
Long polling cuts the volume of empty responses dramatically.
The Long Polling Cycle
The lifecycle is a loop:
- Client sends a request.
- Server holds it open (often with a timeout).
- When an event occurs, the server responds.
- Client processes data and immediately reconnects.
A Simple Client Loop
A long polling client recursively re-issues the request after each response. This keeps a near-continuous channel open.
async function poll() {
try {
const res = await fetch('/api/updates');
const data = await res.json();
handle(data);
} catch (e) {
console.error(e);
}
poll();
}
poll();Server Side: Holding the Request
On the server, you avoid replying until an event fires or a timeout is reached. This often uses an event emitter or a pending-promise registry.
app.get('/api/updates', (req, res) => {
const onEvent = (data) => {
res.json(data);
emitter.off('update', onEvent);
};
emitter.on('update', onEvent);
setTimeout(() => {
emitter.off('update', onEvent);
res.status(204).end();
}, 30000);
});Timeouts Matter
Never hold a request forever. Proxies, load balancers, and mobile networks will silently drop idle connections.
Use a server-side timeout (for example 30s) that returns an empty 204, prompting the client to reconnect cleanly.
Handling Reconnection Gaps
Between a response and the next request there is a tiny window where events could be missed. Use a cursor or last-seen ID so the server can replay anything that happened during the gap.
GET /api/updates?since=10427Long Polling vs WebSockets
- WebSockets: one persistent, bidirectional connection. Lowest latency.
- Long polling: repeated HTTP requests. Higher overhead but works everywhere HTTP works.
WebSockets win for chat and games; long polling wins for hostile network environments and legacy proxies.
Long Polling vs SSE
SSE keeps one connection open and streams many events down it. Long polling reopens a connection per event.
SSE is generally more efficient for unidirectional push, but long polling has broader compatibility and simpler proxy behavior.
Where Long Polling Still Wins
- Corporate networks that block WebSocket upgrades.
- Old proxies that buffer streaming responses.
- Serverless platforms with short execution limits, used as a fallback.
Many libraries (Socket.IO included) fall back to long polling automatically.
Scaling Considerations
Each held request consumes a server slot. With thousands of clients you need non-blocking I/O (Node, Go, async Python) so held requests do not exhaust threads.
Sticky sessions or a shared pub/sub layer (Redis) let multiple servers coordinate events.
Quick Check
Test your understanding of long polling.
Recap
Long polling holds an HTTP request open until data is ready, then the client reconnects. It bridges classic HTTP and true streaming.
- More efficient than short polling.
- Less efficient than WebSockets/SSE, but more compatible.
- Use timeouts and a cursor to stay reliable.
الأسئلة الشائعة
هل درس «الاستطلاع الطويل والتطور نحو البث» مجاني؟
نعم — نص درس «الاستطلاع الطويل والتطور نحو البث» كامل متاح مجاناً هنا على الويب. لتمرينه بشكل تفاعلي (محرر أكواد مدمج ومدرس ذكاء اصطناعي متاح 24/7) وفتح باقي دورة Real-Time Streaming Systems (WebRTC + Live Data)، انتقل إلى CoddyKit PRO. تتضمن دورة Real-Time Streaming Systems (WebRTC + Live Data) 4 دروس في المجموع.
ماذا ستتعلم في «الاستطلاع الطويل والتطور نحو البث»؟
افهم الاستطلاع الطويل كتقنية جسر بين HTTP التقليدي ووسائط نقل البيانات الحديثة المباشرة، ومتى يظل مهمًا، وكيف يقارن بـ WebSockets وSSE. تتمرن على Real-Time Streaming Systems (WebRTC + Live Data) مع أكواد عملية تشغلها مباشرة في المتصفح، ومدرس ذكاء اصطناعي متاح 24/7 يجيب على أسئلتك أثناء عملك.
هل أحتاج إلى خبرة سابقة لأبدأ Real-Time Streaming Systems (WebRTC + Live Data)؟
لا تُشترط خبرة سابقة. Real-Time Streaming Systems (WebRTC + Live Data) على CoddyKit منظم للمبتدئين حتى المتقدمين، لذا يمكنك البدء من هنا أو من البداية والتقدم بسرعتك الخاصة. هذا هو الدرس 4 من أصل 4.
كم من الوقت يستغرق درس «الاستطلاع الطويل والتطور نحو البث»؟
معظم دروس CoddyKit تستغرق حوالي 5–10 دقائق. كل منها موجز وتفاعلي، لذا تحرز تقدماً مستمراً وتستأنف من حيث توقفت عبر الويب والتطبيق.
هل يمكنني كتابة وتشغيل أكواد في درس Real-Time Streaming Systems (WebRTC + Live Data) هذا؟
نعم. كل درس في Real-Time Streaming Systems (WebRTC + Live Data) يتضمن محرر أكواد مدمج، لذا تكتب وتشغل أكواداً حقيقية مباشرة في متصفحك وتحصل على تعليقات فورية من الذكاء الاصطناعي — بدون إعداد محلي.
جميع الدروس في هذه الدورة
- البيانات الفورية مقابل HTTP التقليدي
- WebSockets للتدفق ثنائي الاتجاه
- الأحداث المرسلة من الخادم (SSE) للدفع أحادي الاتجاه
- الاستطلاع الطويل والتطور نحو البث