[reSIProcate] Bug with ClientSubscription when handling NOTIFY while the client is terminating the subscription (with patch)

[Francis Joanis <francis.joanis@xxxxxxxxx>]

Hi,

Here's something else we discovered when experimenting with
Client/Server subscriptions.

The original scenario was:

- Having two processes, one ClientSubscription and one ServerSubscription
- Have the client subscribe to the server
- Have the server send NOTIFYs every 4 seconds or so
- Have the client terminate the subscription
- At the same time disconnect the network connection between the
client and server
- Reconnect the network connection

The outcome is that onTerminated wasn't getting called on the client.

In the details, what happens is that pre-termination NOTIFYs get
resent while the network is disrupted. On the client, a resent NOTIFY
is received while mEnded == true, which ends up creating the bug.

The actual bug is that since mEnded == true, we never call
acceptUpdate/rejectUpdate/... on that NOTIFY and thus it ends up
sticking into the mQueuedNotifies queue.

Since it sticks in the queue, when the server finally sends a
termination NOTIFY it never actually gets processed by the client
(instead it gets queued up on mQueuedNotifies), which means that
onTerminated isn't called on the client.

I've written a small app that exhibits the same behavior and that
should show the problem and that the proposed patch seems to work. To
simulate the problem, I'm resending a previously sent NOTIFY right
after calling end() on the client subscription.

The patch itself isn't too bad unless I'm missing something. It simply
rejects all incoming NOTIFYs (but the terminated ones) received while
in that "state".

Attached is a tar.gz containing the patch, the test code and a simple
makefile to compile the test code (tested on Ubuntu).

Thanks!

Francis

Attachment: fjoanis_clientsub.tar.gz
Description: GNU Zip compressed data