Skip to content
This repository has been archived by the owner on Oct 26, 2022. It is now read-only.

Resend requests

Eric Andrews edited this page Apr 24, 2019 · 4 revisions

Resend requests and L1, L2, L3 fullfillment

A resend request is sent by a client to a node to request previously propagated messages of a stream. A client may send one, for example, to fill in gaps (requesting known missing messages), or for historical data needs. Resend requests may concern both recent messages as well as messages far back in history (weeks, months, or even years ago).

Different resend request types allow different temporal conditions to be expressed. The three resend requests currently in use are

  • ResendLast: request the last n messages of a stream
  • ResendFrom: request messages of a stream starting from a specific point in time
  • ResendRange request messages of a stream falling in between two points in time

Fulfilling a resend request

To fulfill a resend request, a node will first try to find the messages from its own local data sources (L1). If this fails, it will contact neighbor nodes and ask them to fulfill the resend request, acting as a sort of proxy in the middle (L2). As a last resort, if the previous steps failed, it will ask a storage node to fulfill this request, again acting itself as proxy in between (L3).

If a node is unable to fulfill a resend request or if no messages are found, it will respond with control message ResendResponseNoResend. However, if messages are found (directly [L1] or indirectly [L2, L3]), the client is notified with control message ResendResponseResending. This will be followed by multiple point-to-point UnicastMessage(s) (one per found message), and finally, the node will end the session by ResendResponseResent.

L1 fulfillment

Diagram of L1 resend

L2 fulfillment

Diagram of L2 resend

L3 fulfillment

Diagram of L3 resend