Լրիվ երկկողմանի հոսք և հետճնշում SOCKS ռելեում
Կառուցեք ռելեի հոսքը անկախ բայթային հոսքերի, մասնակի I/O-ի, սահմանափակ բուֆերների և հետճնշման շուրջ, այլ ոչ թե գուշակված պատասխանի չափերի։
SOCKS ձեռքսեղմումը հաջողվեց։ Այժմ ռելեն կարդում է հաճախորդից, գրում նպատակակետին, սպասում ամբողջական պատասխանի և միայն դրանից հետո նորից կարդում հաճախորդից։ Այդ հաջորդականությունը կարող է փակուղի բերել միանգամայն վավեր հավելվածը։
TCP թունելը հաստատվելուց հետո SOCKS-ը չի սահմանում դրա ներսի հաղորդագրությունները։ Նպատակակետը կարող է առաջինը ուղարկել։ Երկու կողմերն էլ կարող են ուղարկել անկախ։ Մի կողմը կարող է ուղարկել կարճ գրառում և հետո սպասել մյուսի պատասխանին։
Փոխանցեք բայթեր, ոչ թե գուշակված գործարքներ
Ընդունման կանչը վերադարձնում է հասանելի բայթերը՝ համաձայն իր դրոշների և սոքեթի վիճակի։ Այն ընդհանուր ռելեին չի ասում, որ հավելվածի պատասխանը ամբողջական է։ Կամայական մեծ բուֆերի լցվելուն սպասելը կարող է խանգարել ուղարկել այն փոքր հաղորդագրությունը, որն անհրաժեշտ է գործընկերոջը շարունակելու համար։
Երկու ուղղություններին սպասարկելու համար օգտագործեք հավելվածի գոյություն ունեցող զուգահեռականության մոդելը՝ իրադարձությունների հանգույց, ասինխրոն I/O կամ այլ գիտակցաբար ընտրված ձևավորում։ Կարևոր վարքագիծն այն է, որ մի ուղղությամբ առաջընթացը չի պահանջում հորինված հաղորդագրության սահման մյուսում։
Պահեք երկու սահմանափակ սպասող բուֆեր
Հաճախորդից կարդացված տվյալները դեռ կարող են սպասել նպատակակետին հասնելուն, մինչդեռ նպատակակետից եկած տվյալները սպասում են հաճախորդին հասնելուն։ Հետևեք այդ սպասող բայթերին առանձին։
Ուղարկումը կարող է գրել ավելի քիչ բայթ, քան պահանջվել է։ Պահեք չգրված մասը. մի՛ դեն նետեք այն և մի՛ վերարտադրեք ամբողջ բուֆերը։ Ժամանակավորապես չգրվող սոքեթը պատճառ է սպասելու ճիշտ պատրաստականության իրադարձությանը, ոչ թե անընդհատ պտտվելու։
Սահմանափակեք բուֆերները։ Եթե նպատակակետը դանդաղ է, անսահմանափակ հաճախորդային տվյալներ կարդալը պարզապես հերթը տեղափոխում է ռելեի հիշողություն։ Հետճնշումը նշանակում է կասեցնել ընթերցումները, երբ համապատասխան սպասող բուֆերը լցված է, և վերսկսել, երբ գրառումները տեղ են ազատում։
Մեկ ուղղությամբ ավարտը քաղաքականություն է պահանջում
TCP-ն կարող է փակել ուղարկման ուղղությունը, մինչ մյուս ուղղությունը դեռ ունի օգտակար տվյալներ։ Որոշեք, թե ինչպես փոխանցել այդ վիճակը բուֆերացված բայթերը սպառվելուց հետո, և տարբերեք կարգավորված փակումը սխալից կամ ժամկետից։
Այս ամենը չի պահանջում, որ ռելեն վերծանի կամ վերլուծի հավելվածի բեռը։ Դրան անհրաժեշտ է հոսքի ճիշտ մշակում։ Միայն բուֆերի չափը մեծացնելը չի կարող շտկել ռելեն, որը սպասում է սխալ կողմին կամ ենթադրում է, որ յուրաքանչյուր ընթերցում համապատասխանում է մեկ ամբողջ հարցման։