Re: disallowing concurrent calls to hanging get?

[Alice Neels]

+tq-fidl might have insight here.

On Fri, Apr 16, 2021 at 3:23 PM Mukesh Agrawal <qui...@google.com> wrote:

Hi API Councilors,

I have a hanging get API, and servers implementing that API are only expected to allow a single pending request at a time.

Do we have any advice on how such servers should handle clients that submit concurrent hanging gets in such a case?

The couple of options that my reviewer  (+Alice Neels) and I have discussed are

1. Close the connection.
2. Silently drop the first request.
3. Resolve the first request by sending the caller the current state (even though the state is unchanged).

I'm wondering if we have any advice about how to choose between these, and/or if there are other options we should consider as well.

Thanks,

Mukesh

--

Our nation’s summers of riots are caused by our nation’s winters of delay. (MLK)

[Adam Barth]

I'd recommend closing the connection and logging an error.  The client has violated the state machine of the protocol.

Adam

[Wez]

+1 to Adam's recommendation.

In Chromium, for example, the MediaPlayer protocol implementation reports an error and disconnects the client if they call WatchInfoChange() while a prior call is already pending: https://source.chromium.org/chromium/chromium/src/+/master:fuchsia/engine/browser/media_player_impl.cc;l=107

--
You received this message because you are subscribed to the Google Groups "api-council" group.
To unsubscribe from this group and stop receiving emails from it, send an email to api-council...@fuchsia.dev.
To view this discussion on the web visit https://groups.google.com/a/fuchsia.dev/d/msgid/api-council/CAP%3D28cc0J5%2BCKAhoX8cYtwKRwEARarGXFY94zuSTauQuNFYsYQ%40mail.gmail.com.

[Marie Janssen]

Typically in our APIs we close the channel, potentially with an epitaph of ZX_ERR_BAD_STATE.

Marie Janssen |

Bluetooth Sourceress |

jam...@google.com |

Google, Inc.

[Jody Sankey]

I would say in the cases where we close the channel for a state machine violation, we should also clearly document that clients are only expected to make a single pending request at a time. For example in fuchsia.media.sessions2.Player.WatchInfoChange() I don't see any mention of that fact.

This is an example of my general worry bead from RFC-0002 that there are a lot of usage constraints and semantics baked inside an ABI and we often don't include enough information in our protocol documentation for someone (say someone in a different organization) to use the interface in the way that we were expecting/intending/requiring.

--

You received this message because you are subscribed to the Google Groups "api-council" group.
To unsubscribe from this group and stop receiving emails from it, send an email to api-council...@fuchsia.dev.

To view this discussion on the web visit https://groups.google.com/a/fuchsia.dev/d/msgid/api-council/CAJLTA8iiUYgYv3%3D%2BTrAH_%2BmzR2BabAdp5sJuk5ky94_9a-4_dw%40mail.gmail.com.