As discussed on IRC, this query is related to what bridge components would need wired to facilitate a traditional exchange's broadcast / refresh / gap fill requirements and there are really two parts to the story for each component - what OpenMAMA does, and how it would be implemented in a bridge. So let's go through your points and try and provide a little clarity.

1. Snapshots / Intra day restart

The OpenMAMA DQ Publisher has a concept of 'initial' requests which greets new intraday clients with a full image of the instrument to which they're subscribing. To implement this usually involves a bridge implementation for 'inbox' related functions to work to facilitate request / reply.

2. Retransmission / Recap

If using market data subscriptions, the message is injected with a sequence number which OpenMAMA then checks to detect gaps. If a gap is detected at all (at a OpenMAMA layer), OpenMAMA will then request a snapshot image with what it calls a 'recap'. I know what you're thinking - this would be a nightmare if the bridge was receiving multicast data and data is coming in gappy or out of sequence, which is why I would suggest that line arbitrage and possibly minor gap filling (if you're going to support that) is done underneath the bridge layer and invisible to MAMA. That way gaps are only reported up to MAMA when they are something that would require an image refresh to recover from. Again, this would require an inbox implementation. It's worth noting that OpenMAMA itself has no concept of 'full tick by tick gap fill', and in existing implementations of MAMA, that sort of functionality is handled exclusively at the middleware layer.

Hope this helps,

Cheers,

Frank