Function request_within 

pub fn request_within(
    ctx: &ServiceContext,
    peer: &str,
    msg: &Message,
    secs: i64,
) -> Result<Message, Error>

Ask peer for something and wait up to secs for the answer.

Blocks until the reply arrives or the deadline passes. Not cancellable: the deadline is the only bound, which is why it is a parameter rather than a constant.

Authority: uses this task’s send capability for peer. When it holds none, or a stale one, it asks the kernel’s name directory for a fresh one (AcquireSendCap), which the kernel grants only to a task whose spawn request declared peer or that holds ACQUIRE_ANY - see the module header.

If the peer restarts while the request is in flight, the send fails rather than vanishing, and this reacquires the peer by name and sends once more - so an ordinary restart is invisible to the caller, which is what §14.3 asks of every client. If the peer dies AFTER receiving the request, the kernel wakes this call with ReplyDead and you get Error::PeerDied, not re-sent, because the work may have been done.

Errors

• Error::Unreachable - the request never left, twice, or the name could not be reacquired between the two. Nothing happened.
• Error::Busy - the peer’s queue is full. Nothing happened.
• Error::OutcomeUnknown - no reply in time. It may have happened.
• Error::PeerDied - the request reached the peer and it died before answering (ReplyDead). It may have happened. Not retried here; a caller whose operation is safe to repeat reacquires and asks again itself.