OpenVPN nagpapadala ng multicast sa bawat kliyente, hindi sa mga subscriber

"Sinusuportahan ang multicast" ay sumasagot sa tanong ng protocol at iniiwan ang tanong ng kapasidad na hindi nagalaw. Ang mahalaga sa operasyon ay kung ilang kopya ang inilalabas ng server para sa isang packet ng grupo at kung aling mga tunnel ang nagdadala sa kanila. Ang isang naka-subscribe na application na tumatanggap ng stream ay nagpapatunay lamang na gumagana ang paghahatid sa isang lugar. Hindi nito pinapatunayan na ang mga kliyenteng walang interes ay natipid sa bandwidth.

Tatlong tanong sa loob ng isang pahayag tungkol sa feature

Ang pagiging kasapi ng grupo ay nagtatanong kung sumali ang tatanggap sa grupo. Ang paghahatid sa tunnel ay nagtatanong kung tumawid ang packet sa tunnel. Ang patakaran ng replicasyon ay nagtatanong kung ilang kopya ang ginawa ng server at kanino. Ang pahayag ng vendor ay maaaring totoo sa una at tahimik sa ikatlo, at doon nakatira ang gastos.

Panatilihin silang hiwalay kapag tinatantiya mo ang laki ng link. Tanging ang ikatlong tanong ang nagtatakda ng badyet ng palabas sa panig ng server.

Ano ang ginagawa ng server sa espasyo ng user sa isang packet ng grupo

Sa tradisyonal na server sa espasyo ng user ng OpenVPN 2.6, ang papasok na packet ng broadcast o multicast ay inuuri sa daanan ng input na TUN/TAP at ibinibigay sa rutina ng pagpapalawak ng broadcast sa halip na paghahanap bawat grupo. Ang rutinang iyon ay dumadaan sa mga instance ng kliyente, lumalaktaw sa nagpadala at sa anumang instance na itinigil, inilalapat ang pagsusuri nito ng VLAN kung saan may naka-configure, at naglalagay ng kopya sa pila para sa bawat natitirang kliyente. Walang hakbang sa loop na iyon ang nagtatanong sa talahanayan ng pagiging kasapi. Iyon ay replicasyon sa istilong broadcast, at iyon ang buong mekanismo.

Ituring ito na katangian ng daanang iyon ng code, hindi bilang pangkalahatang batas. Ang mga pinabilis na daanan ng data, iba pang implementasyon at iba't ibang bersyon ay maaaring kumilos nang iba, at wala sa mga ito ang gumagawa sa TAP na pangangailangan o pagkukumpuni.

Ibudget ang mga kopya bago magsukat ng kahit ano

Kunin ang rate ng payload at i-multiply ito sa bilang ng mga karapat-dapat na kliyente. Ang stream na nagpapadala ng isang megabit kada segundo sa dalawampung kliyente ay gumagawa ng dalawampung megabit kada segundo ng payload na lumalabas sa server, bago ang encapsulation, muling pagpapadala at anumang karagdagang gastos bawat kliyente. Ang aritmetikang iyon ay badyet, hindi sukat ng iyong deployment.

ip -s link show tun0

Basahin ang counter ng mga byte na ipinadala bago at pagkatapos ng takdang pagitan na may isang kilalang aktibong nagpadala. Hatiin sa pagitan at ihambing sa rate ng payload na pinarami ng bilang ng kliyente. Ang bilang na malapit sa rate ng isang stream ay nangangahulugang limitado ang replicasyon; ang bilang na malapit sa pinaraming rate ay nangangahulugang bawat kliyente ay tumatanggap ng kopya.

Kasama sa counter ang sarili mong trapiko sa tunnel, kaya panatilihing maikli ang bintana ng pagsubok at tahimik ang host sa ibang pagkakataon. Mas mababa ang kahalagahan ng katumpakan kaysa sa pagkakasunod-sunod ng magnitude, at iyon lang ang kailangan mo upang makilala ang isang kopya sa dalawampu.

Isang pagsubok na may dalawang kliyente na nagtatakda ng tanong sa saklaw

Ikonekta ang isang kliyenteng dapat tumanggap ng stream at isa pang hindi dapat. Simulan ang nagpadala, pagkatapos ay panoorin ang mga counter ng tunnel ng ikalawang kliyente sa parehong pagitan. Ang paglaki sa ikalawang kliyente ay direktang ebidensya ng malawak na replicasyon, anuman ang sinabi ng listahan ng feature.

I-filter ang pagkuha sa address ng grupo upang hindi ka magbasa ng walang kaugnayang trapiko, at limitahan ito sa interface ng tunnel. Ang pagkuha ng pisikal na interface sa abalang host ay gumagawa ng file na walang makapagpapaliwanag at maaaring magtago ng data ng user na hindi mo sinadyang kolektahin.

Pagkatapos ay baliktarin ang mga papel. Kung sinusundan ng resulta ang tumatanggap at hindi ang grupo, may tinitingnan kang bagay na may kamalayan sa pagiging kasapi, at ang dating palagay ay mali sa iyong pabor.

Pumili ng limitadong disenyo sa halip na alisin ang mga limitasyon

Kapag masyadong malawak ang pagpapalawak, ang solusyon ay isang sinusuportahang limitadong kaayusan ng distribusyon, hindi ang pagbura sa bawat kontrol na mayroon ka. Kabilang sa mga opsyon ang paglalapit ng punto ng distribusyon sa mga tumatanggap, paggamit ng modelong subscription na tiyak sa pinagmulan na nagdadala ng pagkakakilanlan ng pinagmulan kasama ng grupo, o paghahati ng stream upang ang mga site na walang interes ay hindi kailanman umupo sa parehong hangganan ng distribusyon.

Panatilihing hiwalay ang pagkakakilanlan ng pinagmulan at grupo mula sa hubad na katotohanan na ang destinasyon ay multicast. Ang tumatanggap na nakikilala ang grupo ngunit hindi ang pinagmulan ay ibang subscriber kaysa sa isang humiling ng partikular na channel. Ang paghahalo ng dalawa ay ginagawang hula ang pagpaplano ng kapasidad sa hinaharap.

Ang modelo ng channel na multicast na tiyak sa pinagmulan ang sanggunian para sa pagkakaibang iyon. Anuman ang design na piliin mo, isulat ang hanay ng mga karapat-dapat na peer, ang may-ari ng replicasyon at ang counter na babasahin mo sa susunod; ang talaang iyon ang nagpapalit ng sorpresa sa bandwidth tungo sa kilalang gastos.