-
Notifications
You must be signed in to change notification settings - Fork 5
Resend requests
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
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.