Re: message disposition question
On Tue, Apr 23, 2013 at 10:09 AM, Michael Goulish wrote: > 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 > 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 > > >> 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. > > > 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 > recv space. > > 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? > > 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. > > > Don't know. Brain tired. > I think you can't -- but at least they won't fall > out the window. > Not calling recv() should be sufficient. Just because messages might arrive in the background due to previously issued credit, doesn't mean the implementation will issue new credit in the background of its own volition. That means if you stop calling recv() one way or another you'll run out of incoming messages eventually. --Rafael
Re: message disposition question
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 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 > >> 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. 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 recv space. 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? > 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. Don't know. Brain tired. I think you can't -- but at least they won't fall out the window. > > Cheers, > Alan. >
Re: message disposition question
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 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 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. Cheers, Alan.
Re: message disposition question
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 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 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 ? >> >> >> >
Re: message disposition question
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 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 ? > > >
message disposition question
( 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 ?
