Lês acht bytes en jou dan de SOCKS4-tunnel oer
Foarkom dat jo de groetnis fan de bestimming opslokke of op net-besteande bytes wachtsje troch de fêste SOCKS4-antwurdgrins te parsen.
It SOCKS4-ferbiningfersyk slagget, mar de applikaasje sjocht nea de iepeningsgroetnis fan 'e tsjinner. Ien plak om te sjen is de earste lêzing fan 'e ferbiner. In lêzing fan sechstjin bytes is te grut foar in SOCKS4-antwurd fan acht bytes.
| Antwurdveld | Bytes |
|---|---|
| Fjild foar antwurdferzje | 1 |
| Resultaatkoade | 1 |
| Poartefjild | 2 |
| Adresfjild | 4 |
De resultaatkoade 0x5a jout oan dat it fersyk tastien is. SOCKS4a feroaret hoe't it fersyk in hostnamme draacht; it makket it antwurd net sechstjin bytes.
Nei it antwurd draacht deselde TCP-stream it protokol fan 'e bestimming. In mailtsjinner kin syn groetnis fuort stjoere. In lêzing dy't sechstjin beskikbere bytes brûkt, kin dêrom it folsleine proxy-antwurd plus de earste acht bytes fan dy groetnis nimme. As der noch neat folget, kin in te grutte blokkearjende lêzing ynstee in unnedege wachttiid tafoegje.
Krekt lingte is ferantwurdlikens fan 'e parser
Ien kear om acht bytes freegje is gjin genôch bewiis dat acht bytes oankamen. Streamlêzingen kinne minder weromjaan. Sammelje krekt de lingte fan it antwurd binnen in deadline, stop by in sletten of mislearre stream, ynspektearje it antwurd en lit de folgjende bytes oan de applikaasje.
As de ferbiner in grutter bufferare lêzing brûkt, bewarje alles nei de grins en jou it troch oan 'e folgjende konsumint. It oerskot fuortgoaien is itselde dataferlies mei in oare lêsgrutte.
SOCKS5 hat syn eigen parser nedich. De lingte fan syn antwurdadres kin ferskille neffens it adrestype. Eltse proxy-lêzing ferfange troch in fêste lêzing fan acht bytes soe ien protokol reparearje wylst in oar brekt.