الجزء LLTR 0: الكشف التلقائي عن مخطط الشبكة والتبديل غير المُدار. مهمة مستحيلة؟

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

سأبدأ بقضية LLTR ( كشف طبولوجيا طبقة الارتباط ).

كان لديّ "دراجة" واحدة - مزامن ملفات كبير "بسرعة الشبكة الكاملة" ، قادر على تحميل ملف 120 جيجا بايت بالكامل عبر Fast Ethernet ( 100 ميجابت في الثانية ؛ 100BASE - TX ؛ مزدوج) إلى 1 أو 10 أو 30 أو 3 ساعات > 200 جهاز كمبيوتر شخصى . لقد كانت "دراجة" مفيدة للغاية لأنها كانت سرعة مزامنة الملف مستقلة تقريبًا عن عدد أجهزة الكمبيوتر التي يتم تحميل الملف عليها. سيكون كل شيء على ما يرام ، ولكنه يتطلب معرفة طوبولوجيا الشبكة لعملها.

يمكنك الاستمرار في السلسلة أكثر ، ولكن على هذا سأكسر.

تتطلب بروتوكولات اكتشاف طبولوجيا طبقة ارتباط البيانات الحالية ( LLDP ، LLTD ، CDP ، ...) دعمًا مناسبًا من جميع عقد الشبكة المتوسطة لتشغيلها. أي أنها تتطلب مفاتيح تبديل مُدارة على الأقل تدعم البروتوكول المناسب. كان هناك بالفعل مقال عن حبري حول كيفية استخدام هذه البروتوكولات " لتحديد طوبولوجيا الشبكة عند مستويات 2/3 من نموذج OSI ".

ولكن ماذا لو كانت العقد المتوسطة مفاتيح بسيطة غير مُدارة؟

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

{حجم الصورة: 924 كيلوبايت ؛ النص: 69 كيلوبايت ؛ الرموز: 9 قطع. }}

@charset "utf-8"; body { font-family: Verdana,sans-serif !important; } .nav-links__item-link { font-family: Helvetica,Arial,sans-serif !important; } .comment__message, .comment-form__preview { font-family:Arial !important; } .post__text { font-size:13px !important; line-height:1.60 !important; } .post__title-text, .post__title_link { font-family: Tahoma,sans-serif !important; line-height:118% !important; } .post__title-text { font-size:30px !important; } .post__title_link { font-size:26px !important; } /* .post__text-html p > br:first-child, .post__text p+br { display:none !important; } .post__text p { margin-bottom: 0.9em; margin-top: 0.9em; } /* for test: https://habr.com/post/315186 :（ */ .post__text br { line-height:normal !important; } /* or 1 ; https://habr.com/company/pt/blog/337450 */ .post__text img { -o-object-fit:contain; object-fit:scale-down; } /* https://stackoverflow.com/questions/787839/resize-image-proportionally-with-css and don't use "height:auto; width:auto;" (example: <img src="img32x32_2x.png" width="16" height="16">)*/ .post__text h1, .post__text h2, .post__text h3 { font-family: Helvetica,Arial,sans-serif !important; } .post__text h2 { font-size:1.5em !important; } .post__text h3 { font-size:1.375em !important; } .post__text h4, .post__text h5, .post__text h6 { font-family: Verdana,sans-serif !important; font-size:1.125em !important; font-weight:bold !important; } .post__text h5 { color:#3D3D3D !important; } .post__text h6 { color:#5C5C5C !important; } .post__text ul li, .post__text ul ul li, .post__text ul ol li, .post__text ol li, .post__text ol ul li, .post__text ol ol li { line-height:inherit !important; padding:0 !important; } .post__text ul, .post__text ul ul, .post__text ul ol, .post__text ol, .post__text ol ul, .post__text ol ol { margin-left:35px !important; } .post__text ul ul, .post__text ul ol, .post__text ol ul, .post__text ol ol { margin-bottom:9px !important; } .post__text .spoiler .spoiler_title { color:#6DA3BD !important; font-size:inherit !important; font-weight:400 !important; } .post__text .spoiler::before { margin-top:2px !important; } .post__text .spoiler .spoiler_text { color:#666 !important; background:#F9F9F9 !important; border:1px solid #EEE !important; } .post__text .spoiler .spoiler_text hr:first-child, .post__text .spoiler .spoiler_text hr:last-child { display:none !important; } .post__text code { font-size:13px !important; /*background-color:#F8F8F8 !important;*/ border:1px solid #F2F2F2 !important; border-radius:3px !important; padding:0 0.25em !important; white-space:pre-wrap !important; } .post__text strong > code { font-weight: normal !important; background-color: #F8F8F8 !important; } .post__text pre code { line-height:1.5 !important; background-color:#F8F8F8 !important; border-color:#DDD !important; padding:0.5em 1em !important; white-space:pre !important; overflow-x:auto !important; } .hljs-comment, .hljs-quote { color:#808080 !important; font-style:inherit !important; } .hljs-doctag,.hljs-keyword,.hljs-formula, .hljs-section,.hljs-name,.hljs-selector-tag,.hljs-deletion,.hljs-subst { color:#4d7386 !important; } .hljs-literal{ color:#7296a3 !important; } .hljs-string,.hljs-regexp,.hljs-addition,.hljs-meta-string{ color:#390 !important; } .hljs-built_in,.hljs-class .hljs-title{ color:#968e5b !important; } .hljs-attr,.hljs-attribute,.hljs-variable,.hljs-template-variable,.hljs-type,.hljs-selector-class,.hljs-selector-attr,.hljs-selector-pseudo,.hljs-number{ color:#2f98ff !important; } .hljs-symbol,.hljs-bullet,.hljs-link,.hljs-meta,.hljs-selector-id,.hljs-title{ color:#968e5b !important; } .post__text kbd { display:inline-block !important; padding:0.2em 0.5em 0.3em !important; vertical-align:middle !important; background-color:#FCFCFB !important; border:1px solid #D9D9D9 !important; border-radius:3px !important; border-bottom-color:#C6CBD1 !important; box-shadow:inset 0px -1px 0px #C6CBD1 !important; font:11px/10px Tahoma, sans-serif !important; color:#575757 !important; text-shadow:0px 1px 0px #FFF !important; } .post__text blockquote, .comment__message blockquote, .comment-form__preview blockquote { background:inherit !important; border-left:0.25em solid #DFE2E5 !important; color:#70767D !important; padding:0 1em !important; } .post__text .user_link { display:inline-block !important; padding-left:14px !important; color:#666 !important; font:92.4%/1.5em Arial !important; background:url("https://hsto.org/storage/habrastock/i/bg-user2.gif") 0px 60% no-repeat !important; } .post__text .user_link::before { content:'@' !important; color:transparent !important; position:absolute !important; left:0 !important; }/*for copy-paste (for Opera Presto)*/ .voting-wjt_post>.voting-wjt__counter, .post-stats__item_views { display:none !important; } 

 // ==UserScript== // @version    1.0.0 // @namespace  https://habr.com/users/ZiroKyl/ // @homepageURL https://habr.com/post/414799/ // @name       Anti-quotes-hell for Habr // @include    https://habr.com/post/* // @include    https://habr.com/company/*/blog/* // ==/UserScript== // Enable opera:config#UserPrefs|UserJavaScriptonHTTPS if(self == top){   window.opera.addEventListener("BeforeEvent.DOMContentLoaded", function(){ "use strict";       var code = document.querySelectorAll(".post__text :not(pre) > code");       var unQuote = function(el){           var aN = null, a = "",              bN = null, b = "";           if((aN = el.previousSibling) && (bN = el.nextSibling) &&              aN.nodeType == 3        && bN.nodeType == 3    ){               a = aN.data; a = a.charCodeAt(a.length-1);               b = bN.data; b = b.charCodeAt(0);               // a != " " && ( a+1 == b && (a == "“" || a == "'" ) || (a == "«" && b == "»") || a == b && (a == "'" || a == "`" || a == '"') )               if(a != 32 && ( a+1 == b && (a == 8220 || a == 8216) || (a == 171 && b == 187) || a == b && (a == 39 || a == 96 || a == 34 ) )){                   aN.data = aN.data.slice(0,-1);                   bN.data = bN.data.slice(1);                   return true;               }           }           return false;       };       var aN = null, bN = null, pElTagName = "";       for(var i=code.length;i--;){           // “<code>...</code>” -> <code>...</code>           if(!unQuote(code[i])                                                                 &&               ( code[i].previousElementSibling == null && code[i].nextElementSibling == null &&                (pElTagName = code[i].parentElement.tagName)                                &&                (pElTagName == "A" || pElTagName == "STRONG")                                ) &&               ( (!(aN = code[i].previousSibling) || aN.data.trim().length == 0) &&                (!(bN = code[i].nextSibling)    || bN.data.trim().length == 0) )             ){               // “<a><code>...</code></a>”    -> <a><code>...</code></a>               // “<a> <code>...</code> </a>”  -> <a> <code>...</code> </a>               // “<a><code>...</code>...</a>” -X               unQuote(code[i].parentElement);           }       }   }, false); } 

حول LLTR ، سأقوم بكتابة سلسلة من المقالات بموضوع عام "كيفية إنشاء بروتوكول". هذه المقالة صفر.

# تشبيه من العالم المادي - النقل الهوائي

تخيل أن لدينا أنبوبين هوائيين ...

أنبوب واحد للطرود الواردة (حاويات حمراء) وأخرى للطرود الصادرة (حاويات زرقاء).

لدينا العديد من الأصدقاء المتصلين بنفس نظام النقل الهوائي. يمكننا إرسال حاويات إليهم ، ويمكنهم إرسال حاويات إلينا. يتم وضع علامة على عنوان تسليم الحاوية على الحاوية نفسها (على سبيل المثال ، في RFID أو الرمز الشريطي).

في مرحلة ما ، أراد الجميع معرفة المسار الذي تسير فيه عبواتهم كل يوم ، ومعرفة أي مفاتيح (مراكز تبديل) متصلة بأنابيبهم الهوائية ، أي تعرف على هيكل الشبكة الهوائية.

كل ما يمكننا القيام به نحن وأصدقاؤنا هو إرسال واستقبال حاويات بمحتوى معين.

أقترح التفكير في كيفية بناء طوبولوجيا هذه الشبكة في هذه الحالة. توجد عدة خيارات تحت المفسد:

# LLTR Basic

بالعودة إلى شبكات إيثرنت السلكية ، دعني أذكرك بالمشكلة التي تم إنشاء LLTR بها. يتم وصف المشكلة بالتفصيل في قسم "أجهزة الكمبيوتر المتصلة بمفاتيح التحويل المختلفة" في مقالة RingSync - هذه مشكلة تقليل السرعة إذا لم يتم بناء سلسلة الأقران بشكل صحيح في شبكة تحتوي على العديد من المفاتيح. لبناء سلسلة نظير بشكل صحيح ، تحتاج إلى معلومات حول هيكل الشبكة.

مثال صغير (لا مشكلة):

لدينا مفتاحان (متصلان بواسطة "سلك") ، و 4 مضيفين (أقران) ، وجميع الاتصالات مزدوجة ، وسرعة جميع الاتصالات هي نفسها. تُظهر الأسهم مسار البيانات. في هذه الحالة ، لا توجد مشكلة - يتم إرسال البيانات بأقصى سرعة للشبكة.

مثال آخر (هناك مشكلة):

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

في هذه الحالة ، يكمن حل المشكلة (تحديد هيكل الشبكة) في سبب الحاجة إلى حلها - في تشكيل "عنق الزجاجة". سلسلة المشاكل بأكملها هي كما يلي: تحتاج إلى التخلص من "الاختناقات" → تحتاج إلى بناء سلسلة "صحيحة" → تحتاج إلى تحديد هيكل الشبكة. بالمناسبة ، لن نمر بكل المجموعات الممكنة من السلسلة ، بحثًا عن سلسلة بدون "اختناقات" - إنها طويلة جدًا ، وبدلاً من ذلك سنقوم بذكاء / أصعب:

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

أصبح الاتصال بين المفتاحين "عنق الزجاجة" ، وسمح بتحديد جميع المضيفين المتصلين بالمفتاح الأيمن في مجموعة منفصلة.

ملاحظة : في الحالات العادية ، من المعتاد محاربة البث بكل قوتنا ، خاصة تلك التي "تستخدم كل عرض النطاق الترددي" ، لكننا نتعامل مع شبكة تبديل غير مُدارة قد تكون عانت أكثر من مرة من عاصفة / فيضان إذاعي ، ومرة ​​واحدة على الأقل تريد الحياة أن يستفيد مثل هذا البث. بالمناسبة ، من الممكن تمامًا استبدال البث ببث أحادي ، ولن يستغرق سوى هذا المسح وقتًا أطول. بالنسبة للنقل الهوائي ، سيتعين عليك أيضًا استخدام البث الأحادي حتى تفكك عن التثبيت الذي يستنسخ الأمر ويثبته في كل مركز تحويل : فاز.

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

يمكن حساب عدد المجموعات التي يجب التحقق منها باستخدام الصيغة n × (n - 1) {كل (n) بحاجة إلى "التحية" لجميع الآخرين (n - 1) ، حتى لو كانوا قد استقبلوه سابقًا} ، حيث n هو الرقم جميع المضيفين ناقص واحد (مضيف البث).

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

بالمناسبة ، يتكون الحد الأدنى لتكوين الشبكة الذي يجب فحصه من مفتاحين ، لكل منهما مضيفان متصلان. بالنسبة لسرعة البث والبث الأحادي ، يمكن الاحتفاظ بحركة البث في نطاق 75٪ - 100٪ من " معدل البيانات الصافي " (معدل البت الصافي ؛ البحث على "Ethernet 100Base-TX") ، و أحادي الإرسال في نطاق 80٪ - 100٪ .

# LLTR متقدم

_طارت ^{الأجسام الغريبة وتركت} _هذه ^الفجوة _هنا ؟ يذكر إحدى صور اختبار الذكاء

كما هو مكتوب أعلاه ، عند استخدام LLTR Basic ، نحتاج إلى مسح الشبكة n × (n - 1) مرات ، مما يقودنا إلى O (n ² ). بالنسبة لعدد قليل من المضيفين ، هذه ليست مشكلة:

• 4 مضيفين ، ن = 3 ⇒ 6 مسح ؛
• 30 مضيفًا ، n = 29 ⇒ 812 بالاشعة.

ولكن إذا كان لدينا 200 مضيف ، ن = 199 ⇒ 39،402 بالاشعة. أسوأ من ذلك ...

دعونا نرى كيف يمكننا تحسين الوضع. Groknom خياران بسيطان لطوبولوجيا الشجرة:

• نجم من المفاتيح.
• الاتصال التسلسلي للمفاتيح.

# طوبولوجيا: "نجمة من المفاتيح"

أدناه ، يتم شرح الإجراء الموضح في هذه الصورة خطوة بخطوة.

لدينا 5 مفاتيح و 12 مضيفًا. تتم الإشارة إلى المضيفين بواسطة الدوائر [●] داخل المفتاح الذي يتصلون به. مفتاح أسود بالكامل هو مفتاح "الجذر".

نختار أحد المضيفين لدور مصدر حركة البث (يظهر في الرسم البياني على شكل دائرة [○]).

إذا كنت تستخدم LLTR Basic ، فبالنسبة لـ 12 مضيفًا ، n = 11 ⇒ ستحتاج إلى 110 عملية مسح (تكرار).

التكرار 1 . اختر أحد المضيفين (المشار إليه باللون الأزرق ) كمصدر (src) لحركة مرور أحادية الإرسال ومضيف واحد (يشار إليه باللون الأزرق ● ) كمستلم لحركة مرور أحادية الإرسال (dst). لنبدأ ، في فترة زمنية معينة ، في مسح الإحصاءات وجمعها.

أظهرت الإحصائيات التي تم جمعها انخفاضًا في سرعة حركة البث على 9 مضيفين. للتوضيح ، يُشار إلى انخفاض السرعة على جميع الأجهزة المضيفة المتصلة بالمفتاح على أنه .

استنادًا إلى انخفاض السرعة المكتشف ، يمكنك توزيع المضيفين في مجموعتين:

• الأصفر (الأولي) - الأجهزة المضيفة التي ظلت سرعة البث عليها قريبة من الحد الأقصى ؛
• أخضر - الأجهزة المضيفة التي تم تسجيل انخفاض كبير في سرعة البث فيها.

التكرار 2 . سنختار مضيفين أحادي الإرسال و dst أحادي الإرسال ، ونبدأ مرة أخرى في مسح الإحصاءات وجمعها.

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

التكرار 3 . مرة أخرى ، حدد المضيفين الأحاديين src و dst الأحاديين ، وابدأ مرة أخرى في مسح الإحصاءات وجمعها.

يتم تسجيل انخفاض السرعة على المضيفين الثلاثة الآخرين. الآن هم في الكتلة الخضراء . انقل هذه الأجهزة المضيفة الثلاثة من المجموعة الخضراء إلى المجموعة الأرجوانية الجديدة.

خلاصة القول : بعد ثلاثة تكرارات من أصل 110 ، تم تقسيم جميع المضيفين إلى مجموعات تقابل مفاتيحهم. في التكرارات الـ 107 المتبقية ، لن يتم تكوين مجموعات جديدة.

لقد كانت حالة مثالية - إما أننا عرفنا طوبولوجيا الشبكة ، أو كنا محظوظين جدًا.

# أتساءل ماذا يمكن أن تكون خيارات التكرار الأول؟

الخيار 1: "unicast on البث sw" . يقع Unicast src على نفس المفتاح الموجود في البث src (وكذلك في المثال أعلاه في الشكل في التكرار 1). يقع Unicast dst على أي محول آخر (وليس البث src).

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

الخيار 2: "عام أحادي الإرسال" . يقع Unicast src على أي مفتاح تبديل "غير بث src". يقع Unicast dst على أي محول آخر ("notcast src" و "not unicast src").

في جميع الحالات ، يحدث انخفاض في السرعة على المفاتيح التي تم تحديدها على dst أحادي الإرسال. كان نفس سلوك الشبكة عند التكرار 2 و 3 (انظر الشكل) من المثال في بداية القسم.

الخيار 3: "unicast to البث sw" . يقع Unicast src على أي مفتاح تبديل "غير بث src" (وكذلك في الخيار 2). يقع Unicast dst على نفس المفتاح مثل البث src.

في هذه الحالات ، لا توجد استجابة شبكة للمسح الضوئي. إذا تم إنشاء مجموعة جديدة في الإصدارات السابقة (1 و 2) ، فلن يتم إنشاء مجموعات جديدة في هذا البديل. هذا أمر سيئ جزئيًا - لا نحصل على معلومات جديدة حول طوبولوجيا الشبكة (في الواقع ، في بعض الحالات ، وإذا لم يكن هذا التكرار هو الأول ، يمكنك الحصول على بعض المعلومات حول موقع dst أحادي الإرسال).

الخيار 4: "unicast in sw" . يقع Unicast src و dst على نفس المفتاح.

هنا أيضًا ، لا تستجيب الشبكة على الإطلاق للمسح الضوئي ، وبالتالي لا توجد مجموعات جديدة.

النتيجة . الخياران 1 و 2 جيدان ، وتستجيب الشبكة إليهما ، وتعطينا معلومات جديدة حول هيكلها. وبناءً على هذه المعلومات ، يتم إنشاء مجموعات جديدة.

يمكن أن يقول الخياران 3 و 4 فقط أن البث الأحادي dst إما على نفس المحول مع البث src أو على نفس المحول مع أحادي الإرسال src. علاوة على ذلك ، لا يمكنهم تقديم معلومات كاملة في تكرار واحد حول الموقع الدقيق لـ dic أحادي البث - سيكونون دائمًا بجوار البث src أو unicast src. لا يمكن الحصول على الموقع الدقيق إلا من خلال دمج المعلومات الواردة مع المعلومات من التكرارات الأخرى.

# هل كان اختيار أحادي الإرسال src و dst في المثال عشوائي؟

ربما كان الاختيار ليس عشوائيًا ، وهناك نمط مخفي فيه؟

حسنًا ، نظرنا للتو إلى كيفية استجابة الشبكة لخيارات المسح المختلفة. تذكر المثال من بداية القسم ، ربما حان الوقت للنظر إليه من "زاوية جديدة" والإجابة على السؤال: هل اخترت بالخطأ unicast src و dst ، أو غش؟

هذه الصورة شبيهة بالصورة من بداية القسم ، والفرق هو أن الخيارات البديلة لـ unicast src أضيفت إلى كل تكرار ، وشيء على اليمين ...

هذا "الشيء" هو حساب احتمالية تشكيل مجموعة جديدة (عدد الخيارات التي سيتم إنشاء مجموعة جديدة مقسومًا على عدد الخيارات التي سيتم إنشاء مجموعة جديدة فيها + عدد الخيارات التي لا تؤدي إلى إنشاء مجموعة جديدة). تم حساب الخيارات بالنسبة إلى أحادي الإرسال الثابت و أحادي الإرسال dst. Unicast dst "مجاني" - هذا يعني أنه تم النظر في جميع الخيارات الممكنة لموقعه.

أي ، في المثال ، اخترت على وجه التحديد تلك الخيارات التي لديها أكبر احتمال لتشكيل مجموعة جديدة. لسوء الحظ ، في الواقع لا يمكننا استخدام مثل هذا التقدير (الاحتمالات). لا عجب في النهاية كتبت:

لقد كانت حالة مثالية - إما أننا عرفنا طوبولوجيا الشبكة ، أو كنا محظوظين جدًا.

ومع ذلك ، فإن القدرة على تقييم احتمال تشكيل كتلة جديدة مفيدة لنا أدناه.

# امسح داخل المجموعة ، أو استخدم المسح عبر الكتلة - هذا هو السؤال ...

في المثال أعلاه ، في التكرار الأخير (الثالث) ، تم استخدام المسح بين العناقيد. هل هو جيد جدا ، لأنهم في البداية استخدموا المسح داخل الكتلة؟

ملاحظة : إذا كان unicast src و dst في نفس المجموعة ، فهذا فحص داخل الكتلة . إذا كان unicast src في مجموعة واحدة ، و unicast dst في مجموعة أخرى - فهذا هو المسح بين المجموعات .

إذا نظرت إلى الاحتمالات في التكرار الثالث ، فسيكون للفحص بين المجموعات 0.60 مقابل 0.30 للمسح داخل الكتلة. يبدو أن الاحتمالية تقول لنا "استخدم المسح بين المجموعات ، يا أخي" ، ولكن هل يستحق الأمر اتباع نصائحها بشكل أعمى؟

ملاحظة : سيؤدي استخدام نوع واحد فقط من المسح (إما داخل كتلة أو مجموعة) إلى تقليل عدد التكرارات بشكل كبير.

إذا في المثال أعلاه ، بدءًا من التكرار الرابع ، بدأنا في المسح داخل الكتلة فقط ، فسيستغرق ذلك 20 تكرارًا (3 × 2 + 3 × 2 + 2 × 1 + 3 × 2) ، في المجموع سيتم الحصول على 23 تكرارًا بدلاً من 110 (كما كان تحسب في بداية القسم). إذا تم بدء المسح بين المجموعات فقط ، بدءًا من نفس التكرار الرابع ، فسيستغرق 87 تكرارًا (3 × (3 + 2 + 3) + 3 × (3 + 2 + 3) + 2 × (3 + 3 + 3) + 3 × (3 + 3 + 2) - 3) ، سيظهر إجمالي 90 تكرارًا .

يفقد المسح بين المجموعات بشكل ملحوظ ، علاوة على ذلك ، لا يمكن استخدامه في التكرار الأول (في هذه اللحظة هناك مجموعة واحدة فقط). إذا انتبهنا إلى التكرار الثاني من المثال أعلاه ، يمكننا أن نرى أن خيار المسح البديل الأخير لديه احتمال تشكيل كتلة جديدة من 0.00. أعتقد أن الإجابة على السؤال: "ما نوع المسح الضوئي الذي حصل عليه هذا البديل؟" واضح بالفعل.

# مسرات المسح المتوازي

إذا كان من الممكن ، باستخدام المسح داخل كتلة ، إجراء مسح في وقت واحد في جميع المجموعات في وقت واحد ، ثم سيتم تقليل 20 تكرارًا إضافيًا (3 × 2 + 3 × 2 + 2 × 1 + 3 × 2) إلى 6 تكرارات (3 × 2). يمكن أن يستفيد المسح بين المجموعات أيضًا من المسح المتوازي.

السؤال هو ما إذا كان فحص واحد سيؤثر على نتائج فحص آخر ، يتم تشغيله بالتوازي.

Note : ( ), – , ?

: – ; , 2‑ — .

– 6‑ . , unicast src dst , 2 . , 2‑ : “ 0.00”.

“ ”, . , ‑ …

, , . 2‑ (“ unicast on broadcast sw ”: unicast src , broadcast src) (“unicast in sw”: unicast src dst ).

“ unicast on broadcast sw ” , “unicast in sw”, . , “unicast in sw” , unicast src ( – ), 2 .

. , ( , ), . “” , broadcast src. , , broadcast src , ! .

Note : , unicast src , , ( ), .

: .

IQ …

# : “ ”

.

unicast ( ) broadcast ( ) , broadcast ( ). 5‑ , “” , – . , , , (↼), ( ) – (⇁), .. (⇋).

.

5 15 . LLTR Basic, 15 , n=14 ⇒ 182 .

. 1‑ , , unicast src , broadcast src, unicast dst broadcast src . Unicast ( ) broadcast broadcast src . ( ). 2‑ , , unicast dst broadcast src .

. ( ).

3 . broadcast unicast – .

4 . broadcast unicast – .

5 . Unicast src dst broadcast src – , unicast dst ( ). , 2‑ , , “ ”.

, , (2 ):

, . 4‑ ( , , ), 1‑ .

30 ((4) + (3×2 + 3×2 + 3×2 + 2×1 + 3×2)) , 182 LLTR Basic.

?

, ‑ . 3‑ , unicast (↼), broadcast , unicast src . , unicast src ( ), , . unicast src , . , , “ ” .

, , , ? “ ” …

( ), :

(2 ), ( ).

, – , 1 . – / .

, 1 , ( , ), , 1 , ? ?

: ( ), () . , , 4 (1 + 3 ):

:

: “ , ?” – , .

? . … ；）

# TL;DR

, …

, , :

• 2 / , – ;
• / , , ( ‑ ).

xkcd, , （：

# / To be continued…

1. OMNeT++ INET [ tutorial ]
3. OMNeT++
4. الرياضيات
5. OMNeT++ 2
7. (‑: “ ”)

: GitHub Pages ;

PS （； URI )

PPS , ；）

PPPS , , – . ( ) , / , – ：）

PPPPS , .