Re: [gupnp] Support for Evented State Variable ?

["Mehmet Sahin" <msahin ubicom com>]

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 <yut616 21cn com> 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 <yut616 21cn com> 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?
> >    <ClientHTTP>
> >    <HTTP10>false</HTTP10>
> >    <HTTP11>true</HTTP11>
> >    <PersistentConnections>true</PersistentConnections>
> >    <Pipelining>false</Pipelining>
> >    </ClientHTTP
> > 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