[Vortex] Flushing ANS on a channel

[Francis Brosnan Blazquez]

Hi Skye,

> To recap:  In my app, the listener sends a MSG and the initiator sends
> a
> bunch of ANS and a NUL then closes the channel.  (BEEP RAW syslog
> profile).

Ok.

> I'm seeing in practice though, the the listener is receiving a
> variable
> number of ANS messages when the initiator pumps out the ANS messages
> as fast
> as it can.  I assumed vortex_channel_close() would block until all
> queued
> messages were sent, but maybe that's not the case?  

Sure, that's the case. Calling to vortex_channel_close causes to wait
for all pending replies to be received and pending replies to be sent
(see __vortex_channel_close).

> How can I flush/drain
> the pending message queue for a channel?

There is no way to implement a real flush operation on BEEP. But you can
consider some practices to achieve similar results.

The explanation is that pending messages aren't queued in a local cache
due to some performance reason (line console buffers). They are queued
becase remote side do flow control using SEQ frames. So, until the
remote side accepts to receive more frames the sender can do nothing.

Easy alternatives are:

1) updating the channel window size at the listener side
(vortex_channel_set_window_size) so listener can consume faster.

2) or to stop sending more messages until
vortex_channel_is_empty_pending_message returns true at the sending side
so you can control memory usage.

3) or doing nothing ;-), I mean, introduce minimal waits (50ms)
periodically causing vortex to consume its pending work...

> In fact, I'd like to be able to drain the outq periodically anyway,
> because
> I can see if I just send_ans in a tight loop (say a million times) the
> memory usage goes up quite dramatically ;)

This is an issue to consider: you can send as fast as you can, but, if
Vortex can't send them due to remote window size exhausted, all pending
message are held in memory. 

Cheers!

> Thanks,
> Skye
-- 
Francis Brosnan Blazquez <francis at aspl.es>
Advanced Software Production Line, S.L.