Extended 0212-pickup with 0032-message-timing decorators

[PavelMinenkov]

trafficstars

Signed-off-by: Pavel Minenkov [email protected]

[TelegramSam]

Can you describe the use case(s) driving this addition?

In my mind, a retrieving agent would always want messages back immediately, without waiting for more messages to come in. What cases am I not understanding?

[PavelMinenkov]

This addition does not affect on time of delivery, retrieving agent will catch forwarding messages immediately. This extension affects on max time retrieving agent is ready to await.

If retrieving agent notify "pending_timeout": X it means recipient asks to not schedule messages after "pending_timeout" occured

• Case-1: Load-Balancing. Mediator may have multiple queues inside multiple downstream connections for single recipient. Every queue is filling from Kafka, RabbitMQ, Redis Streams, etc. "pending_timeout" may help to optimize scheduler

• Case-2: Mediator delivery messages (according same scheme: https://github.com/hyperledger/aries-cloudagent-python/blob/main/Mediation.md#mediator-message-flow-overview) via same duplex channel (websocket connection with endpoint="didcomm:transport/queue" ). If mediator serve other services besides message forwarding, will occure conflicts among parts of code that utilize same connection resource. For example, retrieving agent may utilize same websocket connection for both RFC-0211 and RFC-0212 protocols. Would be nice to resolve this conflicts in time, so delivery party should be notofied what kind of RFC is operating over command channel (it may be crytical for return_route = "all")

[andrewwhitehead]

I believe this is covered by the timing decorator stale_time and/or expires_time properties: https://github.com/hyperledger/aries-rfcs/tree/main/features/0032-message-timing

[PavelMinenkov]

I believe this is covered by the timing decorator stale_time and/or expires_time properties: https://github.com/hyperledger/aries-rfcs/tree/main/features/0032-message-timing

@andrewwhitehead thanks for comment, it is usefull and I should confess ignoring of 0032 decorators was my mistake. I propose use delay_milli parameter with arguments below:

• it is assumed stale_time and expires_time properties have absilute time value it may have side-effects if some of agent has error in timezone configuration
• on other hand, pickup request delegate operation to message_holder, so delay_milli has minimum 2 advantages: a. it started at moment request was delivered by messages_holder so no problem with timezones and ext timing synchronizations b. message_holder has control how to fill queue so delay_milli parameter make sense for it

[PavelMinenkov]

Can you describe the use case(s) driving this addition?

In my mind, a retrieving agent would always want messages back immediately, without waiting for more messages to come in. What cases am I not understanding?

Cases:

• message_holder has 10 messages in the queue. recipient requested batch with batch_size = 3. message_holder will return batch with 3 messages and 7 messages continue to keep
• message_holder has 10 messages in the queue. recipient requested batch with batch_size = 30. message_holder will return batch with 10 messages and queue will be empty
• message_holder has 10 messages in the queue. recipient requested batch with batch_size = 30 and ~timings.delay_milli = 3000 (3000 msec) message_holder delay response cause of it queue has not size corresponded for 30 requesting size, suppose message_holder received 5 messages within 3000 msec, so it will respond with 10+5=15 messages in response
• message_holder has 0 messages in the queue. recipient requested batch with batch_size = 30 and ~timings.delay_milli = 3000 (3000 msec) message_holder did not receive any messages within 3000 msec so it will return empty messages list.

[swcurran]

Discussed on the Aries Working Group call on 2023.06.28 and there was agreement that this can be merged. There are some cleanup typos to be made before merging, that I'll highlight in a couple of extra comments.