Let me try one more time to explain the problem with an unrealistic, but I hope 
easy to follow, example. Consider:

A <-> B

Now, imagine A sends a message to B requesting some unit of data. B begins 
sending a very, very large chunk of data to A, many tens of MB. After 10 MB or 
so, A realizes this is not what it expected, so it sends an "abort/close" 
command to B. A then waits for B to close the connection in response to the 
abort/close command. B is multi-threaded, always trying to both receive and 
send concurrently, so it detects the "abort" command and stops sending.

There is no way this can deadlock. Whenever A sends the abort/close, B will get 
it. B never waits for A to receive anything before it receives itself.

Now, interpose your proxy:

A <-> proxy <-> B

Now, A sends the message to B requesting the data. B starts blasting the data 
to the proxy, which you blast to A. Now, A stops receiving the data and sends 
the "abort/close" command. But what happens? Your proxy will not read from A 
until it finishes sending the data it received from B. But A will not call 
'read', it is waiting for the connection to close.

So your proxy will wait forever trying to send to A, when it could make forward 
progress by receiving from A, sending to B, and then handling the connection 
close.

So your proxy breaks a protocol that was unbreakable without the proxy.

This is the easiest to understand breakage. It is not the only way you can 
introduct breakage. A proxy must not ever say "I will not do X until I can do 
Y" when being able to do Y requires someone else doing something. Assuming the 
protocol you are proxying worked in the first place, it was deadlock free. But 
if you introduce additional ordering dependencies (without knowing the existing 
ones) you can introduce deadlocks.

In general, most protocols require a "you must not refuse to receive just 
because you cannot send" rule because this is the rule TCP itself provides. 
Your proxy violates this rule because it uses blocking sends when it has no 
idea whether a receive from that same endpoint would succeed.

DS


______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    openssl-users@openssl.org
Automated List Manager                           [EMAIL PROTECTED]

Reply via email to