Browse Prior Art Database

Guaranteed Delivery of Event Notifications Across Wide Area Networks

IP.com Disclosure Number: IPCOM000123243D
Original Publication Date: 1998-Jul-01
Included in the Prior Art Database: 2005-Apr-04
Document File: 3 page(s) / 111K

Publishing Venue

IBM

Related People

Cardone, R: AUTHOR [+2]

Abstract

The problem we wanted to solve was that of many clients needing to be notified of events as they occur on (possibly) multiple servers. The clients and servers are part of a WAN, polling was to be avoided, delivery must be guaranteed with no notifications lost, the set of clients and servers is dynamic, the set of servers that any given client may need notification from is dynamic, and the ability for a server to notify many clients soon after an event has occurred is important.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 52% of the total text.

Guaranteed Delivery of Event Notifications Across Wide Area Networks

   The problem we wanted to solve was that of many clients
needing to be notified of events as they occur on (possibly)
multiple servers.  The clients and servers are part of a WAN,
polling was to be avoided, delivery must be guaranteed with no
notifications lost, the set of clients and servers is dynamic, the
set of servers that any given client may need notification from is
dynamic, and the ability for a server to notify many clients soon
after an event has occurred is important.

The protocol assumes the network has the following capabilities:
  1.  A reliable, buffered, stream transport with typical address
      resolution and routing capabilities.
  2.  Buffering of message data at both the sender and receiver
      nodes.
  3.  Queuing of incoming connection (session) requests.
  4.  The ability to wait on multiple input ports at once.
  5.  The ability to determine the network source of incoming
      data.

   Not by chance, a TCP/IP network using TCP as the
connection-oriented, stream transport layer fills these needs.  The
network interrupt or notification algorithm should work over
intranets as well as the Internet.

   The protocol uses two components.  The first is the actual
interrupt message which has been implemented as a single 4-byte
integer.  The second component is a set of two ports used by
clients.  These ports are used to wait for notifications from any
server with which the client has previously declared itself as an
"interested party".  The first, the interrupt port, receives event
notifications under normal operating conditions.  The second, the
overflow port, is used only to handle exceptional conditions.

   The protocol also requires that servers keep a table of
clients that have registered interest in one or more events.  Each
client also keeps a table containing the servers with which it has
registered interest.

   The protocol is pretty simple.  It begins by a client
establishing its interrupt and overflow ports.  A client can then
register interest in some set of events at one or more servers by
sending a message to the server's well-known port.  This
registration message contains the client's interrupt and overflow
ports, its network address (implicitly or explicitly) and the event
type(s) in which it is interested.  The servers record all this in
their tables.

   When an event occurs on some server, the server scans its
table to find all clients that are interested in the event.  Each
event can be described by a small event id (32 bits in our
implementation) which is sent to the interrupt port of each
interested client using the reliable, buffered stream transport.  The
sender opens a connection with the first client, sends the event id
and then closes the session.  It does this with each interested
client with as much concurrency as the OS/transport layer allows.

Three things can happen on e...