دخلت شبكة الغيغابت القاعة، وبقي التطبيق ينتظر

الخلاصة

• يسجل RFC 1152، المنشور في أبريل 1990، نقاشات ورشة عن الشبكات فائقة السرعة. رأى David Clark أن البروتوكولات القائمة قادرة على بلوغ غيغابت في الثانية إذا كان ذلك هو الشرط الوحيد؛ المسافات والمستخدمون والخدمات الجديدة كانت تضيف أسئلة أخرى.
• وضع Keith Lantz التأخير المنخفض وتزامن الوسائط في قلب التطبيق. وناقش Craig Partridge تكلفة انتظار الاستدعاء البعيد. وقدمت نتائج Nectar الأولية مثالاً على أن سرعة بطاقات الاتصال لا تنتقل كاملة إلى البرامج التي تعمل على الحاسوب المضيف.

أي خدمة تنتظر عند الطرف الآخر؟

رعى الورشة Internet Research Steering Group، وهو ضمن بنية عمل IRTF. جمع Craig Partridge تقريرها من ملاحظات رؤساء الجلسات بعد مراجعتها مع المشاركين. يحتفظ التقرير باختلاف الآراء؛ فقد كان السؤال عن وظيفة الشبكة السريعة لا عن رقم واحد يوافق عليه الجميع.

في جلسة تنفيذ البروتوكولات، قال David Clark إن الوصول إلى غيغابت في الثانية بالبروتوكولات المعروفة ممكن إن كانت السرعة وحدها المطلوب. لكن المقترحات كانت تريد عبور مسافات طويلة وخدمة أعداد كبيرة ودعم خدمات مثل حجز السعة. لذلك يبدأ تقييم التصميم بتحديد المتطلبات. ناقش آخرون معالجات مخصصة للبروتوكولات وتحسين تنفيذها القائم. لا تكفي كتابة «أسرع» على الغلاف لاختيار أي طريق من هذه الطرق.

انتقل Keith Lantz إلى المكتب الذي سيستخدم الشبكة. تصور «مكتباً قابلاً للحمل» بمعنى بقاء الوصول إلى الأشخاص والخدمات نفسها من المنزل أو مقر العمل أو مكان بعيد. المقصود انتقال القدرة على العمل، لا تخفيف وزن الجهاز فقط. وفي مؤتمر فيديو مكتبي تتدفق النصوص والرسوم والصوت والصورة معاً. تتفاوت احتياجاتها من السعة كثيراً، لكنها تحتاج عموماً إلى تأخير قليل؛ وبعضها يحتاج انتظاماً في وصول الحزم، وجميعها تحتاج التزامن. قد تصل الصورة بسرعة مدهشة وتصل الجملة بعدها كضيف تأخر عن الحفل.

دعا Lantz أيضاً إلى التكيف عندما تضيق السعة أو تمر الجلسة عبر شبكة أبطأ. تغيير دقة الفيديو قد يبقي التعاون ممكناً. تجربة المستخدم لا تجري على أفضل جزء من الطريق فقط؛ الخدمة تعبر الأجزاء كلها.

ينتظر المعالج جواباً لا يستطيع الضوء استعجاله

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

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

ظهر حد آخر عند مدخل الحاسوب نفسه. أورد التقرير نتائج أولية لشبكة Nectar في Carnegie Mellon: عمليات على بطاقات الاتصال تبادلت البيانات بسرعة 70 Mbps، فيما بلغت عمليات الحواسيب المضيفة نحو 25 Mbps بسبب واجهة VME. تصف الأرقام ذلك النموذج التجريبي تحديداً. وأضاف Jeff Mogul احتمال أن تصبح كلفة نقل الحزم إلى ذاكرة المعالج وتنبيه البرنامج أكبر من كلفة بعض عمل البروتوكول. وصول البيانات إلى الجهاز ليس آخر خطوة في الرحلة.

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