Полнодуплексен тек и повратен притисок во SOCKS реле

SOCKS ракувањето успеа. Сега релето чита од клиентот, пишува до дестинацијата, чека целосен одговор и дури потоа повторно чита од клиентот. Таа низа може да блокира сосема валидна апликација.

Откако TCP тунелот е воспоставен, SOCKS не ги дефинира пораките во него. Дестинацијата може да прати прва. Двете страни може да праќаат независно. Едната страна може да прати краток запис и потоа да чека одговорот на другата.

Пренесувајте бајти, а не погодени трансакции

Повикот за примање враќа достапни бајти според знаменцата и состојбата на сокетот. Тој не му кажува на општо реле дека одговорот на апликацијата е завршен. Чекањето произволно голем бафер да се наполни може да го спречи пренесувањето на малата порака што на партнерот му е потребна за да продолжи.

Користете го постоечкиот модел на конкурентност на апликацијата за опслужување на двете насоки: циклус на настани, асинхрони I/O или друг намерно избран дизајн. Важно е однесувањето: напредокот во едната насока не бара измислена граница на порака во другата.

Чувајте два ограничени бафери на чекање

Податоците прочитани од клиентот може сè уште да чекаат да стигнат до дестинацијата, додека податоците од дестинацијата чекаат да стигнат до клиентот. Следете ги тие бајти што чекаат одделно.

Испраќањето може да запише помалку бајти од побараното. Задржете го незапишаниот дел; не го отфрлајте и не го повторувајте целиот бафер. Привремено непишлив сокет е причина да се чека правилниот настан за подготвеност, а не постојано да се врти.

Ограничете ги баферите. Ако дестинацијата е бавна, продолжувањето да се читаат неограничени клиентски податоци едноставно ја преместува опашката во меморијата на релето. Повратниот притисок значи паузирање на читањето кога соодветниот бафер на чекање е полн и продолжување кога запишувањата ослободуваат простор.

Крајот во една насока бара политика

TCP може да ја затвори насоката за испраќање додека другата насока сè уште има корисни податоци. Одлучете како да ја пренесете таа состојба откако ќе се исцедат баферираните бајти и разликувајте уредно затворање од грешка или рок.

Ништо од ова не бара релето да го дешифрира или парсира корисниот товар на апликацијата. Потребно е правилно ракување со текот. Зголемувањето на големината на баферот само по себе не може да поправи реле што ја чека погрешната страна или претпоставува дека секое читање одговара на едно цело барање.