Re: Split error codes in two

[Martin Thomson <[e-mail]>]

I think that you just managed to change my mind...

On Tue, Sep 26, 2017 at 9:43 AM, Mike Bishop
<[e-mail]> wrote:
> Yes, we have -- which is why I suggested we go ahead and define one, albeit perhaps just a reference API.  I'm not convinced an upcall is necessary -- swallowing unsent data and notifying the app if it attempts to send more is probably sufficient.  But the distinction between the two *would* be an API design decision.

Actually, that would be a protocol decision.  STOP_SENDING could cause
a state transition and cause the stream to become reset, but it
creates some nasty side effects.

> And I would argue that if a generic QUIC stack needs to have a mechanism to transfer multi-gigabyte messages, it also needs to have a way to forestall reading the entirety of those messages.  (Although we already do have the ability to choke off flow control until the application realizes it's supposed to RST_STREAM, I suppose.)

This is the point that I think is convincing.  Ignoring what we might
ask an application layer to do (or not), operating purely at the
transport layer, if the reader closes, then it won't send flow control
credits.

That is, it could (and direct the pipe to /dev/null), but I don't
think that we've provided the right incentives.  Redirecting to
/dev/null is costly for both sides, so I see little reason for them to
do that.  The result is therefore most likely a deadlock.

That's the clincher for me.  If the transport at the reader doesn't
read, then the writer can't write and we end up with streams that are
deadlocked until the application resolves it.  I don't mind if the
application wants to insert itself (the upcall suggestion), but I
think that a transport-layer function forces the transport to
recognize this problem and deal with it.