Handling of client context for remotely handled messages

[Istemi Ekin Akkus]

Currently, the entire set of workflow functions run in a single application sandbox. As a result, when the first function of the workflow is triggered, the triggering client context is created at the handling sandbox instance.

In the future, it is possible that the client context remains at one sandbox instance, whereas the remaining functions are instantiated at one or more remote sandbox instances. If one such remotely executing function instance is the last one in the workflow, the result cannot be returned to the original client because the remote sandbox does not have the correct client context (i.e., client connection).

Furthermore, in the current state, any session function update message may be redirected to any sandbox instance, which may not necessarily be the one running the session function instances. Although the message can be delivered via the metadata for session function instances, any returned response will fail as described in the above paragraph.

One solution is to make client connection state transfer from the originating sandbox's frontend to the last one, which may not be straightforward to do.

Another solution is to send back the final result to the originating sandbox where the correct client context is still kept. In this proposal, the following would need to be done:

1. For any incoming message, the sandbox frontend attaches its address as metadata to the message (i.e., "__client_origin").
2. Outgoing messages (i.e., results published to "end" topic) are retrieved by the sandbox frontend, which then finds the correct client context. In this case, if there is no such client context, the frontend will check the metadata to find the originating sandbox frontend address. The sandbox frontend will then send a special message to ther originating sandbox frontend (i.e., "X-MFN-Action": "Remote-Result").
3. The originating frontend will handle the special message by extracting the execution id and the result value. It will then look up the correct client context using the execution id and return the response to the client.

Thoughts, comments?

[Ruichuan Chen]

It should work. One comment: since the interaction happens across different sandboxes and even hosts, would it be possible to use service mesh or data layer to exchange metadata (and context)?

…

On Tue, Oct 13, 2020 at 12:37 PM Istemi Ekin Akkus ***@***.***> wrote: Currently, the entire set of workflow functions run in a single application sandbox. As a result, when the first function of the workflow is triggered, the triggering client context is created at the handling sandbox instance. In the future <https://github.com/knix-microfunctions/knix/wiki/Roadmap>, it is possible that the client context remains at one sandbox instance, whereas the remaining functions are instantiated at one or more remote sandbox instances. If one such remotely executing function instance is the last one in the workflow, the result cannot be returned to the original client because the remote sandbox does not have the correct client context (i.e., client connection). Furthermore, in the current state, any session function update message may be redirected to any sandbox instance, which may not necessarily be the one running the session function instances. Although the message can be delivered via the metadata for session function instances, any returned response will fail as described in the above paragraph. One solution is to make client connection state transfer from the originating sandbox's frontend to the last one, which may not be straightforward to do. Another solution is to send back the final result to the originating sandbox where the correct client context is still kept. In this proposal, the following would need to be done: 1. For any incoming message, the sandbox frontend attaches its address as metadata to the message (i.e., "__client_origin"). 2. Outgoing messages (i.e., results published to "end" topic) are retrieved by the sandbox frontend, which then finds the correct client context. In this case, if there is no such client context, the frontend will check the metadata to find the originating sandbox frontend address. The sandbox frontend will then send a special message to ther originating sandbox frontend (i.e., "X-MFN-Action": "Remote-Result"). 3. The originating frontend will handle the special message by extracting the execution id and the result value. It will then look up the correct client context using the execution id and return the response to the client. Thoughts, comments? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#88>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAQSEDB7EJ2JNIP7FVRURRDSKQUVLANCNFSM4SOSSHJQ> .

[Istemi Ekin Akkus]

metadata is attached to each message as it passes through the functions of the workflow.

The interaction is assuming that the originating sandbox is found via some metadata kept by the platform (in this case, the message metadata that's flowing; in the case of session function instances, it's the data layer). That lookup might also happen at the routing layer (e.g., service mesh), but I think that would mix the 'network layer' with the 'platform layer', and may not be ideal, but I may have misunderstood something.

As for the context, I am referring to the client connection information (e.g., TCP state). Not sure whether that's straightforward to transfer at all.

[ksatzke]

Hi Ekin, don’t know if that helps, but the context object recently has been extended to enable a client to transfer information to the function: client_context – (mobile apps) Client context that's provided to Lambda by the client application. o client.installation_id o client.app_title o client.app_version_name o client.app_version_code o client.app_package_name o custom – A dict of custom values set by the mobile client application. o env – A dict of environment information provided by the AWS SDK. So with the above we can already transfer metadata from a client to any function in form of a custom dict. BR Klaus

[Istemi Ekin Akkus]

Yes, we have a similar encapsulation/decapsulation mechanism that includes other metadata that is not exposed to the user code.

The context I am referring to here is the "client connection" (i.e., HTTP request) that was used to start the workflow execution, which is available at the originating sandbox's frontend.