Re: Deadlocking in the transport

[Mikkel Fahnøe Jørgensen <[e-mail]>]

Blocking at source is not practical if feeding several very large files via
a mmap pointer to the API for deferred round robin transmission so all
files get equal opportunity to get through. In this case only small pieces
could be delivered at a time before the allocation must check if there is
are more transmission credits.


Kind Regards,
Mikkel Fahnøe Jørgensen


On 10 January 2018 at 14.46.36, Ian Swett ([e-mail]) wrote:

I would agree that #4 is the right direction.  GQUIC also does #4, because
it forces all headers to be written before any requests that may depend
upon them are written.

If the application knows there is a dependency, it should be the
application's responsibility to deal with it, not the transport's, which
also points to #4(or maybe #1).

I also think there are use cases for data transfer that is not a stream and
does not consume flow control, but I don't think they solve every problem
and I don't think they should be necessary here.

On Wed, Jan 10, 2018 at 2:05 AM, Dmitri Tikhonov <
[e-mail]> wrote:

> On Tue, Jan 09, 2018 at 10:49:28PM -0800, Jana Iyengar wrote:
> > Protocols that create inter-stream dependency should be able to express
> > that in priorities down to the transport, which I believe is expected to
> be
> > part of the API. I believe that handles this issue, doesn't it?
>
> When it comes to priorities, the QUIC I-D gives implementations
> some leeway [1].  One cannot guarantee that a conforming
> implementation will not deadlock.
>
>   - Dmitri.
>
> 1. https://tools.ietf.org/html/draft-ietf-quic-transport-08#section-10.6
>
>