[gupnp] handling of sequence numbers in gupnp-service-proxy.c

[Sven Neumann <s neumann phase-zero de>]

Hi,

we have been having problems over the last week where notifications did
not end up being received in GUPnPServiceProxy. After some debugging we
found that the following code in gupnp-service-proxy.c is the culprit:

        hdr = soup_message_headers_get (msg->request_headers, "SEQ");
        if (hdr == NULL) {
                /* No SEQ header */
                soup_message_set_status (msg,
                                     SOUP_STATUS_PRECONDITION_FAILED);

                return;
        }

        seq = atoi (hdr);
        if (seq > proxy->priv->seq) {
                /* Oops, we missed a notify. Resubscribe .. */
                unsubscribe (proxy);
                subscribe (proxy);

                /* Message was OK otherwise */
                soup_message_set_status (msg, SOUP_STATUS_OK);

                return;
        }

This code extracts the SEQ number from the HTTP header and compares it
to the expected sequence number which is incremented for each received
NOTIFY message. If there's a mismatch, the message is silently discarded
and the service-proxy unsubscribes itself and subscribes again. I don't
quite understand the reasons for handling it this way. The proxy is
obviously subscribed just fine, otherwise it wouldn't have received this
message. So why is there a need to resubscribe? And what's worse, why is
the message silently discarded?

What's the purpose of the SEQ header? If it is there to make sure that
messages are received in the order they are sent, then GUPnPServiceProxy
should probably have a message queue where out-of-order messages are
kept until outstanding messages are received.

I am willing to work on a fix for this problem. But I'd like to first
understand what the proper behavior would be. Any help with that is much
appreciated.


Sven


--
To unsubscribe send a mail to gupnp+unsubscribe\@o-hand.com