Re: [gupnp] Support for Evented State Variable ?

[YuTao <yut616 21cn com>]

If you do not add close, does it always fail the test?

At least, in my test, it will not fail even if it does not use "close".

The root cause should be the event sending policy.
LastChange means it could do not send EVERY event out.
e.g.:it could only send the first one and last one, and drop the middle ones.

In your test, maybe the first one is overlayed by the second one.

You could read the "Test Document" carefully for more details.

What's your reference code segment? Could you provide?

 

 

 

 

 

 

 

 

===== Original Message =====

Yes is version 1.5-00-52.

I figure an important issue, I have tested item 7.3.93.1A more then 10
times for per case explained below, here is the finding,

case 1) Close Connection Header is not added
I have captured all eventing packets, in every trial SEQ:1 were missing
on the traffic between DMR and CTT.
Somehow eventing packets with SEQ1 were lost. Looks like CTT waits
initial Last Change notification with SEQ:1 if it missing it drops the
test.


case 2) Close Connection Header is not added
I have captured all eventing packets. In every trial SEQ:1 were avaliable
on the traffic between DMR and CTT.
And in this case CTT informs that it got intial LastChange notification
succesfully. and passed the point where it was droped in case 1.

Now I have to understand what is the reason of missing SEQ:1 even
notification packets ? and if adding close connection is the only way of
overcoming this problem ?

Is there anyone passing CTT item 7.3.93.1A without using Close Connenction
header as explained below ?

Mehmet



On Wed, 09 Dec 2009 17:59:39 +0200, yut616 wrote:

> BTW, what's the version of your CTT tool ? 1.5-00-52 ?
>
>
> 2009-12-09
>
>
>
> yut616
>
>
>
> 发件人： yut616
> 发送时间： 2009-12-09 22:40:28
> 收件人： gupnp; gupnp
> 抄送：
> 主题： [gupnp] Re: Re: [gupnp] Re: [gupnp] Support for Evented State
> Variable ?
> maybe DMR sends a new event in the correct moment if you use "close".
> You could repeat test this item (7.3.93.1A) for 20 times to see if this
> close method will make a faillure too.
>
> If CTT prompts the initial lastchange missing, you should check whether
> the SEQ:1 is the first value of the 5 continuous value.
> If not, it means the first change has been overlayed by the other ones.
>
>
> 2009-12-09
>
>
>
> yut616
>
>
>
> 发件人： Mehmet Sahin
> 发送时间： 2009-12-09 22:14:29
> 收件人： gupnp
> 抄送：
> 主题： Re: [gupnp] Re: [gupnp] Support for Evented State Variable ?
> Here is the sequence up to get a failure,
> 1. CTT Subscribes to DMR Service, OK
> 2. CTT Gets the initial NOTIFY with sequence "SEQ:0", OK
> 3. CTT fails to get initial LastChange Event from DMR, FAIL
> I have captured some Event Notification packets with SEQ:1 or later which
> DMR actually sends to CTT, but CTT never verifies these packets.
> The critical question is why adding Close Connection header to
> notify_subscriber method takes away this Eventing problem.
> Mehmet Sahin
> On Wed, 09 Dec 2009 15:13:25 +0200, yut616 wrote:
>> 1. the CTT 7.3.93.1A will check the first lastchange of the 5 continuous
>> setvolumn etc.
>> 2. and check the second lastchange should be large than 200ms between
>> the first one.
>> Did CTT not receive your first lastchange? If not, it will fail.
>> Or your response does not be sent in 1 second.
>>
>> CTT will check the lastchange in 1 second, and the event should not be
>> sent frequently.
>>
>> 2009-12-09
>>
>>
>>
>> yut616
>>
>>
>>
>> 发件人： Mehmet Sahin
>> 发送时间： 2009-12-09 19:02:06
>> 收件人： gupnp
>> 抄送：
>> 主题： [gupnp] Support for Evented State Variable ?
>> Hi,
>> Are below ClientHTTP settings correct for GUPnP Framework?
>>
>> false
>> true
>> true
>> false
>>
>> I tested Rygel Renderer plugin which is running on GUpN Framework,
>> there're failures about "Support for Evented State Variable" related CTT
>> items ( 7.3.93.1, 7.3.93.1A etc...).
>> The Initial Event Notification part is actually working, however there
>> is
>> a problem with next Event Notification (LastChange Events for DMR)
>> packects.
>> CTT waits for the LastChange state variable to be updated, and gives
>> ERROR:The DUT did not update the LastChange state variable.
>> I modified notify_subscriber method as below and the problem is removed.
>> However as far as I know, adding Closing Connection header for
>> Persistent
>> Connections is not something acceptable.
>> How do I overcome this conflict, is below modification seems reasonable
>> to
>> you ?
>> /* Send notification @user_data to subscriber @value */
>> static void
>> notify_subscriber (gpointer key,
>> gpointer value,
>> gpointer user_data)
>> {
>> SubscriptionData *data;
>> const char *property_set;
>> char *tmp;
>> SoupMessage *msg;
>> SoupSession *session;
>> data = ""
>> property_set = user_data;
>> /* Create message */
>> msg = soup_message_new (GENA_METHOD_NOTIFY,
>> data->callbacks->data);
>> if (!msg) {
>> g_warning ("Invalid callback URL: %s",
>> (char *) data->callbacks->data);
>> return;
>> }
>> + soup_message_headers_append (msg->request_headers,
>> + "CONNECTION",
>> + "close");
>> +
>> soup_message_headers_append (msg->request_headers,
>> "NT",
>> "upnp:event");
>> Thanks
>> Mehmet Sahin
>> --
>> To unsubscribe send a mail to gupnp+unsubscribe\@o-hand.com



--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
--
To unsubscribe send a mail to gupnp+unsubscribe\@o-hand.com

---------------------------------------
最强企业安全解决方案