Lees agt grepe en gee dan die SOCKS4-tonnel oor
Vermy om 'n bestemming se groet in te sluk of op nie-bestaande grepe te wag deur die vaste SOCKS4-antwoordgrens te ontleed.
Die SOCKS4-verbindingsversoek slaag, maar die toepassing sien nooit die bediener se openingsgroet nie. Een plek om te kyk is die verbinding se eerste lees. 'n Lees van sestien grepe is te groot vir 'n SOCKS4-antwoord van agt grepe.
| Antwoordveld | Grepe |
|---|---|
| Antwoordweergaweveld | 1 |
| Resultaatkode | 1 |
| Poortveld | 2 |
| Adresveld | 4 |
Die resultaatkode 0x5a dui aan dat die versoek toegestaan is. SOCKS4a verander hoe die versoek 'n gasheernaam dra; dit maak nie die antwoord sestien grepe nie.
Ná die antwoord dra dieselfde TCP-stroom die bestemmingsprotokol. 'n E-posbediener kan sy groet dadelik stuur. 'n Lees wat sestien beskikbare grepe verbruik, kan dus die volledige proxy-antwoord plus die eerste agt grepe van daardie groet neem. As nog niks volg nie, kan 'n te groot blokkerende lees eerder 'n onnodige wag byvoeg.
Presiese lengte is 'n ontleder se verantwoordelikheid
Om een keer agt grepe te vra is nie genoeg bewyse dat agt grepe aangekom het nie. Stroomlesings kan minder teruggee. Versamel presies die antwoord se lengte binne 'n tydlimiet, stop by 'n geslote of mislukte stroom, ondersoek die antwoord, en laat die volgende grepe vir die toepassing.
As die verbinding 'n groter gebufferde lees gebruik, bewaar alles ná die grens en gee dit aan die volgende verbruiker. Om die oorskot te gooi is dieselfde dataverlies met 'n ander leesgrootte.
SOCKS5 het sy eie ontleder nodig. Sy antwoordadres kan verskillende lengtes hê volgens die adrestipe. Om elke proxy-lees met 'n vaste lees van agt grepe te vervang, sou een protokol regmaak terwyl 'n ander breek.