[PATCH] libmbim: Add mbim-proxy support
aleksander at aleksander.es
Sat May 24 22:51:43 PDT 2014
On Sun, May 25, 2014 at 3:26 AM, Greg Suarez <gpsuarez2512 at gmail.com> wrote:
> The issue is that one of the OEMs that I'm working with implements a "debug
> trace" service and once it's turned on generates megabytes of data through
> indications in just a few seconds. So I think it would be too much of a
> performance hit to forward so much data to clients that are just going to
> ignore it.
I don't think there is a point in adding the limitation just due to 1
service behaving that way. Actually, if the service is going to
transfer huge amounts of data within MBIM indications, it probably
makes more sense to them to setup a specific DSS session for that,
instead of overflowing the main MBIM communication channel. Also, what
about other unknown services which may expect to have clients listen
to the indications even when the service was not used in advance?.
> And I also believe that the MBIM spec specifies that devices are not
> supposed to send non standard indications unless first requested. Of course
> I could be wrong on this since it's been a while since I've read the spec.
> At least I know the spec for this OEM specifies that.
I'm not sure if that's true in MBIM. It is in QMI; i.e. a client can
register to get notified about a given indication, and can unregister
when it no longer wants them. In the case of MBIM; receiving
indications is not something we can choose or not choose, I believe.
So, by default we should forward all indications.
Another thing, though, is whether we want to include an additional
private command in the proxy service to let clients register or
unregister to some indications. If the client wants to get notified
about only a subset of indications, we can setup a new open-flag to
request that, so that it can then "subscribe" only to the indications
that it wants. Given that this is to be handled by the proxy (i.e. the
communication with the device will still handle all notifications), it
can just be seen as an addon, same as the proxy is. The only problem
with this approach is that then, we're kind of forcing standard
clients to use this logic, so that they don't get bothered with
indications they don't know of...
More information about the libmbim-devel