[9fans] IL question?

[9fans] IL question?

[beto]

Hi,

IL does not have any flow control, I know
it was design for RPC type comunication, but if
a user starts writing a lot of data down an IL
connection it would use all kernel memory :-(.

Has this been fixed in Brazil? How?

I don't think it's good idea to add very complex flow control
scheme to avoid this problem. stiloput could check the
noacked queue and limit the number of packets a given user can
have outstanding.

Any comments would be appreciate?

[9fans] IL question?

[presotto]

But the receiver still has the problem...

[9fans] IL question?

[beto]

In <199710171717.NAA18350@cse.psu.edu>
 presotto@plan9.bell-labs.com wrote:

> It wouldn't take much to throw out any il data
> that appears after > 256k of il bytes are in the
> process end queue (or pick your favorite limit).
> You'll still have to process the packets or the
> protocol will break but nothing forces you to keep
> the processed data lying around.
>

thanks.

I think we'll implement something similar to
the tcp->sndfull idea. You keep a counter of bytes
on the ackq and if bigger than some limit it will
sleep. The ackto funtion will wakeup this
process if the number is smaller than half
the limit.

This shouldn't affect RPC performance and the protocol
will work as a pipe too.

[9fans] IL question?

[presotto]

It wouldn't take much to throw out any il data
that appears after > 256k of il bytes are in the
process end queue (or pick your favorite limit).
You'll still have to process the packets or the
protocol will break but nothing forces you to keep
the processed data lying around.

As long as you use the protocol for reply/request, nothing
is changed.  If you try to use it as a streaming pipe, it'll
lose info but won't eat up all of memory.

[9fans] IL question?

[beto]

In <199710170433.AAA03255@sulphur.osf.org>
 Rich Salz <rsalz@opengroup.org> wrote:

> >I don't think it's good idea to add very complex flow control
> >scheme to avoid this problem.
>
> Can't you run over TCP in cases where the lightweight solution isn't
> good enough?
>

I think the fact that IL does not have flow control is not a real
problem because it's use for RPC. However, we are trying to make
the system a little more robust, so I'd like to protect IL for a
miss behaving process which writes a lot of data to the stream.

One of our QA guys decided to test IL and complained about this
problem :-(.

[9fans] IL question?

[Rich]

>I don't think it's good idea to add very complex flow control
>scheme to avoid this problem.

Can't you run over TCP in cases where the lightweight solution isn't
good enough?