Non-blocking asynchronous/synchronous in multihop scenario
According to specs, diagrams 8.2.2.3-1 in TS-0001 (asynchronous) and E.2.2-2 in TS-0004 (synchronous) indicate that non-blocking communication mode is used in all hops if the originator requests to use it in the original request (the responseType parameter of the original request is forwarded in the forwarded request. There are several issues with this approach, besides the fact that an originator should not determine the communication mode between its Registrar CSE and next hops. The issues are:
- resources are created in all hops up to the target CSE
- in asynchronous mode, it is not specified when intermediate resources can be deleted (despite expiration time).
- it is not specified when the requestStatus attribute of the resource is updated to COMPLETED for transit CSEs (table 7.3.2.5-2 of TS-0004). In synchronous mode, this means that the originator will always get requestStatus indicating FORWARDED when trying to retrieve the result of the operation
In addition, the actual approach introduces extra load to all hops up to the target CSE.
Proposal
NOT to forward the responseType parameter of the original request, which means that the communication mode is determined hop by hop. Any transit CSE will determine the communication mode to be used to forward the request to the next hop, which is transparent to the initial originator (as a black box). That communication mode can be whatever (blocking, non-blocking, long polling, CMDH, etc) and is determined and requested by each transit CSE. The following diagram depicts this proposal (for asynchronous mode):