Läs åtta byte och lämna sedan över SOCKS4-tunneln
Undvik att svälja destinationens hälsning eller att vänta på byte som inte finns genom att tolka den fasta SOCKS4-svargränsen.
SOCKS4-anslutningsbegäran lyckas, men programmet ser aldrig serverns inledande hälsning. En plats att titta på är anslutningens första läsning. En läsning på sexton byte är för stor för ett SOCKS4-svar på åtta byte.
| Svarfält | Byte |
|---|---|
| Fält för svarversion | 1 |
| Resultatkod | 1 |
| Portfält | 2 |
| Adressfält | 4 |
Resultatkoden 0x5a visar att begäran beviljades. SOCKS4a ändrar hur begäran bär ett värdnamn; det gör inte svaret till sexton byte.
Efter svaret bär samma TCP-ström destinationens protokoll. En e-postserver kan skicka sin hälsning direkt. En läsning som förbrukar sexton tillgängliga byte kan därför ta hela proxy-svaret plus de första åtta byten av den hälsningen. Om inget följer ännu kan en alltför stor blockerande läsning i stället lägga till en onödig väntan.
Exakt längd är parserns ansvar
Att begära åtta byte en gång är inte tillräckligt bevis för att åtta byte har anlänt. Strömläsningar kan returnera mindre. Samla exakt svarets längd inom en tidsfrist, stanna vid en stängd eller misslyckad ström, granska svaret och lämna de följande byten till programmet.
Om anslutningen använder en större buffrad läsning, bevara allt efter gränsen och skicka det vidare till nästa konsument. Att kasta bort överskottet är samma dataförlust med en annan lässtorlek.
SOCKS5 behöver sin egen parser. Längden på dess svaradress kan variera beroende på adresstypen. Att ersätta varje proxy-läsning med en fast läsning på åtta byte skulle laga ett protokoll men förstöra ett annat.