كيفية تنفيذ RFC 3393 (تغير تأخير حزمة Ipdv) في لغة C؟

Question

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

Answer 1

RFC 3393 مخصص لقياس التباين في تأخير الحزمة، وليس لقياس التأخير نفسه.

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

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

خذ الطرف الآخر:في معظم الأحيان، تصل البيانات خلال 20 مللي ثانية.إلا في بعض الأحيان، عندما يستغرق الأمر 5000 مللي ثانية.إذا لم تحتفظ بأي مخزن مؤقت وكان التأخير في الإطارات من 1 إلى 50 يبلغ 20 مللي ثانية، فستتمكن من تشغيل أول 50 إطارًا دون مشكلة.ثم يستغرق الإطار 51 5000 مللي ثانية للوصول ويبقى بدون أي بيانات فيديو لمدة 5000 مللي ثانية.يذهب المستخدم ويزور موقعًا آخر لمشاهدة مقاطع الفيديو الخاصة بالقطط اللطيفة.ما كنت تحتاجه حقًا هو مخزن مؤقت يبلغ 5000 مللي ثانية من البيانات - حينها ستكون بخير.

مثال طويل، نقطة قصيرة:أنت لست مهتما بما مطلق التأخير في الحزم هو أنك مهتم بما التباين في هذا التأخير - هذا هو حجم المخزن المؤقت الخاص بك.

لقياس مطلق تأخير، يجب أن تتم مزامنة الساعات على كلا الجهازين.سيرسل الجهاز "أ" حزمة بالطابع الزمني 12337849227 28 وعندما وصل ذلك إلى الجهاز B في الوقت 12337849227 48, ، كنت تعلم أن الحزمة استغرقت 20 مللي ثانية للوصول إلى هناك.

ولكن بما أنك مهتم بـ التباين, ، فأنت بحاجة (كما يصف RFC 3393) إلى عدة حزم من الجهاز أ.يرسل الجهاز "أ" الحزمة 1 ذات الطابع الزمني 1233784922 72 8، ثم يرسل بعد 10 مللي ثانية الحزمة 2 بالطابع الزمني 1233784922 73 8، ثم يرسل بعد 10 مللي ثانية الحزمة 3 بالطابع الزمني 1233784922 74 8.

يتلقى الجهاز B الحزمة 1 في ما يعتقد أنه الطابع الزمني 1233784922 12 8.كان التأخير في اتجاه واحد بين الجهاز A والجهاز B في هذه الحالة (من منظور الجهاز B) هو -600 مللي ثانية.من الواضح أن هذا هراء كامل، لكننا لا نهتم.يتلقى الجهاز B الحزمة 2 في ما يعتقد أنه الطابع الزمني 1233784922 15 8.كان التأخير في اتجاه واحد -580 مللي ثانية.يتلقى الجهاز B الحزمة 3 في ما يعتقد أنه الطابع الزمني 1233784922 16 8.كان التأخير في اتجاه واحد مرة أخرى -580 مللي ثانية.

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

لاحظ أنني أتجاهل تمامًا مسألة انحراف الساعة هنا (أي أن الساعات الموجودة على الجهازين A وB تعمل بمعدلات مختلفة قليلًا، بحيث يتقدم وقت الجهاز A على سبيل المثال بمعدل 1.00001 ثانية لكل ثانية وهذا في الواقع اجتاز).في حين أن هذا لا يؤدي إلى عدم الدقة في القياسات، إلا أن تأثيره العملي ليس من المرجح أن يكون مشكلة في معظم التطبيقات.