OpenVPN મલ્ટિકાસ્ટ દરેક ક્લાયન્ટને મોકલે છે, સબ્સ્ક્રાઇબરોને નહીં

"મલ્ટિકાસ્ટ સપોર્ટ કરે છે" એ પ્રોટોકોલનો પ્રશ્ન જવાબ આપે છે અને ક્ષમતાનો પ્રશ્ન અડ્યો વિનાનો રાખે છે. ઓપરેશનલ રીતે મહત્વનું એ છે કે સર્વર એક ગ્રુપ પેકેટ માટે કેટલી નકલો મોકલે છે અને કઈ ટનલ તેમને વહેવડાવે છે. સ્ટ્રીમ મેળવતી એક સબ્સ્ક્રાઇબ થયેલી એપ્લિકેશન ફક્ત એ સાબિત કરે છે કે ડિલિવરી ક્યાંક કામ કરે છે. તે એ સાબિત કરતી નથી કે રસ ન ધરાવતા ક્લાયન્ટોને બેન્ડવિડ્થ બચી ગઈ છે.

એક ફીચર દાવા વચ્ચેના ત્રણ પ્રશ્નો

ગ્રુપ સભ્યપદ પૂછે છે કે રિસીવર ગ્રુપમાં જોડાયો છે કે નહીં. ટનલ ડિલિવરી પૂછે છે કે પેકેટ ટનલમાંથી પસાર થયું છે કે નહીં. રેપ્લિકેશન નીતિ પૂછે છે કે સર્વરે કેટલી નકલો બનાવી અને કોને આપી. વેન્ડરનું નિવેદન પહેલા માટે સાચું અને ત્રીજા વિશે મૌન હોઈ શકે છે, અને ત્યાં જ ખર્ચ રહે છે.

લિંકનું માપ નક્કી કરતી વખતે તેમને અલગ રાખો. ફક્ત ત્રીજો પ્રશ્ન સર્વર બાજુએ આઉટબાઉન્ડ બજેટ નક્કી કરે છે.

યુઝરસ્પેસ સર્વર ગ્રુપ પેકેટ સાથે શું કરે છે

OpenVPN 2.6 ના પરંપરાગત યુઝરસ્પેસ સર્વરમાં, આવતું બ્રોડકાસ્ટ કે મલ્ટિકાસ્ટ પેકેટ TUN/TAP ઇનપુટ માર્ગમાં વર્ગીકૃત થાય છે અને ગ્રુપ દીઠ શોધને બદલે બ્રોડકાસ્ટ ફેન-આઉટ રૂટિનને સોંપાય છે. તે રૂટિન ક્લાયન્ટ ઇન્સ્ટન્સોમાંથી પસાર થાય છે, પ્રેષક અને કોઈપણ અટકાવેલા ઇન્સ્ટન્સને છોડી દે છે, જ્યાં VLAN ગોઠવાયેલું હોય ત્યાં તેની ચકાસણી લાગુ કરે છે, અને બાકીના દરેક ક્લાયન્ટ માટે એક નકલ કતારમાં મૂકે છે. તે લૂપમાં કોઈ પણ પગલું સભ્યપદ કોષ્ટકને પૂછતું નથી. તે બ્રોડકાસ્ટ-શૈલીનું રેપ્લિકેશન છે, અને આખી ક્રિયાવિધિ એ જ છે.

આને તે કોડ માર્ગની લાક્ષણિકતા ગણો, સાર્વત્રિક નિયમ નહીં. વેગવાળા ડેટા માર્ગો, અન્ય અમલીકરણો અને જુદા સંસ્કરણો જુદી રીતે વર્તી શકે છે, અને તેમાંથી કંઈ પણ TAPને જરૂરિયાત કે સમારકામ બનાવતું નથી.

કંઈપણ માપતા પહેલાં નકલોનું બજેટ બનાવો

પેલોડ દર લો અને પાત્ર ક્લાયન્ટની સંખ્યાથી ગુણો. સેકન્ડમાં એક મેગાબિટ વીસ ક્લાયન્ટને મોકલતો સ્ટ્રીમ સેકન્ડમાં વીસ મેગાબિટ પેલોડ ઉત્પન્ન કરે છે જે સર્વર છોડે છે, એન્કેપ્સ્યુલેશન, પુનઃપ્રસારણ અને દરેક ક્લાયન્ટના કોઈપણ ઓવરહેડ પહેલાં. તે ગણતરી બજેટ છે, તમારા ડિપ્લોયમેન્ટનું માપ નહીં.

ip -s link show tun0

એક જાણીતા સક્રિય પ્રેષક સાથે નિશ્ચિત અંતરાલ પહેલાં અને પછી ટ્રાન્સમિટ બાઇટ કાઉન્ટર વાંચો. અંતરાલથી ભાગો અને પેલોડ દરને ક્લાયન્ટ સંખ્યાથી ગુણીને તુલના કરો. એક સ્ટ્રીમના દરની નજીકની સંખ્યા એટલે રેપ્લિકેશન મર્યાદિત છે; ગુણેલા દરની નજીકની સંખ્યા એટલે દરેક ક્લાયન્ટ નકલ મેળવે છે.

કાઉન્ટરમાં તમારો પોતાનો ટનલ ટ્રાફિક પણ સામેલ હોય છે, તેથી પરીક્ષણ વિન્ડો ટૂંકી અને હોસ્ટને બાકીના સમયે શાંત રાખો. ચોકસાઈ કરતાં ક્રમની માત્રા વધુ અગત્યની છે, અને એક નકલને વીસથી અલગ પાડવા માટે તમને એટલું જ જોઈએ.

બે ક્લાયન્ટની પરીક્ષા જે હદનો પ્રશ્ન નક્કી કરે છે

એક ક્લાયન્ટ જોડો જેને સ્ટ્રીમ મળવો જોઈએ અને બીજો જેને ન મળવો જોઈએ. પ્રેષક શરૂ કરો, પછી તે જ અંતરાલ માટે બીજા ક્લાયન્ટના ટનલ કાઉન્ટર જુઓ. બીજા ક્લાયન્ટ પર વૃદ્ધિ વ્યાપક રેપ્લિકેશનનો સીધો પુરાવો છે, ફીચર યાદી શું કહે તે પછી પણ.

કેપ્ચરને ગ્રુપ સરનામા પર ફિલ્ટર કરો જેથી અસંબંધિત ટ્રાફિક ન વાંચો, અને તેને ટનલ ઇન્ટરફેસ સુધી મર્યાદિત રાખો. વ્યસ્ત હોસ્ટ પર ભૌતિક ઇન્ટરફેસ કેપ્ચર કરવાથી એવી ફાઇલ બને છે જે કોઈ સમજી શકતું નથી અને જે વપરાશકર્તા ડેટા રાખી શકે છે જે તમે એકત્ર કરવાનો ઇરાદો નહોતો રાખ્યો.

પછી ભૂમિકાઓ ઉલટાવો. જો પરિણામ ગ્રુપને બદલે રિસીવરને અનુસરે, તો તમે સભ્યપદ-સભાન કંઈક જોઈ રહ્યા છો, અને અગાઉની ધારણા તમારા પક્ષમાં ખોટી હતી.

મર્યાદા દૂર કરવાને બદલે મર્યાદિત ડિઝાઇન પસંદ કરવી

જ્યારે ફેન-આઉટ ખૂબ પહોળું હોય, ત્યારે ઉકેલ સપોર્ટેડ મર્યાદિત વિતરણ ગોઠવણી છે, તમારા બધા નિયંત્રણો દૂર કરવા નહીં. વિકલ્પોમાં વિતરણ બિંદુને રિસીવરોની નજીક લાવવું, સ્રોત-વિશિષ્ટ સબ્સ્ક્રિપ્શન મોડેલ વાપરવું જે ગ્રુપ સાથે સ્રોતની ઓળખ પણ વહે છે, અથવા સ્ટ્રીમને વિભાજિત કરવું જેથી રસ ન ધરાવતી સાઇટો ક્યારેય એક જ વિતરણ સીમા પર ન બેસે.

સ્રોત અને ગ્રુપની ઓળખને ગંતવ્ય મલ્ટિકાસ્ટ હોવાની નરી હકીકતથી અલગ રાખો. જે રિસીવર ગ્રુપ ઓળખે છે પણ સ્રોત નહીં, તે ચોક્કસ ચેનલ માંગનાર સબ્સ્ક્રાઇબર કરતાં જુદો સબ્સ્ક્રાઇબર છે. બંનેને ભેળવવાથી પછીનું ક્ષમતા આયોજન અનુમાન બની જાય છે.

સ્રોત-વિશિષ્ટ મલ્ટિકાસ્ટ ચેનલ મોડેલ આ ભેદ માટે સંદર્ભ છે. તમે જે પણ ડિઝાઇન પસંદ કરો, પાત્ર પીઅર સેટ, રેપ્લિકેશનનો માલિક અને આગલી વખતે વાંચવાનું કાઉન્ટર લખી રાખો; તે રેકોર્ડ જ બેન્ડવિડ્થના આશ્ચર્યને જાણીતા ખર્ચમાં ફેરવે છે.