Alex Rousskov wrote:
It is not safe in general because there are examples where callout
server might want to reorder message content (e.g., change the
parts order of a multipart e-mail message or move an ad banner to
the end of an HTML page). To make it safe, we would have to
explicitly document this assumption (and, hence, prevent copying
optimization in those rare(?) cases where callout server needs to
change the order of message parts).
Yup, see your point, agreed.
Question is whether added complexity to deal with such rare(?) cases
is justified, or whether we believe that it might be OK to keep it
less complex. Anyone any thoughts on that?
The OPES processor will stop reading incoming data when its buffers
are full. That's how most proxies (and servers) I know work today.
One can always control its input, relying on transport protocol to
slow down the producer (TCP) or to drop packets (UDP).
When deadlock occurs, the OPES processor is not reading incoming
data because its buffers are full, and the callout server is not
sending any data back because it waits for more incoming data to
make a decision.
There are buffers at different levels, and I was *not* refering to TCP
buffers or so, but rather to the buffers that temporarily store the
application message, assuming the OPES processor would still be able
to receive TCP/UDP packets, but just no longer be able to temporarily
store the appliction message (or parts of it). In that case, wouldn't
the current protocol design already include everything that's needed?
Example: The OPES processor starts receiving an application message
(e.g. from a Web server). Since it still has buffer available, it
copies the application message and indicates this to the callout
server by setting the [copied] flag. If the buffer at the OPES
processor now fills to, let's say, 90%, the OPES processor keeps
forwarding the received application messages to the callout server,
but no longer stores them in its local buffer. This is indicated to
the callout server by *not* setting the copied flag in subsequent
callout messages. As such, no deadlock occurs. What's missing?
Thanks,
-Markus