.NET-soketo bezonas SOCKS-manpremon
Klarigu, kion kruda .NET TCP-soketo devas fari antaŭ ol la bajtoj de la aplikaĵo povas vojaĝi tra SOCKS-prokurilo.
Se Socket.Connect() montras al SOCKS-servilo, malfermiĝas TCP-konekto al tiu servilo. La sekvaj bajtoj tamen devas paroli SOCKS. Se oni tuj sendas la protokolon de la aplikaĵo, la servilo atendas alian konversacion.
Ĉe SOCKS5, konekta starigo inkluzivas metod-negocadon, eventualan elektitan aŭtentikigan interŝanĝon, kaj peton nomantan la celon. Nur sukcesa respondo malfermas la vojon por la bajtoj de la aplikaĵo. Tiuj etapoj estas difinitaj en RFC 1928.
Tenu la negocadon en la konekta tavolo
Aplikaĵo kun propra TCP-protokolo povas uzi prokurilo-konscian konektilon, kiu redonas starigitan fluon. La resto de la aplikaĵo tiam legas kaj skribas tra tiu fluo. Konektilo devas konsideri partajn legadojn, vari-longajn adresojn, aŭtentikigajn malsukcesojn kaj limdaton por la negocado.
Mane skribita efektivigo, kiu legas unu bufron de fiksa grando kaj supozas sukceson, estas fragila. TCP ne konservas la limojn de la SOCKS-mesaĝoj. Legu la plenan respondon priskribitan de ĝia adrestipo antaŭ ol komenci la aplikaĵan protokolon. Legilo de CONNECT-respondoj por .NET 7+ ilustras tiun paŝon.
Se prizorgata biblioteko jam provizas tiun ĉi konektan tavolon, kontrolu ĝiajn subtenatajn SOCKS-versiojn, aŭtentikigajn metodojn kaj celan kadron. Dekjara forumligilo estas elirpunkto por esplorado, ne pruvo de nuna kongruo.
La HTTP-klienta agordo havas apartan amplekson
La prokurila agordo de HTTP-kliento agordas tiun HTTP-klienton. Ĝi ne modifas ĉiun krudan soketon en la procezo. La Socket-API akceptas retan finpunkton kaj lasas la pli altnivelan negocadon al la alvokanto.
Por ĉifrita aplikaĵa protokolo, plenumu ĝian TLS-manpremon post kiam la prokurila tunelo estas starigita. Validigu la identecon de la celata destino en tiu etapo. Prokurila aŭtentikigo kaj celloka aŭtentikigo restas apartaj, kvankam ili uzas la saman suban fluon.