On Thu, 2008-06-05 at 04:26 -0700, TLFox wrote:
>
>
> Arnaud Simon wrote:
> >
> >
> > If it also applies to receive(), and that's my interpretation, we can
> > ack pseudo-asynchronously i.e. the next message transfer could carry an
> > ack flag confirming that the broker has received the previous message
> > acknowledgment. So we don't have to block on the ack before delivering
> > the message to the receiver. Note that when the client lib is
> > pre-fetching messages we only need to deliver the next message after the
> > sync ack of the previous message has returned.
> >
> > Arnaud
> >
> >
>
> Well, in the above, you're still effectively blocking on the ack, but in a
> more roundabout way, since you can't deliver the next message until the ack
> has reached the server then you are given notification of that by the next
> message transfer- I think you're just moving the same issue from one place
> to another.
Let's say that the time to perform a sync is ts and to process the
message tp (I am not taking into account the message transfer time as
messages may be pre-fetched). If we sync before delivering the message
we'll have the following:
=ts= =tp= =ts= =tp= =ts= =tp=
| | |
M1 M2 M3
That means that the overall time to receive and process 3 messages is 3
* ts + 3 * tp
If we wait on the previous message sync we'll then have something like:
=tp= =Max(0, ts - tp)= =tp= =Max(0, ts - tp)= =tp=
| | |
M1 M2 M3
that means that the overall time is 3 * tp + 2 Max(0, ts - tp). That
looks to me faster than the previous scenario. I may be wrong though.
Arnaud
