This nearly covers the issue I was raising, and most likely addresses
the major use case.
I was envisaging multiple sessions over the same connection, possibly
with different priorities and flow control needs. The question shifts
from "when is it a good time to send messages on this session" to
"when is the connection output buffer ready for a new message (from
any session)". The PN_TRANSPORT event you suggest is actually session
agnostic and could form the role here as well. pn_transport_pending()
could serve to decide when to add more messages to the connection's
output stream.
The right value of a high/low water mark would vary a lot between an
8Gig network and some low power wireless transport.
If we did not generate PN_TRANSPORT events by default, many
applications would run just fine and not pay the price of ignoring
them. Those that wanted them could perhaps register for them.
Or, assuming the application knows whether it is a large hub server or a
webcam, perhaps it could inform Proton appropriately and register what
it thought was the low water mark via an api call:
pn_transport_set_low_watermark(t, n_bytes);
which would be edge triggered when the buffer transitioned from above
the watermark to below.
Or the Application could just tell Proton each time it is interested in
a low watermark event.
void send_available() {
/* ... */
/* try_to_send returns false because we hit high water mark,
which leads to: */
/* Message not sent, leave on available list for next send_available() */
/* and... */
pn_transport_notify_pending_less_than(t, n_bytes)
Which fires exactly once, either on the transition, or "soon" if
transport_pending is currently less than n_bytes.
I acknowledge that the saner approach in most cases might be to have
separate connections to manage complicated session link priorities and
that it may not really be too onerous to generate a transport event
whenever the output buffer shrinks.
Cliff
On Thu, Oct 27, 2016 at 1:35 PM, Alan Conway <acon...@redhat.com> wrote:
> Cliff has been bugging me about transport events, sending messages and
> memory bounding for ages and the penny finally dropped, I think it
> deserves a wider audience:
>
> The issue is bounding memory use in a proton sending application. AMQP
> flow control (as shown in our examples) covers many/most cases
> providing the receiver sets a "reasonable" credit limits.
>
> However, on the sender, if the receiver sets infinite credit, or has a
> much bigger notion of "reasonable", proton will buffer messages without
> regard to sender constraints. It is quite plausible that
> receiver/sender have very different memory constraints - one might be a
> large hub server, the other embedded on millions of small devices
> (webcams for example)
>
> The `on_sendable` or PN_FLOW event tells you the remote end has given
> credit, so you can write a sender that waits for credit before sending.
> I think we can use the C PN_TRANSPORT event in a similar way to limit
> sender memory. Attached is a C example/explanation.
>
> Some of our language bindings don't expose TRANSPORT and we might want
> to think of a more intuitive way to express this. Also TRANSPORT is a
> bit of a catch-all event, it does fire when data moves from session to
> transport buffers, but it fires for other things too. We might want to
> look at the event model.
>
> Meantime I think the attached is a workable approach in C. Would love
> to hear comments, this is something we probably should incorporate into
> the language bindings
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
> For additional commands, e-mail: users-h...@qpid.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org
