[PATCH] libmbim: Add mbim-proxy support

[Greg Suarez]

On Fri, May 30, 2014 at 1:04 AM, Aleksander Morgado <
aleksander at aleksander.es> wrote:

> On Thu, May 29, 2014 at 9:15 PM, Greg Suarez <gpsuarez2512 at gmail.com>
> wrote:
> >> Yes. If we get an indication from the device an there wasn't *any*
> >> client configured to receive it, then we should forward it to
> >> everyone.
> >>
> >
> > So now that I've implemented this I've come to realize that there's no
> way
> > to tell the difference between
> > "there's no client configured to receive an indication" vs "a client
> that's
> > configured to not receive any indications
> > from a service"
> >
>
> If I understood it correctly, by default clients will start like this:
>  * Enabled to receive all indications from standard services (those
> defined by MBIM standard).
>  * Disabled to receive any indication from non-standard services.
>

Yes

> Now, the issue is that the configuration of the service subscribe list
> is performed by passing a list of these types:
>
> typedef struct {
>     MbimUuid device_service_id;
>     guint32 cids_count;
>     guint32 *cids;
> } MbimEventEntry;
>
> The client will notify which are the CIDs in a given service for which
> it wants to get notifications. The client needs to provide the full
> list of CIDs per service; those not provided in the list of CIDs are
> to be considered disabled.
>
> Yes

> So, as soon as a client sends
> MBIM_CID_BASIC_CONNECT_DEVICE_SERVICE_SUBSCRIBE_LIST, the modem will
> (should) only provide indications for the CIDs listed there. The task
> of the proxy, therefore is to track which CIDs were enabled by each
> client, and build its own
> MBIM_CID_BASIC_CONNECT_DEVICE_SERVICE_SUBSCRIBE_LIST with the mixed
> lists of CIDs from all clients.
>

Yes, and the proxy also needs to keep all the indications for the standard
services enabled because
when a client connects it expects to receive indications for standard
services without having to
send the MBIM_CID_BASIC_CONNECT_DEVICE_SERVICE_SUBSCRIBE_LIST.


>
> Regarding your point, yes, it is tricky. If we have e.g. 3 clients and
> all of them used MBIM_CID_BASIC_CONNECT_DEVICE_SERVICE_SUBSCRIBE_LIST
> with an empty list (so that they request not to receive any
> notification), and still we get a notification from the device, I
> really believe we should still forward it to all clients. Same if we
> had 3 clients each with its own list and we get a notification which
> is not in any list; we should still forward it to all clients. I'm not
> sure whether the proxy should try to 'fix' a wrong behavior of the
> modem, if it ever happens. Sure, this logic may never be used if all
> modems do it correctly, but not sure. Anyway, I have mixed feelings
> about this...


I was also thinking of the standard services indications since I always
have them enabled.
I guess I could filter out the standard services indications when trying to
figure out if the indication is errant
and needs to be forwarded anyways.


> So, what I'm suggesting is the following:
>
> > So what I'm doing is if a client has sent the
> > MBIM_CID_BASIC_CONNECT_DEVICE_SERVICE_SUBSCRIBE_LIST
> > it will only receive indications from that list.
>
> Yes, unless there is an indication coming which isn't by default
> enabled in any client. If there is an indication not configured by any
> client, then it should go to all. Clients need to be prepared to
> receive indications they didn't ask for (as in no crash, just ignore
> them).
>

I was more concerned with the wasted cpu cycles than anything else :P

>
> > A client will receive all indications if the client has never sent the
> > MBIM_CID_BASIC_CONNECT_DEVICE_SERVICE_SUBSCRIBE_LIST
> > command or sends the command with no elements, which clears out the list.
>
> If the client has never sent the SUBSCRIBE_LIST command, it should
> always get the indications for the standard services. If it sends the
> command with no elements, shouldn't we assume that it is trying to
> disable all indications?

oh... yeah... whoops :P

Thanks,

Greg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/libmbim-devel/attachments/20140530/ce3644ab/attachment-0001.html>