Shared usage of a CID via qmi-proxy?

[Aleksander Morgado]

Hey,

> Back in March 2021, Aleksander Morgado wrote on a thread:
> 
> > Using the proxy or not doesn't have a direct relationship with the
> > actual data connection setup. A key point to consider when setting up
> > the data connection using qmicli is that you MUST make sure the WDS
> > client is not released after the Start Network, i.e. you must run
> > --wds-start-network always with --client-no-release-cid, and then
> > reuse the WDS client cid (with --client-cid=CID) in every other qmicli
> > WDS command for that connection setup, even in the --wds-stop-network.
>
> My question is, given that a data call instance is tied to a particular WDS CID, can two clients going through the qmi-proxy share the same CID? One client would setup and tear-down the data call, as needed, as well as query data call status. This client would allocate, but never release, the CID. The second client would only query data call status, using the CID allocated by the first (the first client passes the CID to the second client via an out-of-band mechanism). Both clients would be long-lived.
>
> Is this use case supported by the QMI protocol, generally, and the qmi-proxy, specifically? (Are there any race conditions to worry about?)  Or does each client to the proxy need to have a unique CID allocated?
>
> (If CID cannot be shared, I don't see how two different clients could have the same "view" of the active data call status.)
>

I believe the qmi-proxy forbids that: only one process can take
control of an existing service client id at any given time.

The processes acting as clients to the proxy can exit without
explicitly releasing a managed service client id, and if so the proxy
will store that into a list of "disowned cids". Once a new process
client arrives to the proxy asking to reuse an existing service client
id, it will taken from the list of "disowned cids" and make it owned
again by the new process. This logic maps nicely with the qmicli usage
of the QMI service client ids, assuming no two qmicli run at the same
time for the same client id.

Now, this limitation is imposed by the qmi-proxy but in practice it
could really be removed. The key point here would be to have the proxy
properly track the different transaction id translations between the
QmiClient instances for the same service cid in different process. It
would be a bit convoluted, but technically possible. Not saying I'm
eager to work on that personally, though :)

My suggestion would be to skip that need really. Let the long-running
process that launched the connection also monitor the status of the
same connection.
-- 
Aleksander