On Thu, Jun 5, 2014 at 2:59 PM, Ted Ross <[email protected]> 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
