LLTR Bagian 0: Deteksi topologi jaringan otomatis dan sakelar yang tidak dikelola. Misi Tidak Mungkin?

Bagaimana membangun topologi jaringan pada lapisan data link jika hanya switch yang tidak dikelola yang digunakan dalam subnet yang diinginkan? Dalam artikel ini saya akan mencoba menjawab pertanyaan ini.

Saya akan mulai dengan penyebab LLTR ( Link Layer Topology Reveal ).

Saya punya satu "sepeda" - sinkronisasi file besar "dengan kecepatan jaringan penuh", mampu mengunggah sepenuhnya file 120 GiB melalui Fast Ethernet ( 100 Mbps ; 100BASE - TX; duplex) ke 1, 10, 30, atau 3 jam > 200 pcs . Itu adalah "sepeda" yang sangat berguna karena kecepatan sinkronisasi file hampir tidak tergantung pada jumlah PC yang akan diunggah file. Semuanya akan baik-baik saja, tetapi membutuhkan pengetahuan tentang topologi jaringan untuk pekerjaannya.

Anda dapat melanjutkan rantai lebih jauh, tetapi dalam hal ini saya akan memutuskan.

Protokol penemuan topologi layer data link yang ada ( LLDP , LLTD , CDP , ...) memerlukan dukungan yang tepat dari semua node jaringan perantara untuk operasinya. Artinya, mereka memerlukan setidaknya sakelar yang dikelola yang mendukung protokol yang sesuai. Sudah ada artikel tentang Habré bagaimana menggunakan protokol ini untuk " menentukan topologi jaringan pada level 2/3 dari model OSI ".

Tetapi bagaimana jika simpul-simpul perantara adalah sakelar-sakelar sederhana yang tidak dikelola?

Jika Anda tertarik bagaimana hal ini dapat dilakukan, selamat datang di kucing. Saya menjanjikan ketersediaan banyak ilustrasi dan contoh.

{ukuran gambar: 924 KiB; Teks: 69 KiB; Emoticon: 9 buah. }

@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); } 

Tentang LLTR, saya akan menulis serangkaian artikel dengan tema umum "cara membuat protokol". Artikel ini nol.

# Analogi dari dunia fisik - transportasi pneumatik

Bayangkan kita memiliki 2 pipa udara ...

Satu pipa untuk paket masuk (wadah merah), dan satu untuk paket keluar (wadah biru).

Kami memiliki beberapa teman yang terhubung ke sistem transportasi pneumatik yang sama. Kami dapat mengirim mereka wadah, dan mereka dapat mengirim wadah kepada kami. Alamat pengiriman kontainer ditandai pada wadah itu sendiri (misalnya, dalam RFID atau kode batang).

Pada titik tertentu, semua orang ingin mengetahui rute yang dilalui paket mereka setiap hari, dan untuk mencari tahu sakelar mana (switching center) yang dihubungkan dengan pipa pneumatik mereka, yaitu. Cari tahu topologi jaringan pneumatik.

Yang dapat kita dan teman-teman kita lakukan hanyalah mengirim dan menerima kontainer dengan konten tertentu.

Saya mengusulkan untuk berpikir tentang bagaimana, dalam hal ini, Anda dapat membangun topologi jaringan ini. Beberapa opsi ada di bawah spoiler:

# LLTR Basic

Kembali ke jaringan Ethernet berkabel, izinkan saya mengingatkan Anda tentang masalah karena LLTR dibuat. Masalahnya dijelaskan secara rinci di bagian "PC yang terhubung ke sakelar berbeda" pada artikel RingSync - ini adalah masalah pengurangan kecepatan jika rantai rekan tidak dibangun dengan benar di jaringan dengan beberapa sakelar. Untuk membangun rantai rekan dengan benar, Anda memerlukan informasi tentang topologi jaringan.

Contoh kecil (tidak ada masalah):

Kami memiliki 2 switch (dihubungkan oleh satu "kawat"), 4 host (rekan) , semua koneksi adalah duplex, dan kecepatan semua koneksi adalah sama. Panah menunjukkan jalur data. Dalam hal ini, tidak ada masalah - data ditransmisikan pada kecepatan jaringan maksimum.

Contoh lain (ada masalah):

Dalam contoh ini, rantai rekan dibangun kurang berhasil (karena kita tidak tahu topologi jaringan), yang mengarah pada pembentukan "bottleneck" (dua aliran data searah dalam satu koneksi) dan penurunan laju transfer data keseluruhan.

Dalam hal ini, solusi untuk masalah (menentukan topologi jaringan) terletak pada alasan kebutuhan untuk menyelesaikannya - dalam pembentukan "bottleneck". Seluruh rantai masalah adalah sebagai berikut: Anda perlu menyingkirkan "bottleneck" → Anda perlu membangun rantai "benar" → Anda perlu menentukan topologi jaringan. Ngomong-ngomong, kita tidak akan melalui semua kombinasi yang mungkin dari rantai, untuk mencari rantai tanpa "kemacetan" - itu terlalu lama, sebaliknya kita akan melakukan yang lebih pintar / rumit:

Isi jaringan dengan lalu lintas - pilih salah satu host sebagai sumber lalu lintas siaran. Di semua host lain, kami akan mulai mengumpulkan statistik tentang lalu lintas siaran yang diterima. Selanjutnya, pilih 2 host non-siaran, dan mulai kirim lalu lintas unicast dari host pertama ke host kedua. Menurut statistik lalu lintas siaran yang dikumpulkan pada host pada saat ini, akan terlihat bahwa pada beberapa host kecepatan penerimaan lalu lintas siaran menurun - host ini, dalam hal ini, terhubung ke sakelar yang tepat. Dan pada semua host yang terhubung ke sakelar kiri, kecepatan menerima lalu lintas siaran tidak berubah.

Sambungan antara kedua sakelar menjadi “bottleneck”, dan diizinkan untuk memilih semua penghuni yang terhubung ke sakelar kanan dalam gugus terpisah.

Catatan : Dalam kasus biasa, adalah kebiasaan untuk melawan siaran dengan sekuat tenaga, terutama yang "menggunakan semua bandwidth", tetapi kita berhadapan dengan jaringan saklar yang tidak dikelola yang mungkin telah menderita lebih dari satu kali akibat badai / banjir siaran, dan setidaknya sekali hidup ingin siaran semacam itu bermanfaat. Omong-omong, sangat mungkin untuk mengganti siaran dengan unicast, hanya pemindaian seperti itu akan memakan waktu lebih lama. Untuk transportasi pneumatik, Anda juga harus menggunakan unicast sampai Anda melepaskan instalasi yang mengkloning masalah tersebut dan memasangnya di setiap switching center ： won.

Untuk membangun topologi jaringan yang benar, tetap untuk mengulangi yang sama untuk semua kemungkinan kombinasi pasangan berorientasi non-siaran. Apa yang dimaksud dengan "pasangan berorientasi"? Pertama, Anda perlu mengirim lalu lintas unicast dari host pertama ke yang kedua, dan mengumpulkan statistik, dan kemudian mengubah arah (lalu lintas dari yang kedua ke yang pertama), dan mengumpulkan statistik terpisah untuk opsi ini.

Jumlah kombinasi yang perlu diperiksa dapat dihitung dengan menggunakan rumus n × (n - 1) {masing-masing (n) perlu "menyapa" semua yang lain (n - 1) , bahkan jika mereka sudah menyapanya sebelumnya}, di mana n adalah nomor semua host minus satu (host siaran).

Akibatnya, semua statistik yang dikumpulkan dimasukkan ke input dari algoritma khusus (lebih lanjut tentang hal itu di salah satu artikel berikut), yang membangun topologi jaringan (lebih tepatnya, itu lebih banyak - itu segera membangun rantai rekan yang benar untuk RingSync).

By the way, konfigurasi jaringan minimum yang harus dipindai terdiri dari dua switch, yang masing-masing memiliki dua host yang terhubung. Sedangkan untuk kecepatan penyiaran dan unicast, lalu lintas penyiaran dapat dijaga dalam kisaran 75% - 100% dari " kecepatan data bersih " (bitrate bersih; cari di "Ethernet 100Base-TX"), dan unicast dalam kisaran 80% - 100% .

# LLTR Advanced

^UFO _terbang dan ^{meninggalkan celah} _{ini di sini} ? Mengingatkan salah satu gambar tes IQ

Seperti yang tertulis di atas, ketika menggunakan LLTR Basic, kita perlu memindai jaringan n × (n - 1) kali, yang membawa kita ke O (n ² ). Untuk sejumlah kecil host, ini bukan masalah:

• 4 host, n = 3 ⇒ 6 scan;
• 30 host, n = 29 ⇒ 812 pemindaian.

Tetapi jika kita memiliki 200 host, n = 199 ⇒ 39.402 scan. Lebih buruk lagi ...

Mari kita lihat bagaimana kita dapat memperbaiki situasi. Groknom dua opsi sederhana untuk topologi pohon:

• bintang dari sakelar;
• koneksi serial sakelar.

# Topologi: "bintang dari sakelar"

Di bawah ini, tindakan yang digambarkan dalam gambar ini dijelaskan langkah demi langkah.

Kami memiliki 5 switch dan 12 host. Host ditunjukkan oleh lingkaran [●] di dalam sakelar yang terhubung. Switch yang sepenuhnya hitam adalah switch "root".

Kami memilih salah satu host untuk peran sumber lalu lintas siaran (ditampilkan dalam diagram sebagai lingkaran [○]).

Jika Anda menggunakan LLTR Basic, maka untuk 12 host, n = 11 ⇒ Anda perlu 110 pemindaian (iterasi).

Iterasi 1 . Pilih salah satu host (ditunjukkan dengan warna biru ) sebagai sumber (src) lalu lintas unicast, dan satu host (ditunjukkan oleh warna ● ) sebagai penerima (dst) lalu lintas unicast. Mari kita mulai, pada periode waktu tertentu, memindai dan mengumpulkan statistik.

Statistik yang dikumpulkan menunjukkan penurunan kecepatan lalu lintas siaran di 9 host. Untuk kejelasan, penurunan kecepatan pada semua host yang terhubung ke sakelar dilambangkan sebagai .

Berdasarkan penurunan kecepatan yang terdeteksi, Anda dapat mendistribusikan host dalam dua kelompok:

• kuning (awal) - host yang kecepatan penyiarannya mendekati maksimum;
• hijau - host di mana penurunan signifikan dalam kecepatan siaran direkam.

Iterasi 2 . Kami akan memilih host unicast src dan dst lainnya, dan kembali mulai memindai dan mengumpulkan statistik.

Penurunan kecepatan ditetapkan pada 3 host. Sekarang mereka berada di cluster hijau , karena pada iterasi sebelumnya, penurunan kecepatan juga dicatat pada host ini. Pindahkan 3 host ini dari cluster hijau ke cluster merah baru.

Iterasi 3 . Sekali lagi, pilih host unicast src dan dst lainnya, dan mulai lagi memindai dan mengumpulkan statistik.

Penurunan kecepatan direkam pada 3 host lainnya. Sekarang mereka berada di cluster hijau . Pindahkan 3 host ini dari cluster hijau ke cluster ungu baru.

Intinya : setelah tiga iterasi dari 110, semua host dibagi menjadi kelompok sesuai dengan switch mereka. Dalam 107 iterasi yang tersisa, tidak ada cluster baru yang akan dibentuk.

Itu adalah kasus yang ideal - kami tahu topologi jaringan, atau kami sangat beruntung.

# Saya ingin tahu apa yang bisa menjadi opsi untuk iterasi pertama?

Opsi 1: "unicast on sw sw" . Unicast src terletak pada sakelar yang sama dengan broadcast src (dan juga pada contoh di atas pada gambar di iterasi 1). Unicast dst terletak di sakelar (bukan broadcast src) lainnya.

Dalam semua kasus, respons jaringan terhadap pemindaian adalah sama - penurunan kecepatan pada semua sakelar src non-siaran. Hal ini dapat dimengerti - sic unicast bergabung pada awal saluran yang sama dengan broadcast src - karena itu penurunan kecepatan pada semua sakelar lainnya, dan tidak masalah yang mana yang digunakan unicast pertama.

Opsi 2: "unicast general" . Unicast src terletak di sakelar “non broadcast src”. Unicast dst terletak di sakelar lainnya (“not broadcast src” dan “not unicast src”).

Dalam semua kasus, penurunan kecepatan terjadi pada sakelar yang digunakan unicast dst. Perilaku jaringan yang sama adalah pada iterasi 2 dan 3 (lihat gambar) dari contoh di awal bagian.

Opsi 3: “unicast to broadcast sw” . Unicast src terletak pada sakelar “non broadcast src” (dan juga pada opsi 2). Unicast dst terletak di sakelar yang sama dengan broadcast src.

Dalam kasus ini, tidak ada respons jaringan terhadap pemindaian. Jika dalam versi sebelumnya (1 dan 2) sebuah cluster baru dibuat, maka dalam varian ini cluster baru tidak dibuat. Ini sebagian buruk - kami tidak mendapatkan informasi baru tentang topologi jaringan (pada kenyataannya, dalam beberapa kasus, dan jika iterasi ini bukan yang pertama, Anda bisa mendapatkan beberapa informasi tentang lokasi unicast dst).

Opsi 4: "unicast in sw" . Unicast src dan dst terletak di sakelar yang sama.

Di sini juga, jaringan sama sekali tidak menanggapi pemindaian, dan karenanya tidak ada kluster baru.

Hasilnya Opsi 1 dan 2 bagus, jaringan meresponsnya, dan memberi kami informasi baru tentang topologinya. Dan berdasarkan informasi ini, cluster baru dibuat.

Opsi 3 dan 4 hanya dapat mengatakan bahwa unicast dst berada pada sakelar yang sama dengan src siaran, atau pada sakelar yang sama dengan src unicast. Selain itu, mereka tidak dapat memberikan informasi lengkap dalam satu iterasi tentang lokasi pasti unicast dst - mereka akan selalu berada di sebelah broadcast src atau unicast src. Lokasi yang tepat hanya dapat diperoleh dengan menggabungkan informasi yang diterima dengan informasi dari iterasi lain.

# Apakah pilihan unicast src dan dst dalam contoh acak?

Mungkin pilihannya tidak acak, dan ada pola tersembunyi di dalamnya?

Oke, kami baru saja melihat bagaimana jaringan merespons berbagai opsi pemindaian. Ingat contoh dari awal bagian ini, mungkin sekarang saatnya untuk melihatnya dari “sudut baru” dan menjawab pertanyaan: apakah saya secara tidak sengaja memilih sic dan dst unicast, atau ditipu?

Gambar ini mirip dengan gambar dari awal bagian, perbedaannya adalah bahwa pilihan alternatif unicast src ditambahkan ke setiap iterasi, dan sesuatu di sebelah kanan ...

"Sesuatu" ini adalah perhitungan probabilitas pembentukan cluster baru (jumlah opsi di mana sebuah cluster baru akan dibuat dibagi dengan jumlah opsi di mana sebuah cluster baru akan dibuat + jumlah opsi yang tidak mengarah pada penciptaan sebuah cluster baru). Opsi dihitung relatif terhadap src unicast tetap, dan unstast dst gratis. Unicast dst "free" - ini berarti semua opsi yang memungkinkan untuk lokasinya dipertimbangkan.

Yaitu, dalam contoh, saya secara khusus memilih opsi-opsi yang memiliki kemungkinan terbesar untuk membentuk sebuah cluster baru. Sayangnya, pada kenyataannya kita tidak dapat menggunakan estimasi (probabilitas) tersebut. Tidak heran pada akhirnya saya menulis:

Itu adalah kasus yang ideal - kami tahu topologi jaringan, atau kami sangat beruntung.

Namun, kemampuan untuk mengevaluasi probabilitas pembentukan cluster baru berguna bagi kami di bawah ini.

# Pindai di dalam cluster, atau gunakan pemindaian lintas-cluster - itulah pertanyaannya ...

Pada contoh di atas, dalam iterasi (3) terakhir, pemindaian antar cluster digunakan. Apakah sangat bagus, karena pada awalnya mereka menggunakan pemindaian di dalam cluster?

Catatan : Jika unicast src dan dst berada di cluster yang sama, ini adalah pemindaian di dalam cluster . Jika src unicast berada di satu cluster, dan sst unicast di yang lain - ini adalah pemindaian interluster .

Jika Anda melihat probabilitas di iterasi ke-3, maka pemindaian intercluster akan memiliki 0,60 berbanding 0,30 untuk pemindaian di dalam cluster. Probabilitas tampaknya memberi tahu kita "gunakan pemindaian antar-ras, kawan.", Tetapi apakah layak untuk mengikuti sarannya secara membuta?

Catatan : Menggunakan hanya satu jenis pemindaian (baik di dalam cluster atau intercluster) akan secara signifikan mengurangi jumlah iterasi.

Jika dalam contoh di atas, mulai dari iterasi ke-4, kita mulai memindai hanya di dalam cluster , maka ini akan mengambil 20 iterasi (3 × 2 + 3 × 2 + 2 × 1 + 3 × 2) , total 23 iterasi akan diperoleh alih-alih 110 (seperti sebelumnya dihitung di awal bagian). Jika, dimulai dari iterasi ke-4 yang sama, hanya pemindaian antarkluster yang dimulai , maka diperlukan 87 iterasi (3 × (3 + 2 + 3) + 3 × (3 + 2 + 3) + 2 × (3 + 3 + 3) + 3 × (3 + 3 + 2) - 3) , total 90 iterasi akan berubah.

Pemindaian Intercluster kehilangan terasa, apalagi, itu tidak dapat digunakan pada iterasi 1 (saat ini hanya ada 1 cluster). Jika kita memperhatikan iterasi ke-2 dari contoh di atas, kita dapat melihat bahwa opsi pemindaian alternatif terakhir memiliki kemungkinan membentuk cluster baru 0,00. Saya percaya bahwa jawaban untuk pertanyaan: "Jenis pemindaian apa yang dimiliki alternatif ini?" Sudah jelas.

# Kelezatan pemindaian paralel

Jika, menggunakan pemindaian di dalam sebuah cluster , adalah mungkin untuk menjalankan pemindaian secara simultan di semua cluster sekaligus, maka 20 iterasi tambahan (3 × 2 + 3 × 2 + 2 × 1 + 3 × 2) akan dikurangi menjadi 6 iterasi (3 × 2). Pemindaian intercluster juga dapat memanfaatkan pemindaian paralel.

Pertanyaannya adalah apakah satu pemindaian akan memengaruhi hasil pemindaian lain, dijalankan secara paralel.

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. Matematika
5. OMNeT++ 2
7. (‑: “ ”)

: GitHub Pages ;

PS （； URI )

PPS , ；）

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

PPPPS , .