RealtimeOverflow

Retain recent messages server-side so a subscriber that briefly falls behind can catch up instead of losing them; how far back is set by setMaxQueue. Whatever is lost beyond that is reported through onMessageDrop, so losses are countable — but see that method for why the count is not exhaustive, and note that a burst above the server's per-window ceiling is truncated whatever this is set to.

Shed load rather than let the subscriber lag — the newest messages of each delivery window survive, the rest are discarded. Message sequence numbers are not tracked, so onMessageDrop never fires and the loss is invisible. Choose this only when stale data is worthless (cursor positions, typing indicators) and lagging is worse than losing.