Как правильно передать TCP-трафик между сокетами?

Question

Я пытаюсь написать код Python, который установит невидимое реле между двумя сокетами TCP. Мой метод состоит в том, чтобы настроить два потока, каждый из которых считывает и впоследствии записывает 1kb данных за раз в определенном направлении (то есть 1 поток для A-B, 1 поток для B-A).

Это работает для некоторых приложений и протоколов, но не является надежным - иногда отдельные приложения будут вести себя по-разному при использовании этого Python-реле. Некоторые даже сбой.

Я думаю, что это связано с тем, что, когда я заканчиваю выполнение чтения на сокете А, программа, работающая там, считает, что ее данные уже достигли Б, когда на самом деле я - коварный человек посередине - еще не отправил это к B. В ситуации, когда B не готов к получению данных (в течение которых блокирует send()), мы находимся в состоянии, когда A считает, что оно успешно отправило данные в B, но я все еще держу данные , ожидая вызова send(). Я думаю, что это причина различия в поведении, которое я нашел в некоторых приложениях, используя мой текущий ретрансляционный код. Я что-то пропустил, или это звучит правильно?

Если это так, мой настоящий вопрос: есть ли способ решить эту проблему? Можно ли читать только сокета А, когда мы знаем, что B готов к приему данных? Или есть другой метод, который я могу использовать для создания действительно «невидимого» двухстороннего реле между [уже открытыми установленными] TCP-сокетами?

Answer 1

Можно читать только из гнезда А когда мы знаем, что Б готов получить данные?

Sure: использовать select.select на обоих сокетов А и В (если она возвращает говоря только один из них готов, использовать его на другой), и только для чтения от А и писать B, когда вы знаете, что они» оба готовы. Например:

import select 

def fromAtoB(A, B): 
    r, w = select.select([A], [B], []) 
    if not r: select.select([A], [], []) 
    elif not w: select.select([], [B], []) 
    B.sendall(A.recv(4096)) 

Answer 2

Я не думаю, что это может быть вашей проблемой.

В общем случае приложение-отправитель не может определить, когда приложение-получатель фактически вызывает recv() для чтения данных: отправитель() может быть выполнен, но реализация TCP в исходной & целевых ОС будет выполнять буферизация, управление потоком, повторная передача и т. д.

Даже без вашего реле в середине, для того, чтобы «рассмотреть свои данные, которые уже достигли B», это получить ответ от B, говорящий «да, я понял".

Answer 3

Возможно, приложение, к которому выполняется проксирование, плохо написано.

Например, если я звоню recv(fd, buf, 4096, 0); Я не обещал 4096 байт. Система прилагает все усилия для ее обеспечения.

Если 1k не кратно размеру вашего приложения recv или send, а приложение будет разбито, то группировка данных, отправленных в 1k-блоки, приведет к поломке приложения.