This strategy consumes the elements from a Publisher
one by one, with acknowledgement required for each event.
In this mode the consumer must indicate its readiness to
receive data after every event and the consumer must wait
on that acknowledgement. Technically what this means is that for
each element the consumer needs to do a request(1) call.
This could be the same as FixedWindow(1) (see FixedWindow),
however internally implementations can optimize for stop-and-wait
flow control. For example a buffer is not necessarily required.
Pros and Cons of stop-and-wait strategy:
the implementation can be simpler
versus FixedWindow it doesn't have to wait for the buffer
to fill up, so it's more fair
the producer needs to wait for acknowledgement on each
event and this is a source of inefficiency
This strategy consumes the elements from a
Publisherone by one, with acknowledgement required for each event.In this mode the consumer must indicate its readiness to receive data after every event and the consumer must wait on that acknowledgement. Technically what this means is that for each element the consumer needs to do a
request(1)call.This could be the same as
FixedWindow(1)(see FixedWindow), however internally implementations can optimize for stop-and-wait flow control. For example a buffer is not necessarily required.Pros and Cons of stop-and-wait strategy: