While talking about APIs are client implementations issues might be
interesting to some, I think getting the semantics of the service right
might be useful.

Let's look at the requirements a bit.

I see multiple distinct and useful services:

- A transactional point to point queued message service. For extra
points, allow multiple producers and consumers, ensure that each only
one consumer sees each message, and ensure that multiple consumers can
process work simultaneously. Consumer failures must be handled by
putting the message back at the head of the queue.

- A reliable broadcast message service. Client applications get an
unbroken and ordered sequence of messages from a given point.

- An unreliable broadcast message service. Essentially UDP or IP
multicast, not very interesting for the purposes of this discussion.

People here seem most interested in the second service, which is
reasonable. There are interesting implications for such a service.

Network Traffic

There are network scalability issues when messages are sent individually
to each client. Network traffic goes up linearly with the number of
clients. For example, assume a message rate of 10/sec, average size 50
bytes and 1000 clients. This is roughly 5Mbit/sec of traffic after
allowing some protocol overhead. Where the underlying network supports
broadcasts, clearly there is a win.

Underlying Network Naming

Using a protocol like UDP lets you send a broadcast to all nodes on a
subnet listening on a given port number. Problems: Only a submit, need
to use a port number, which might clash with other applications.

IP multicast allows broadcasts to cross routers, and addressing can be
locally controlled.

Of course other protocols (eg. ATM) define broadcast services with
slightly different semantics; they can still be used.

Higher Level Naming

At the application level, I would expect a database object for the
message stream to be created. An application would subscribe to a
message stream and be given the listening details by the server.

If filtering on a stream is to be performed, it should be done at the
client, otherwise detecting gaps becomes problematic.

Message Structure

I have deliberately left the message structure undefined. I think the
message structure should either be defined in terms of native Interbase
types, or left as a blob. The actual representation should be machine
readable and small. Please, no mandated ASCII, and especially no XML!

Joining (or resyncing with) a Message Stream

If a client misses a message, it needs to get a copy of the lost message
before it can present anything to the application. It then needs to
request that the server resends a particular message. If a "small"
number of messages are missing, the server could either send them
directly to the client, or (as an optimisation if many clients missed a
message) rebroadcast the messages. Clients which did receive the
messages would drop them as a duplicates.

If the number of missed messages is "large", we assume that the server
has forgotten about some of the missed messages. Joining a message
stream is much the same as missing too many messages. The client needs
to resync to match the server's state so that it can start listening to
broadcasts again and interpret them correctly. How this is done will
vary with the application. I expect the range to be "don't care, just
start listening again" to "start listening, and remember everything while
you receive the entire state as at sequence N." Of course, generating
the state as at sequence N is application dependent.

Of course, early detection of missed messages reduces the size of this
problem, so regular heartbeat messages are useful. The definitions of
"small" and "large" are probably related to the amount of traffic between
some small number of heartbeats.

Security

Submitting messages to the queue would require a database connection with
appropriate permissions. If you really care about who listens or about
message authentication, encrypt and/or sign the messages. To get message
authentication, you need public key cryptography and to previously have
distributed the server's public key. If you just care about
confidentiality, the client and the server could do a Diffie-Hellman key
exchange to agree on a key for securing the broadcast key. No external
configuration required.


Anyway, there are some random thoughts.

Jan Mikkelsen
janm@...