Denis Perchine <dyp@perchine.com> writes:
> This is the result of my 6 days "war" with Linux kernel people...
> Any usefull comments on this????
The Linux people seem to be assuming (erroneously) that application
protocols are strictly I-send-and-then-you-send. That's too
restrictive, and in fact it falls down in exactly the case that
we're seeing in libpq: one side of the connection may send an
error message "out of turn" and then close the connection. If the
other side of the connection was busy sending, the first thing it
will get is an EPIPE error on its send. By closing the connection
*AND DISCARDING VALID USER DATA* at this point, the Linux kernel
makes it impossible to retrieve the error message --- which might
have contained essential information.
> In Linux scheme you know forward that stream is aborted.
> Depending on protocol you may choose to abort protocol
> or to continue to operate, parsing already received messages.
But what about the messages you didn't get yet, but the other end
sent in good faith? There's nothing in the TCP specs that says
a program can't close its end of the connection as soon as it has
sent the last data it intends to send.
>> But not other way around...
> You have just seen a new way around. The correct one. 8)
No, just a new half-baked excuse for doing things wrong. The kernel at
the other side of the connection accepted the data for delivery. That
means that both sides of the connection are going to make their best
efforts to deliver it. By willfully failing to deliver that data, the
Linux kernel is violating the fundamental premise of TCP (or any other
reliable byte-stream protocol). This is not "correct", it is broken.
Do I need to quote RFC chapter and verse at you?
regards, tom lane