Overlay ya N2N si proxy: chora miunganisho yote mawili

Firefox inaelekeza kwa 127.0.0.1:8000, ukingo wa N2N uko hai, mwenzake anajibu ping kwenye anwani yake ya overlay, na kivinjari bado kinaripoti kuwa proxy ilikataa muunganisho. Hakuna kitu kinachopingana katika mnyororo huo. Overlay inampa mwenyeji anwani inayofikika kwenye mtandao wa kibinafsi; haitengenezi mchakato unaozungumza itifaki ya proxy. Kivinjari hakiombi njia kuelekea mwenzake. Kinaomba msikilizaji wa ndani.

Hapa miunganisho miwili inachanganywa, na kuichora kivyake kunafafanua sehemu kubwa ya mkanganyiko katika dakika moja.

Miunganisho miwili, si mmoja

Muunganisho wa kwanza unaenda kutoka kivinjari hadi kile kinachosikiliza kwenye mlango wa loopback. Hiyo ni socket ya ndani, na ikiwa hakuna kinachomiliki, muunganisho unakataliwa kabla hata pakiti moja kufika N2N. Wa pili unaenda kutoka mchakato wa proxy hadi chanzo kinachochukua. Njia hiyo inachaguliwa na jedwali la uelekezaji la mwenyeji wa proxy, na inaweza kuwa uplink ya kawaida, handaki lingine, au njia ya sera isiyo na uhusiano wowote na overlay.

Kupiga ping kwa mwenzake kunathibitisha kuwa overlay inaweza kuwasilisha pakiti kati ya anwani za ukingo. Haithibitishi chochote kuhusu msikilizaji kwenye mlango 8000, wala kuhusu iwapo mwenyeji huyo anaweza kufikia chanzo. Hitilafu tofauti, marekebisho tofauti.

Msikilizaji anapaswa kuishi wapi

Proxy iliyofungwa kwa 127.0.0.1 ni ya ndani kwa makusudi: inakubali miunganisho kutoka kwa mashine inayoendeshwa pekee. Hiyo ni chaguo sahihi la kawaida kwa proxy ya kibinafsi na umbo lisilofaa kwa kuishirikisha kupitia overlay. Kuhudumia wenzake wa overlay kunahitaji ama anwani ya bind kwenye kiolesura cha overlay au sehemu ya upelekaji inayomaliza muunganisho wa loopback na kuupeleka. Kwa vyovyote, sera iliyo wazi inapaswa kuamua vyanzo vipi vya overlay vinaweza kutumia huduma, kwa sababu proxy iliyo wazi kwenye mtandao unaoshirikiwa ni mwaliko.

Angalia bind halisi kwa orodha ya socket badala ya faili ya usanidi. Daemon iliyoanzishwa kabla overlay haijainuka inaweza bado kufungwa kwa anwani ambayo haipo tena.

localhost si mwenzake

Katika uwanja wa proxy wa kivinjari, localhost inaelekeza kwa mashine ya kivinjari yenyewe. Si ukingo, si supernode, na si mwenyeji wa upande wa mbali wa handaki. Ikiwa proxy inaendeshwa kwa mwenzake mwingine, weka anwani ya overlay inayofikika na mlango wa mwenzake huyo kwenye uwanja, kisha thibitisha kuwa msikilizaji anakubali miunganisho kutoka anwani ya ukingo wako.

Supernode husaidia kingo kupata kila mmoja; si huduma ya proxy. Kutibu anwani ya supernode kama kituo cha mwisho cha proxy hutoa kataa hiyo hiyo pamoja na hatua ya ziada ya mkanganyiko.

Njia haiwezi kufanya handshake

Hata kwa anwani sahihi, uelekezaji si uproxying. Muunganisho wa proxy ya HTTP huanza kwa ombi la CONNECT au mstari wa ombi wa umbo kamili, na proxy ya SOCKS huanza kwa majadiliano ya toleo na mbinu. Kipanga njia au overlay husafirisha baiti; haichambui ujumbe huo wala haifungui muunganisho unaofuata kwa niaba yako. Ndiyo sababu njia inayofanya kazi kwa ping na SSH inaweza bado kushindwa kwa proxy ya kivinjari: kivinjari kinahitaji mchakato unaoshirikiana, si ufikivu tu.

Ikiwa lengo ni kufikia huduma kwa mwenzake tu, ondoa mpangilio wa proxy na tumia anwani ya overlay ya huduma moja kwa moja.

Jaribu mipaka kwa mpangilio

Thibitisha kuwa anwani ya overlay inajibu, kisha thibitisha kuwa kuna msikilizaji kwenye mlango uliosanidiwa na uandike anwani yake ya bind. Fanya ombi moja lililodhibitiwa na usome kumbukumbu ya proxy, ili ujue kama hitilafu iko kwa msikilizaji au kwenye uchukuaji unaofuata. Mwishowe, angalia njia ya mwenyeji wa proxy na sera ya DNS kwa chanzo.

Mradi wa N2N unaandika kingo na supernode kama sehemu za overlay. Haubadilishi ukingo kuwa proxy ya programu, na hakuna usanidi wa uelekezaji unaoongeza kishughulikia itifaki ambacho hakuna aliyekianzisha.