|
Actually, I do not think
"Close" is the root cause from my test result.
Maybe you could capture a Windows media
player server for the lastchange of directory/file add/remove to check its
NOTIFY.
BTW, does Rygel Renderer send the changes one
by one from it queue, and it will not remove/replace the middle
state?
If it is sending one by one, I do not think it is the
correct lastchange mechanism.
2009-12-10
yut616
发件人： Mehmet Sahin
发送时间： 2009-12-10 16:59:13
收件人： gupnp
抄送：
主题： Re: [gupnp] Support for
Evented State Variable ?
Yes it always fails for item 7.3.93.1 and 7.3.93.1A.
I think you are suspecting the case below,
When a given state variable (within the same instance) changes multiple
times before the moderation
period of the LastChange state variable expires, only one state variable
element will appear within the
InstanceID element. The previous state variable element must be removed
and replaced with a new state
variable element that reflects the most recent value of that state
variable.
I've checked the body of the packets and didn't see a problem which may
suit this case,
and the body was involving only one state variable element mostly.
As you may know there're some other items which don't test LastChange
Eventing individually but using as middle step in their tests.
For exp. for 7.3.102.1 CTT succesfully gets LastChange message.
I'm using Rygel Renderer and it's LastChange mechanism. I found some minor
bugs there and fixed them, but it didn't solve this issue.
Let me ask question this way,
if I add Close Connection Header to notify_subscriber method of libgupnp,
do you think guys it may broke some other things, or it's acceptable ?
Looks like although the system is generally uses persistent connection,
eventing layer of GUPnP may use Close Conection if it'll work in more
stable way.
Since we know that after sending eventing packets we will not send the
followings before moderation time period expires (it's 200 ms), so looks
like no need to keep connection open for eventing. What do you think about
that how much this idea suitable for libgupnp ?
Mehmet
On Thu, 10 Dec 2009 04:01:04 +0200, YuTao <yut616 21cn com> wrote:
> 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 = value;
>>> 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
|