Re: Split error codes in two

[Martin Thomson <[e-mail]>]

On Thu, Sep 14, 2017 at 12:40 AM, Lubashev, Igor <[e-mail]> wrote:
> Thinking about this a bit more, it seems that the key difference between
> “tcp socket” and “two pipe pairs” models is independence of the send and
> receive directions.

I prefer Christian's analogy of streams as messages.  That's what
motivated the design that I proposed.  Then you don't get "pipe pairs"
you get "messages and (optionally) response messages".

On Thu, Sep 14, 2017 at 5:03 AM, Roberto Peon <[e-mail]> wrote:
> So many RPC models have failed utterly because they couldn’t handle
> receiving the data in a streaming fashion.

That doesn't invalidate the streams-are-messages model, it just
recognizes that the messages cannot be sent and received as a single
unit (unless they are 0 length, I guess).  Flow control, multiplexing,
etc, etc...

~

I want to come back to the original question in light of what we learned:

 -> what is the transport going to **do** with a STOP_SENDING?

I can't think of anything other than to tell the application.  That
makes the answer pretty clear to me.

I don't think that this discussion - valuable as it is been - has
changed my position on this much.  Ideally I would like to enable all
the various viewpoints on the question to be equally valid.  Building
a protocol that can provide something that looks like a TCP socket is
challenging though, because the complete close of a coupled pair
cannot be done generically - I think that we all agree that this is
impossible in the general case.

I can appreciate the desire to build some of the pieces that might be
needed to build a bidirectional close, but I think that is more
dangerous than useful and would prefer to leave this to application
protocols.