Re: Two quick questions about the new whitelist functionality

[Ludovic Ferrandis <ludovic ferrandis intel com>]

On 28/08/2013 11:52, Mark Ryan wrote:
> Hi All,
>
> I've had a quick look at the new whitelist code in GUPnP this morning
> and I have a few questions:
>
> 1. If my whitelist is enabled and contains one network, say network A, I
> don't get a context available notification when I join network B.
> Similarly, I don't get a context unavailable if I leave network B.  Now,
> if my whitelist is disabled and I join network B, I do get my context
> available notification as expected.  However, if I then enable the white
> list to filter out network B, I get service and device unavailable
> notifications but I do not get a context unavailable notification unless
> I leave network B.  I can't see this causing any problems but I was just
> wondering if this is the intended behaviour.

Complex issue. I will try to give a clear explanation.

GUPnPContextManager doesn't manage context un/available notification, 
nor the list of context.
It's done by derived class, Linux/Unix/ConnMann Context Manager.

In ContextManager we could block the available notification, and defer 
it later if needed (as everything is ready in sub classes), but we could 
not send unavailable notification as we don't have access to underneath 
classes. The unavailable notification is sent when sub classes have 
clear the context.

So there are 2 solutions:
1 - Block available context notification when possible.
2 - Never block available notification.

You perfectly describe case 1. It has sometimes 'asymetric' behavior.
But the main and really important part of this solution, is that it has 
no impact on current applications.

Now case 2.
The main issue with this solution, is we need to change code to current 
applications to be clean.
I'll take dleyna code as example. When we receive the available 
notification we do:

cp = gupnp_control_point_new(
        context,
        "urn:schemas-upnp-org:device:MediaServer:1");

g_signal_connect(cp, "device-proxy-available",
                 G_CALLBACK(prv_server_available_cb), upnp);

g_signal_connect(cp, "device-proxy-unavailable",
                 G_CALLBACK(prv_server_unavailable_cb), upnp);

gssdp_resource_browser_set_active(GSSDP_RESOURCE_BROWSER(cp), TRUE);
gupnp_context_manager_manage_control_point(upnp->context_manager, cp);

We set the callback for device notification and we activate the browser 
before to give the control of the control point to the context manager.
That means we will receive the device available notification and then 
the unavailable notification.

Note: In this case, we should update 
gupnp_context_manager_manage_control_point to use the whitelist 
filtering function. This is not currently the case.



> 2. I suspect the code in gupnp-context-manager.c:on_context_unavailable
> might be doing more rescans than necessary.
>
> Let's suppose:
>
>    - I have 3 SSIDs, A, B and C, each of which is running a DMS.
>    - I have a whitelist containing A and B.
>    - I have three control points, one for each context
>    - My whitelist is enabled.
>    - I disable the whitelist
>
> I could be reading the code wrong here, but it seems that
> on_context_unavailable will do an unnecessary rescan on the control
> points for networks A and B.  This control points are already active so
> the rescan isn't necessary.  Also, if we set a control point to active
> is there any need to invoke a rescan?  Doesn't the effect of
> transitioning from non-active to active send out all the broadcast
> messages?  So I was wondering if we could we just remove the call to
> gssdp_resource_browser_rescan or is this needed for some reason?

Probably no more needed. Old code during refactoring. I could not 
remember the use case.
I just perform new tests. Even if we call the function, the rescan is 
not always done (result = false).
It works well without, so I will provide a fix.


For general purpose info, why this design?
There was 2 solutions. The current one or to include the current 
GUPnPWhiteList code directly into Context Manager.
I choose this solution based on information I got during preliminary 
discussions for this feature. It was mentioned that we could filter, ip 
address, interface name and also UID.

So if want to support filtering at the server level, we can implement 
GUPnPWhiteList in Device.

For instance, I must admit, I could not find use cases.

Ludovic

> Best Regards,
>
> Mark
>
>
>
> _______________________________________________
> gupnp-list mailing list
> gupnp-list gnome org
> https://mail.gnome.org/mailman/listinfo/gupnp-list

--
Ludovic Ferrandis
Open Source Technology Center
Intel Corporation