Polnodupleksni tok in povratni tlak v posredniku SOCKS
Načrtujte tok posrednika okoli neodvisnih bajtnih tokov, delnega I/O, omejenih medpomnilnikov in povratnega tlaka namesto ugibanih velikosti odgovora.
Rokovanje SOCKS je uspelo. Zdaj posrednik bere od odjemalca, piše v cilj, čaka na celoten odgovor in šele nato znova bere od odjemalca. Takšno zaporedje lahko blokira popolnoma veljavno aplikacijo.
Ko je tunel TCP vzpostavljen, SOCKS ne določa sporočil v njem. Cilj lahko pošlje prvi. Obe strani lahko pošiljata neodvisno. Ena stran lahko pošlje kratek zapis in nato čaka na odgovor druge.
Posredujte bajte, ne ugibanih transakcij
Klic za sprejem vrne razpoložljive bajte glede na zastavice in stanje vtičnice. Splošnemu posredniku ne pove, da je odgovor aplikacije popoln. Čakanje, da se napolni poljubno velik medpomnilnik, lahko prepreči posredovanje majhnega sporočila, ki ga partner potrebuje za nadaljevanje.
Uporabite obstoječi model sočasnosti aplikacije za oskrbovanje obeh smeri: zanko dogodkov, asinhroni I/O ali drugo namerno izbrano zasnovo. Pomembno vedenje je, da napredek v eni smeri ne zahteva izmišljene meje sporočila v drugi.
Hranite dva omejena čakajoča medpomnilnika
Podatki, prebrani od odjemalca, morda še čakajo, da dosežejo cilj, medtem ko podatki iz cilja čakajo, da dosežejo odjemalca. Te čakajoče bajte spremljajte ločeno.
Pošiljanje lahko zapiše manj bajtov, kot je bilo zahtevano. Obdržite nezapisani del; ne zavrzite ga in ne predvajajte celotnega medpomnilnika znova. Začasno nezapisljiva vtičnica je razlog za čakanje na pravi dogodek pripravljenosti, ne za nenehno vrtenje.
Omejite medpomnilnike. Če je cilj počasen, nadaljnje branje neomejenih podatkov odjemalca preprosto premakne čakalno vrsto v pomnilnik posrednika. Povratni tlak pomeni začasno ustavitev branja, ko je ustrezni čakajoči medpomnilnik poln, in nadaljevanje, ko pisanja sprostijo prostor.
Konec v eni smeri zahteva politiko
TCP lahko zapre smer pošiljanja, medtem ko ima druga smer še koristne podatke. Odločite se, kako razširiti to stanje po izpraznitvi medpomnilnih bajtov, in ločite urejeno zaprtje od napake ali roka.
Nič od tega ne zahteva, da posrednik dešifrira ali razčleni koristno obremenitev aplikacije. Potrebuje pravilno ravnanje s tokom. Samo povečanje medpomnilnika ne more popraviti posrednika, ki čaka na napačno stran ali predpostavlja, da vsako branje ustreza eni celotni zahtevi.