Nebula advertise_addrs કે static_host_map: માલિક પ્રમાણે પસંદ કરો
સ્થિર નકશો તેને ડાયલ કરતા દરેક પીઅર દ્વારા જાળવવામાં આવે છે; જાહેર કરેલું સરનામું હોસ્ટ દ્વારા પ્રકાશિત થાય છે. કોણ એન્ડપોઇન્ટ જાણે છે તે પ્રમાણે પસંદ કરો.
static_host_map અને advertise_addrs સેટિંગ્સ બંને પીઅરની સામે સરનામું મૂકે છે, અને તેઓ જુદા જુદા પ્રશ્નોના જવાબ આપે છે. એક સ્થાનિક ફાઇલ છે જે ઓવરલે સરનામું અને ડાયલ કરવાનું અંડરલે એન્ડપોઇન્ટ સૂચિબદ્ધ કરે છે. બીજું હોસ્ટ છે જે તેના લાઇટહાઉસને કહે છે કે કયા વધારાના એન્ડપોઇન્ટ તેને પહોંચી શકે છે. માલિકી એ ખરો તફાવત છે: નકશો તેને જરૂર હોય તે દરેક જાળવે છે, અને જાહેરાત હોસ્ટ પોતે.
માહિતી કોની છે તે પ્રમાણે નિર્ણય કરો
| Setting | Where it lives | Best for |
|---|---|---|
static_host_map | Every peer that needs the entry | Bootstrap endpoints, deliberately fixed paths |
advertise_addrs | The host's own config | Endpoints the host cannot otherwise discover |
દરેક પીઅરની સ્થિર ફાઇલમાં દરેક બદલાતું પીઅર એ જાળવણીનું કામ છે જે ફ્લીટના વર્ગ સાથે વધે છે. હોસ્ટ પોતે જવાબ જાણે ત્યારે બીજી સેટિંગ તરફ જવાનું વ્યવહારુ કારણ એ જ છે.
માલિકીનો પ્રશ્ન એ પણ અનુમાન કરે છે કે સરનામું બદલાય ત્યારે શું થાય. સ્થિર નકશા સાથે, જૂની એન્ટ્રી ધરાવતા દરેક પીઅરને કોઈએ યાદ રાખવું પડે. જાહેરાત સાથે, હોસ્ટ નવું એન્ડપોઇન્ટ પ્રકાશિત કરે છે અને તેના લાઇટહાઉસ તેને આગળ પસાર કરે છે, તેથી ફેરફાર ખસેડાયેલા મશીન પર જ સ્થાનિક રહે છે.
બૂટસ્ટ્રેપને હજી પણ સ્થિર એન્ટ્રીઓની જરૂર છે
ક્લાયંટે બીજા પીઅર વિશે કોઈને પૂછતા પહેલા ઓછામાં ઓછા એક લાઇટહાઉસ સુધી પહોંચવું પડે. તે પ્રથમ કૂદકો શોધમાંથી આવી શકતો નથી, તેથી તે ક્લાયંટના રૂપરેખાંકનમાં સ્થિર એન્ટ્રી પર આધાર રાખે છે. તે એક એન્ટ્રી સાચી કરો અને બાકીનું ઓવરલે શીખી શકાય છે.
નકશા એન્ટ્રી Nebula સરનામાને એક અથવા વધુ પહોંચી શકાય તેવા IP અથવા DNS એન્ડપોઇન્ટ અને પોર્ટ સાથે જોડે છે. લાઇટહાઉસ ત્યાં રાખવા સામાન્ય છે; દરેક પીઅર ત્યાં રાખવો એ પેટર્ન છે જે ખરાબ રીતે વૃદ્ધ થાય છે, કારણ કે દરેક નવા પીઅરનો અર્થ એવી મશીનો પર ફાઇલો સંપાદિત કરવી જે તમે કદાચ નિયંત્રિત કરતા નથી. યાદી એટલી ટૂંકી રાખો કે વ્યક્તિ વાંચીને તેને ચકાસી શકે.
હોસ્ટ એન્ડપોઇન્ટ જાણે ત્યારે જાહેર કરો
પોર્ટ ફોરવર્ડિંગ પાછળનું હોસ્ટ જાહેર સરનામા પર પહોંચી શકાય છે જે તેના પોતાના કોઈપણ ઇન્ટરફેસને સોંપાયેલું નથી. તે પોતાને જોઈને તે સરનામું શોધી શકતું નથી. advertise_addrs તેને તેના લાઇટહાઉસ દ્વારા એન્ડપોઇન્ટ પ્રકાશિત કરવા દે છે જેથી બીજા પીઅર ખરેખર કામ કરતો માર્ગ શીખે. સેટિંગ ફક્ત એટલા માટે છે કે મેપિંગ થયું છે તે હોસ્ટ જ એકમાત્ર પક્ષ જાણે છે.
તે સરનામું અને પોર્ટ વાપરો જે બીજા પીઅર ખરેખર પહોંચી શકે. એ જ તર્ક ઘણા નેટવર્ક માર્ગો ધરાવતા હોસ્ટને લાગુ પડે છે, જ્યાં ચોક્કસ નેટવર્કના પીઅર માટે એક માર્ગ વધુ સારો છે. જાહેરાત એ અંડરલે વિશેનું નિવેદન છે, કોઈ વસ્તુની વિનંતી નહીં. મેપિંગ બદલાય ત્યારે હોસ્ટ પર જાહેરાત અપડેટ કરો અને શોધને તે લઈ જવા દો, આખી ફ્લીટમાં સ્થિર ફાઇલો સંપાદિત કરવાને બદલે.
જાહેરાત એ પહોંચ નથી
એન્ડપોઇન્ટ પ્રકાશિત કરવાથી રાઉટરનો ફોરવર્ડિંગ નિયમ બનતો નથી, ઉપરના ફાયરવોલ ખૂલતો નથી, કે DNS નામ ઉકેલાતું નથી. તે અલગ કામના ભાગો છે, અને ખૂટતા પોર્ટ ફોરવર્ડિંગ સાથેની સાચી જાહેરાત એ જ નિષ્ફળતા ઉત્પન્ન કરે છે જે તમે સુધારવા માગતા હતા. જાહેરાત એ પહોંચ વિશેનો દાવો છે, તેને સ્થાપિત કરતી કોઈ પદ્ધતિ નહીં.
શોધને દોષ આપતા પહેલા બહારથી માર્ગ તપાસો. જે પીઅર એન્ડપોઇન્ટ શીખે છે પણ હેન્ડશેક પૂર્ણ કરી શકતું નથી તેને અંડરલે પર રાઉટિંગ અથવા ફિલ્ટરિંગની સમસ્યા છે, અને બંને સેટિંગમાં એ જ સરનામું પુનરાવર્તિત કરવાથી તે બદલાશે નહીં.
ઓવરલે સરનામાને એન્ડપોઇન્ટથી અલગ રાખો
નોડનું પ્રમાણપત્ર તેનું Nebula સરનામું ઓળખે છે. જાહેર કરેલા સરનામાં અંતર્ગત નેટવર્કના છે, અને પ્રમાણપત્રને સ્પર્શ કર્યા વિના બદલી શકાય છે. અલગ ઓવરલે IP સાથે નવું પ્રમાણપત્ર જારી કરવું એ અલગ કામગીરી છે, જેની પોતાની અસરો છે દરેક વિશ્વાસ સંબંધ પર જેણે જૂનાને પિન કર્યું હતું. રનબુકમાં બે ફેરફારો અલગ રાખો, નહીંતર એન્ડપોઇન્ટ સ્થળાંતર ફરીથી અમલ તરીકે નોંધાશે.
જ્યારે ટ્રાયેજ અટકે, બે સ્તરોને સ્પષ્ટ રીતે અલગ કરો: શું શોધ અપેક્ષિત એન્ડપોઇન્ટ પરત કરે છે, અને શું હેન્ડશેક તેને પહોંચે છે? જો શોધ સાચી હોય અને પેકેટ નિષ્ફળ જાય, તો સમસ્યા ઓવરલેની નીચે છે. જો શોધ ખોટી હોય, તો સમસ્યા નકશા અથવા જાહેરાતમાં છે, અને સુધારો ત્યાં જ છે.