You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.