Nebula punchy સેટિંગ્સ: કઈ એક તમારું NAT સુધારે છે

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

સમય પહેલાં અંતિમ બિંદુ ખાતરી કરો

જે પિયર અપેક્ષિત સરનામે ક્યારેય દેખાતું નથી તેને punch ટ્યુનિંગ બચાવશે નહીં. લાઇટહાઉસ પિયર વિશે શું જાણે છે અને પિયરની પોતાની રૂપરેખા શું જાહેર કરે છે તે તપાસો, કારણ કે જૂનું bootstrap સરનામું અથવા ભૂલથી પ્રકાશિત ખાનગી સરનામું દરેક ટ્રાવર્સલ યુક્તિ નિષ્ફળ કરે છે. પ્રમાણપત્ર વિશ્વસનીય છે તેની પણ ખાતરી કરો, કારણ કે અવિશ્વસનીય ઓળખ NAT મહત્વનું થાય તે પહેલાં ઘણું વહેલું વાતચીત થંભાવે છે. પછી ચકાસો કે UDP લાઇટહાઉસ સુધી પહોંચે છે કે નહીં. સમયના મૂલ્યો સૌથી છેલ્લે જોવાની વસ્તુ છે, પહેલી નહીં.

તમે જે અંતિમ બિંદુની જોડી સાથે ચકાસણી કરો છો તે નોંધો, જેથી પછીની સરખામણી બે બીજા મશીનને બદલે એ જ પિયર વાપરે.

punch મેપિંગ રાખે છે, respond દિશા ખોલે છે

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

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

વિલંબ નક્કી કરે છે ક્યારે, એ નહીં કે થશે કે નહીં

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

પ્રક્રિયા સાચી ન થાય ત્યાં સુધી તેમને રહેવા દો. પછી એક ગોઠવો, અને જૂનું મૂલ્ય લખી રાખો.

જ્યારે રિલે જ પ્રામાણિક જવાબ હોય

કેટલાક NAT સંયોજનો સીધો માર્ગ ટેકવી શકતા નથી, સમય ગમે તેમ ગોઠવો. બંને બાજુ સમપ્રમાણ NAT, અથવા એવો ફાયરવોલ જે માંગ્યા વિનાનું આવતું ટ્રાફિક સંપૂર્ણપણે ફેંકી દે છે, તે કંઈપણ તોડવા જેવું છોડતા નથી.

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

નિષ્ફળ ગયેલી જોડીને નિષ્ક્રિય રહ્યા પછી ચકાસો

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

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