On 04/18/2013 06:21 AM, Rafael Schloming wrote:
I spoke a bit too soon in my first reply. The tracking windows are
*supposed* to be measured from the point where the tracker is first
assigned, so from when you call put or get. This means that it shouldn't
matter how many times you call recv or how much credit recv gives out, the
only thing that matters is whether you've called get() more than WINDOW
times. That should be fine as calling get() is very much in your control.
Now the reason I was confused yesterday is that from looking at the code it
appears that due to a recent commit, incoming trackers are actually
assigned earlier than they should be. This has not been the case for any
released code, however, only for a short time quite recently on trunk.


On Wed, Apr 17, 2013 at 2:26 PM, Rafael Schloming <r...@alum.mit.edu> wrote:

That's a good question and now that you mention it nothing prevents it.
That was an intentional choice when the feature was added, and it wasn't a
problem at the time because we didn't have recv(-1). This meant that you
were always asking for an explicit amount and if you asked for more than
your window, you were (hopefully knowingly) asking for trouble. With
recv(-1), however, you are no longer explicitly controlling the credit
window so this could be a problem. One possibility might be to define
incoming/outgoing window sizes of -1 to allow for unlimited sizes.


On Wed, Apr 17, 2013 at 1:32 PM, Michael Goulish <mgoul...@redhat.com>wrote:

( a question inspired by a question from a reviewer of
one of my docs... )

If you set an incoming message window of a certain size,
and if Messenger can receive messages even when you, i.e.
call send() - - -  what's to stop some messages from
falling off the edge of that window, and thus getting
accepted-by-default, before your app code ever gets a
chance to make a real decision about the message's disposition ?

I'm still not clear on how this answer the original question: If messages can be received "in the background" when I call send() or other functions, and that can cause messages to fall out of the received window, then how do I ensure that I get a chance to see and ack/reject every message? I have no control over the background message delivery.

A related question: how can I flow control if I'm getting too many messages? The naive answer is "stop calling recv()" but if messages can also be received when I call send() then I have no way to limit the messages that pile up, or worse: that are dropped off my receive window and into oblivion.


Reply via email to