Re: [HOME_NETWORK_TF] Finalizing the HNTF req doc

On 3/10/11 11:26 , Giuseppe Pascale wrote:
> On Fri, 30 Sep 2011 18:35:05 +0200, Jean-Claude Dufourd 
> <jean-claude.dufourd@telecom-paristech.fr> wrote:
>
>> After more discussions with my colleagues and co-implementers, here 
>> is the state of our reflections.
>> I assume we have implemented a discovery mechanism in the HNTF or 
>> Web&TV user agent (named HNUA hereafter).
>> I assume we implement a fixed service in the HNUA called "HNUA 
>> Standard Service", with following messages/actions:
>> - listServicesAndRegisterServiceListener: message received from 
>> another HNUA wanting to get notified of new service and service removed
>> - unregisterServiceListener: other HNUA signing out
>> - newService: message sent to all service listeners in case of new 
>> service creation
>> - serviceRemoved: message sent to all service listeners in case of 
>> removal of an exposed service
>>
>> Comparing this to UPnP-style service advertisement, this causes the 
>> sending of N messages (N = number of listeners) instead of 1 
>> broadcast message.
>> So this is inefficient, and duplicated existing UPnP/zeroconf 
>> functionality.
>> I do not like it, but I have to admit that I could probably live with 
>> it.
>>
> I'm not sure your concern is valid for advertisement. If your 
> application/service you another service (HNAdsService) to advertise 
> himself on the network, you will always talk only with that service, 
> that in turn will be able to generate multicast notifications. So this 
> would be equivalent to UPnP.
JCD: I see now precisely what you are proposing as a solution: 
delegating the multicasting to a (possibly centralized) native service.
That indeed does not have the performance problems I describe.
OK. As I wrote above, I can live with such a solution.
>
> I think we should avoid to equate the term Service to a "UPnP 
> service". Here service (IMO) is more genericaly a functionality 
> provided by a device (that could be the UA itself)
JCD: I have implemented a HNTF-like system on top of UPnP.
So when I speak of UPnP, I am reasonably certain of the validity of my 
claims.
And this is why I often take UPnP examples. It does not mean I want to 
restrict HNTF work to UPnP, far from it.
I am 100% for a techno-independent design for HNTF.

>
>
>> However, I want to insist that we have really TWO gaps, service 
>> discovery and service advertising.
>> What you propose is a supposedly easier to implement solution to the 
>> secnd gap.
>> It does not remove the existence of the service advertisement gap.
>
> When I talk about gap here, I'm not talking about requirement anymore 
> but technical gaps. It seems to me that once we have some technical 
> means to do discovery, every other requirement may be implemented on 
> top of it (if properly designed).
>
> Note also that I'm not necessarely saying this is the most effective 
> way to do so, just saying that without implementing it is difficult to 
> say if will be enough.
>
>>
>> So I would insist that we describe two gaps in the document, even if 
>> I would agree to also include a sentence saying that the service 
>> advertising gap may be filled by something else than UPnP/zeroconf 
>> service advertisement techniques.
>
> I'll make an attempt to capture what discussed and circulate some text 
> for inclusion into the requirement document later today or tomorrow.
> So you can provide me with some feedbacks.
>
JCD: In order to be interoperable on the service advertisement side, we 
would need to standardize the name and messages of the service 
advertisement service, even if even though its technology may be 
unspecified.
So there is a need for a "service advertisement" gap to justify the 
definition of that (technology neutral) service advertisement service as 
part of the general solution.

Best regards
JC

-- 
JC Dufourd
Directeur d'Etudes/Professor
Groupe Multimedia/Multimedia Group
Traitement du Signal et Images/Signal and Image Processing
Telecom ParisTech, 37-39 rue Dareau, 75014 Paris, France
Tel: +33145817733 - Mob: +33677843843 - Fax: +33145817144

Received on Monday, 3 October 2011 11:13:47 UTC