On Wed, Feb 14, 2018 at 17:39 +0100, you wrote:
> I think your use case is simple enough that we can make a few additions to
> CAF and then implement this in Broker-land. Let me outline a solution here:
Yeah, that sounds like a good plan to me and should make the remaining
parts on the
>> And if you still planned on message routing/auto-forwarding being more
>> widely used, I think you would want to buffer the message while the
>> longest subscribed *path* has a down node?
>
> I was thinking to do the buffering at the routing/hop-level. The
> messsage would get as far as it can
On Tue, Feb 13, 2018 at 12:15 -0500, Seth wrote:
> As a producer:
> As a consumer:
Producer-side it should be easy to enforce limits, but consumer-side
it seems more difficult as it would need either some kind of a
handshake or a notion what data represents a buffered activity. Do you
think
On Tue, Feb 13, 2018 at 11:41 -0600, Jon wrote:
> If the goals is to prevent loss of data, then don't we need more than
> just buffering, like message acknowledgements from the peer?
Yeah, I wouldn't see it as bullet-proof reliability, rather as a best
effort "let's no needlesly drop stuff on
On Tue, Feb 13, 2018 at 10:35 AM, Robin Sommer wrote:
> One more Broker idea: I'm thinking we should add a queuing mechanism
> to Broker that buffers outgoing messages for a while when a peer goes
> down. Once it comes back up, we'd pass them on. That way an endpoint
> could
On 13 Feb 2018, at 11:35, Robin Sommer wrote:
> One more Broker idea: I'm thinking we should add a queuing mechanism
> to Broker that buffers outgoing messages for a while when a peer goes
> down. Once it comes back up, we'd pass them on. That way an endpoint
> could restart for example without
One more Broker idea: I'm thinking we should add a queuing mechanism
to Broker that buffers outgoing messages for a while when a peer goes
down. Once it comes back up, we'd pass them on. That way an endpoint
could restart for example without us loosing data.
I'm not immediately sure how/where