Oh! Oh! Let me try! (see inline)
----- Original Message -----
> 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.
> > --Rafael
> > 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.
> >> --Rafael
> >> 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
> received "in the background" when I call send() or other functions, and that
> cause messages to fall out of the received window, then how do I ensure that
> get a chance to see and ack/reject every message? I have no control over the
> background message delivery.
First, just to be clear, it's not in the background in the sense of
a separate thread, it's just ... 'unexpectedly'.
But the main thing is .. .that is not a *received* window.
If you set a window size of N, that window exists only
relative to the position of the first message for which you
create a tracker.
Creating a tracker is done not with recv() but with get(),
and the window only exists in the get-space. Not in the
So the only way to make a message fall off the window is to:
0. define incoming window size N
1. call get()
2. make a tracker ( will track starting with most recent message got() )
3. call get() N more times, but don't both to dispose the messages one
way or the other.
4. You just had 1 message fall off the edge of your window, and
get accepted by default.
5. If you keep calling get() now, you will have 1 new message fall
over the edge for each call.
> A related question: how can I flow control if I'm getting too many messages?
> naive answer is "stop calling recv()" but if messages can also be received
> I call send() then I have no way to limit the messages that pile up, or
> that are dropped off my receive window and into oblivion.
Don't know. Brain tired.
I think you can't -- but at least they won't fall
out the window.