Mailing-List: contact users-help@qpid.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@qpid.apache.org
Received-SPF: pass (nike.apache.org: domain of
 prvs=8234d4f342=rhs@alum.mit.edu designates 18.7.68.20 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <5390BDF4.4000300@redhat.com>
References: <COL131-W220FEAB8F145C0913A5C0AD72D0@phx.gbl>
	<5390BDF4.4000300@redhat.com>
Date: Fri, 6 Jun 2014 09:17:07 -0400
Message-ID: 
 <CACL1BnCmRUTdcA7Wu2bQMFMQ=RKF-hShdoy2FM6ocFjw5UoWXg@mail.gmail.com>
Subject: Re: The waiting game [client sends 0 outgoing size]
From: Rafael Schloming <rhs@alum.mit.edu>
To: "users@qpid.apache.org" <users@qpid.apache.org>
Content-Type: multipart/alternative; boundary=047d7b15a983a7f03004fb2aadcb

--047d7b15a983a7f03004fb2aadcb
Content-Type: text/plain; charset=UTF-8

On Thu, Jun 5, 2014 at 2:59 PM, Ted Ross <tross@redhat.com> wrote:

> Tom,
>
> I'm not sure I understand why the server sets the incoming window the
> same as the client's outgoing window.  Shouldn't the server set the
> incoming window to some value large enough to prevent pipeline-stalling
> and small enough to prevent incoming frames from consuming too much memory?
>
> If your objective is to manage a very large number of clients and you
> don't want to provide incoming capacity until there are messages to be
> sent, I think pn_session_t would need to add something like "set_offer"
> so the sender can indicate that there are bytes/frames to send.
>

I don't think additional API would be necessary here. The session's
outgoing window should be computable based on the state of it's various
links, e.g. if messages are being offered on one or more links, we should
be able to factor that in when we compute the outgoing session window.

Regardless, I don't think using the "available" protocol field in the way
you describe will work in general since it is an optional field. As a
server you need to use a strategy that will work even if available is never
set. The point of the available field is to provide extra information to
distribute credit more optimally, but you can't rely on it as an absolute
signal. For example as a server that has more clients than available
credit, you can revoke credit from idle clients and give it instead to
blocked clients. You can use the information from the available field in
order to pick a blocked client that will definitely be able to use the
credit, but if none of your clients supply that information, you will still
need to ensure that all clients eventually have an opportunity to send.

--Rafael

--047d7b15a983a7f03004fb2aadcb--