RDEP subscription - duplicate events after power lost

[rmulyadi]

Hi,

After a power lost, our subscription requests for retrieving events from an IDS 4.0 sensor keep returning duplicate events. I try to explicitly confirm the events and then send a new subscription request,but it still return me with the exact set of events. I check the IDS Device Manager and the eventserver statistics show no open subscription at all. However, I didn't get any error messages when using the last subscription id that I have (before the power lost) to send my subscription requests.

Any comments are very welcome.

Thanks,

Rusma

[marcabal]

When the sensor is rebooted it looses all knowledge of previous subscriptions.

If you try to retreive events with the old subscription id it should return an error and require you to open a new subscription.

When you open the new subscription you will have to tell the sensor what alarms to start sending you.

The bext way to do this is to look at the timestamp in the last alarm you received before the sensor was rebooted. When you send your new subscription request designate a start time equal to the timestamp of that last alarm you received in the previous subscription. The first few alarms in the new subscription may be duplicates of the last few alarms in the previous but this will ensure that you haven't lost any alarms in between.

If you don't care about a few lost alarms and would instead want to prevent the duplicates all you need to do is specify the start time of the new subscription as the timestamp of the last alarm from the previous subscription + 1 second.

[rmulyadi]

I know that it is supposed to give me an error message, but that's not the case in my situation. I still can send subscription requests without getting any error messages. However, it just giving me the same set of events.

I can always start a new subscription, but I am wondering whether anyone else encountering the same problem as me.

Thanks

[brhamon]

It's a feature! The last batch of events received before a power loss have not been confirmed. When you use that subscription ID to perform a GET after the system reboots, the same batch will be returned.

To explain why we designed RDEP this way, you have to understand how we use the underlying TCP stream to confirm previously sent events. Suppose a TCP connection exists between server "S" and client "C". Now overlay HTTP/1.1 on this TCP session. "C" sends a GET and "S" sends a response. When C sends the next GET, S advances the subscription pointer past the last event sent in the previous response. This is an implicit confirmation. We added a way to explicitly confirm subscription GETs on a non-persistent connection (see the "confirm" parameter in the RDEP specification).

The two ways to deal with this on the client are (1) never crash, and when terminating discard any events received on the final GET; or (2) use the eventId as a key to eliminate any duplicate events. Time is another property of an event, from which the eventId is derived; however, unlike eventId, it is possible (though unlikely) for two events to have the exact same time stamp.

If you have not already, please read the RDEP specification available at:

http://www.cisco.com/cgi-bin/dev_support/access_level/product_support?pcgi=1&product=IDS_INT_API

[rmulyadi]

As I mentioned my first posting, I try to explicitly confirm the events, but the next time I send a new subcription request, I end up with the same set of events. Is this also part of the feature?