[Spread-users] Spread message queueing questions

[Clark C . Evans]

On Mon, Apr 08, 2002 at 03:14:42PM +0000, Rob Butler wrote:
| Does spread perform any "message queueing" for reliable messages
| similar to MQ series?

Some basics:

  - Spread is a peer-to-peer message distribution system.
    Certainly one of your peers can be a "server" who primarly
    generates messages, and "clients" who primarly consume
    messages, but spread itself does not have this distinction.
  - You can thing of spread more like a "chat room" where each 
    peer can hear everything in the room (only that each peer
    can be in more than one room at once).  If a peer is not in 
    the room, it doesn't hear the messages.
  - When a peer joins a room all other peers in the room get
    an entry message, similarly when a pear leaves the room all 
    in the room get a leave message.
  - If a peer is slow or gets disconnected, it is treated as if
    the peer has left the room.
  - In addition to the public "chat" rooms, there is also a "tell"
    function so that one peer can send a message to another peer 
    directly without having all the other peers in the room hear.
  - Spread makes a total ordering of the messages in the room,
    and this is the hard part.  In this way all peers in the room
    agree that message M happened before or after message N.

So.  Your question, does spread keep messages which a peer has
missed?  Then answer is no beacuse there isn't a server.
Although, a very _neat_ feature to add to spread library would
be a "peer" process which plays the role of "recorder" and 
is only an observer in a given room keeping the message history.
This recorder could then be queried by a peer who has been 
disconnected for all of the messages that they missed.  I'd like
such a "recorder process", but it shouldn't be that hard to write.
The hard part (the synconization and low level messaging stuff) 
is already done... a recorder shouldn't be the show stopper, no?

| I.E. if a client goes down, will the server still hold onto messages for 
| that client and deliver them when the client comes back up?

Nope.  There isn't a server, although this is a good role for
a "recorder" peer.

| If the server should go down, are messages stored to disk so they are 
| available when the server is restarted?

This would also be a good role for a recorder, although since the
recorder may die you may need some way to implement "shifts" so 
that when a recorder's shift ends another recorder takes over... ;)

| How many messages can the server hold for the client, before it will start 
| dropping messages for the client?  Does it drop old or new messages?

I think that this is completely dependent on how the recorder process
would be written.

| How many clients can a spread server reasonably support?
| If spread is unable to do these things now, will it have these capabilities 
| soon? When?

The hardest part about making a recorder would be getting 
the fail-over mechanism to work so that if the recorder 
died every peer knew to stop talking till the recorder is
replaced.

| Basically, looking for something that can do the basics of MQ, but I don't 
| want to have to buy MQ.

Nice.  How about contributing?  Why not learn spread and write
the recorder component?  You seem to have a very good idea as
to what would be required!  ;) 

Best,

Clark

P.S.  I'm a newbie here, so if I mis-spoke, I apologise in advance.