U.S. patent application number 12/059926 was filed with the patent office on 2008-10-09 for peer-to-peer messaging system.
This patent application is currently assigned to WebEx Communication, Inc.. Invention is credited to Bin Zhao.
Application Number | 20080250110 12/059926 |
Document ID | / |
Family ID | 39227381 |
Filed Date | 2008-10-09 |
United States Patent
Application |
20080250110 |
Kind Code |
A1 |
Zhao; Bin |
October 9, 2008 |
PEER-TO-PEER MESSAGING SYSTEM
Abstract
In one embodiment, a distributed environment for supporting
on-line collaborative meetings among a plurality of users includes
a plurality of applications executing on different client machines.
A sequence of messages is transmitted from a first application of
the distributed environment to a second application of the
distributed environment, using a multicast form of delivery. A
request for re-transmission is received from the second application
specifying at least one message of the sequence that was not
received by the second application. In response to the request, the
specified at least one message of the sequence is retransmitted
from the first application to the second application using a
reliable unicast form of delivery.
Inventors: |
Zhao; Bin; (Newark,
CA) |
Correspondence
Address: |
CESARI AND MCKENNA, LLP
88 BLACK FALCON AVENUE
BOSTON
MA
02210
US
|
Assignee: |
WebEx Communication, Inc.
San Jose
CA
|
Family ID: |
39227381 |
Appl. No.: |
12/059926 |
Filed: |
March 31, 2008 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
10266732 |
Oct 7, 2002 |
7353253 |
|
|
12059926 |
|
|
|
|
10266762 |
Oct 9, 2002 |
6709145 |
|
|
10266732 |
|
|
|
|
Current U.S.
Class: |
709/206 |
Current CPC
Class: |
H04L 12/1868 20130101;
H04L 51/30 20130101; G06F 9/546 20130101; G06Q 10/107 20130101;
H04L 12/1813 20130101 |
Class at
Publication: |
709/206 |
International
Class: |
G06F 15/16 20060101
G06F015/16 |
Claims
1-26. (canceled)
27. A method comprising: establishing a distributed environment for
supporting on-line collaborative meetings among a plurality of
users, the distributed environment including a plurality of
applications executing on different client machines; transmitting a
sequence of messages from a first application of the distributed
environment for supporting on-line collaborative meetings to a
second application of the distributed environment for supporting
on-line collaborative meetings, using a multicast form of delivery;
receiving a request for re-transmission from the second application
specifying at least one message of the sequence that was not
received by the second application; and in response to the request,
retransmitting the specified at least one message of the sequence
from the first application to the second application using a
reliable unicast form of delivery.
28. The method of claim 27 wherein the plurality of applications
include one or more meeting manager applications and one or more
collaboration server applications.
29. The method of claim 27 further comprising: assigning a
respective sequence number to each message of the sequence of
messages, and wherein the request for retransmission specifies the
at least one message of the sequence that was not received by
sequence number.
30. The method of claim 27 wherein the multicast form of delivery
is a connectionless multicast protocol.
31. The method of claim 30 wherein the connectionless multicast
protocol is User Datagram Protocol (UDP) multicast.
32. The method of claim 27 wherein the reliable unicast form of
delivery is a reliable connectionless unicast protocol.
33. The method of claim 32 wherein the reliable connectionless
unicast protocol is User Datagram Protocol (UDP) reliable
unicast.
34. The method of claim 27 wherein the sequence of messages is
associated with a subject, and the method further comprises:
receiving a request from the second application indicating the
second application subscribes to the subject.
35. The method of claim 27 wherein the establishing further
comprises: coupling the different client machines with a local area
network (LAN).
36. An apparatus comprising: a memory storage device operable to
store a first application of a distributed environment for
supporting on-line collaborative meetings among a plurality of
users; and a processing device operable to execute the first
application, the first application when executed to transmit a
sequence of messages to a second application of the distributed
environment for supporting on-line collaborative meetings using a
multicast form of delivery, to receive a request for
re-transmission from the second application that specifies at least
one message of the sequence that was not received by the second
application, and in response to the request, to retransmit the
specified at least one message of the sequence to the second
application using a reliable unicast form of delivery.
37. The apparatus of claim 36 wherein the first application is a
meeting manager application or a collaboration server
application.
38. The apparatus of claim 36 wherein the first application
comprises: a sequence number generator operable to assign a
respective sequence number to each message of the sequence of
messages, and wherein the request for retransmission specifies the
at least one message of the sequence that was not received by
sequence number.
39. The apparatus of claim 36 wherein the multicast form of
delivery is a connectionless multicast protocol.
40. The apparatus of claim 39 wherein the connectionless multicast
protocol is User Datagram Protocol (UDP) multicast.
41. The apparatus of claim 36 wherein the reliable unicast form of
delivery is a reliable connectionless unicast protocol.
42. The apparatus of claim 41 wherein the reliable connectionless
unicast protocol is User Datagram Protocol (UDP) reliable
unicast.
43. The apparatus of claim 36 wherein the sequence of messages is
associated with a subject and the first application comprises: a
receiver list operable to indicate the second application
subscribes to the subject.
44. The apparatus of claim 36 further comprising: a local area
network (LAN) operable to pass the sequence of messages.
45. An apparatus comprising: means for transmitting a sequence of
messages from a first application of a distributed environment for
supporting on-line collaborative meetings to a second application
of the distributed environment for supporting on-line collaborative
meetings using a multicast form of delivery, the distributed
environment including a plurality of applications executing on
different client machines; means for receiving a request for
re-transmission from the second application that specifies at least
one message of the sequence that was not received by the second
application; and means for retransmitting, in response to the
request, the specified at least one message of the sequence from
the first application to the second application using a reliable
unicast form of delivery.
46. The apparatus of claim 45 wherein the plurality of applications
include one or more meeting manger applications and one or more
collaboration server applications.
Description
TECHNICAL FIELD OF THE INVENTION
[0001] The present invention relates generally to computer networks
and, more particularly, to peer-to-peer messaging systems.
BACKGROUND OF THE INVENTION
[0002] Distributed network applications often require an efficient
and reliable real-time data communication system. Applications need
to send and receive messages to other applications running on
separate computers linked by a local area network. Such a messaging
system should be able to handle a high volume of messages.
[0003] Various systems and techniques have been previously
developed for data communication for distributed network
applications. One such previously developed system is a
"heavyweight" peer-to-peer messaging system. The heavyweight
peer-to-peer messaging system employs two types of components. The
first type of component is a messaging client library that is
linked into every custom application that needs to send or receive
messages. The second type of component is a messaging daemon that
handles the network broadcasting of the messages. This messaging
daemon needs to be running on every machine that is sending or
receiving messages. Such daemon is a process that runs in the
background (without a visible user interface) and performs a
specified operation at predefined times or in response to certain
events. In general, daemons are usually spawned automatically by a
system and may either live forever or be regenerated at
intervals.
[0004] Another previously developed messaging system employs a
client-server architecture. Such a client-server system consists of
multiple messaging clients communicating with one or more
stand-alone messaging servers. The clients have messaging libraries
linked into custom applications like in the peer-to-peer system
described above. Each messaging server has a daemon resident
thereon.
[0005] Both the heavyweight peer-to-peer and client-server
messaging architectures suffer from numerous problems. For example,
in the heavyweight peer-to-peer model, inter-process communication
(IPC) calls between the messaging library and the messaging daemon
are required for messaging, thereby comprising performance. This is
in addition to the required network communication that is needed to
broadcast the messages from a sending messaging daemon to one or
more receiving messaging daemons. In the client-server model,
performance is compromised because messages need to be sent to a
messaging server before being broadcast to the receiving client
machines.
[0006] In the heavyweight peer-to-peer model, reliability is an
issued because the messaging daemon could be a potential failure
point on every machine that needs to send and receive messages. If
the messaging daemon fails or is accidentally stopped, none of the
applications running on the machine will be able to send or receive
messages. In the client-server model, the use of a single messaging
server presents a single point of failure. Using one or more
additional messaging servers alleviates this reliability issue, but
increases overall costs.
[0007] In the heavyweight peer-to-peer model, a messaging daemon
must be configured and initiated for each machine that is sending
and receiving messages, thereby complicating the task of system
configuration. In the client-server model, system configuration is
complicated by the need to configure and maintain the messaging
server machines and the daemons resident thereon.
[0008] In addition, many previously developed messaging solutions
use the Transmission Control Protocol (TCP). TCP provides a unicast
point-to-point transmission mechanism with message acknowledgement
for reliable messaging. TCP is suitable when there is one sender
and one recipient for any given message. However, to send a message
from one machine to many others using the unicast mechanism is
bandwidth intensive. For example, to send a message to five
recipients with the unicast mechanism of TCP requires five separate
transmissions of the same data.
SUMMARY OF THE INVENTION
[0009] The present invention provides systems and methods for a
lightweight peer-to-peer messaging system. The messaging system
does not use a messaging daemon in order for there to be
communication between a plurality of client machines. Each client
machine in the messaging system includes one or more applications,
each of which has a messaging client library for communications
with other machines. The messaging client library may implement a
User Datagram Protocol (UDP) multicast protocol for sending out
broadcast messages. If there are problems, then the same machine
may send out a non-broadcast UDP protocol message. The proposed
lightweight peer-to-peer messaging system includes a client
application messaging library. The system does not include a
separate messaging daemon or stand-alone messaging server. The
simplicity of design improves upon reliability, performance, and
configuration ease.
[0010] According to one embodiment of the present invention, a
system is provided for peer-to-peer messaging. The system includes
a first client machine which may transmit a sequence of messages
related to a subject. The transmission of each message can be in
the form of multicast delivery or reliable unicast delivery. At
least one second client machine communicates with the first client
machine. Each such second client machine may receive at least a
portion of the sequence of messages transmitted in the multicast
form of delivery from the first client machine, and determines if
there is an interest in the subject of the sequence of messages.
The second client machine may determine if any messages in the
sequence have not been received if there is an interest, and can
transmit a request for re-transmission to the first client machine.
The request identifies any messages of the sequence that were not
received so that such messages can be re-transmitted by the first
client machine to the at least one second client machine in the
form of reliable unicast delivery.
[0011] According to another embodiment of the present invention, a
method is provided for peer-to-peer messaging performed on a first
client machine. The method includes the following: transmitting a
sequence of messages in multicast form of delivery to a plurality
of second client machines, the sequence of messages related to a
subject, and wherein at least a portion of the plurality of second
client machines subscribe to the subject; receiving a request for
re-transmission from at least one second client machine, the
request for re-transmission specifying at least one message of the
sequence which was not received by the at least one second client
machine; and re-transmitting the specified at least one message of
the sequence in reliable unicast form of delivery to the at least
one second client machine.
[0012] Important technical advantages of the present invention are
readily apparent to one skilled in the art from the following
figures, descriptions, and claims.
BRIEF DESCRIPTION OF THE DRAWINGS
[0013] For a more complete understanding of the present invention,
for further features and advantages, applicants now make the
following description, taken in conjunction with the accompanying
drawings, in which:
[0014] FIG. 1 illustrates a peer-to-peer messaging system,
according to an embodiment of the present invention.
[0015] FIG. 2 illustrates a logical view of an exemplary computer
system environment in which a lightweight peer-to-peer messaging
system can be employed, according to an embodiment of the present
invention.
[0016] FIG. 3 illustrates an exemplary messaging library, according
to an embodiment of the present invention.
[0017] FIG. 4 illustrates an exemplary message, according to an
embodiment of the present invention.
[0018] FIG. 5 is a flow diagram of a method for peer-to-peer
messaging, according to an embodiment of the present invention.
DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS
[0019] Turning first to the nomenclature of the specification, the
detailed description which follows is represented largely in terms
of processes and symbolic representations of operations performed
by conventional computer components, such as a local or remote
central processing unit (CPU), processor, server, or other suitable
processing device associated with a general purpose or specialized
computer system, memory storage devices for the processing device,
and connected local or remote pixel-oriented display devices. These
operations may include the manipulation of data bits by the
processing device and the maintenance of these bits within data
structures resident in one or more of the memory storage devices.
Such data structures impose a physical organization upon the
collection of data bits stored within computer memory and represent
specific electrical or magnetic elements. These symbolic
representations are the means used by those skilled in the art of
computer programming and computer construction to most effectively
convey teachings and discoveries to others skilled in the art.
[0020] For purposes of this discussion, a process, method, routine,
or sub-routine is generally considered to be a sequence of
computer-executed steps leading to a desired result. These steps
generally require manipulations of physical quantities. Usually,
although not necessarily, these quantities take the form of
electrical, magnetic, or optical signals capable of being stored,
transferred, combined, compared, or otherwise manipulated. It is
conventional for those skilled in the art to refer to these signals
as bits, values, elements, symbols, characters, text, terms,
numbers, records, files, or the like. It should be kept in mind,
however, that these and some other terms should be associated with
appropriate physical quantities for computer operations, and that
these terms are merely conventional labels applied to physical
quantities that exist within and during operation of the
computer.
[0021] It should also be understood that manipulations within the
computer system are often referred to in terms such as adding,
comparing, moving, searching, or the like, which are often
associated with manual operations performed by a human operator. It
must be understood that no involvement of the human operator may be
necessary, or even desirable, in the present invention. Some of the
operations described herein are machine operations performed in
conjunction with the human operator or user that interacts with the
computer or system.
[0022] In addition, it should be understood that the programs,
processes, methods, and the like, described herein are but an
exemplary implementation of the present invention and are not
related, or limited, to any particular computer, system, apparatus,
or computer language. Rather, various types of general purpose
computing machines or devices may be used with programs constructed
in accordance with the teachings described herein. Similarly, it
may prove advantageous to construct a specialized apparatus to
perform one or more of the method steps described herein by way of
dedicated computer systems with hard-wired logic or programs stored
in non-volatile memory, such as read-only memory (ROM).
Overview
[0023] According to embodiments of the present invention, systems
and methods are provided for peer-to-peer messaging between and
among a number of client computers. With this peer-to-peer
messaging, no messaging daemon process or stand-alone messaging
server is required. Instead, for each client computer having one or
more applications running thereon, a messaging client library may
be linked into each application that needs to send and receive
messages between client computers. In one embodiment, the messaging
client library may support or utilize a specialized form of User
Datagram Protocol (UDP) to provide for both efficient and reliable
delivery of messages from the linked-in application to all other
messaging client computers. This peer-to-peer messaging is able to
handle a high volume of messages (e.g., up to 800 messages per
second).
System For Peer-To-Peer Messaging
[0024] Referring now to the drawings, FIG. 1 illustrates a system
10 for peer-to-peer messaging, according to an embodiment of the
present invention. As depicted, system 10 includes a plurality of
client machines 12 which may communicate over a communication link
14.
[0025] Each client machine 12 can be any suitable computer such as,
for example, a personal computer (PC), main-frame, a file server, a
workstation, or other suitable data processing facility supported
by memory (either internal or external), and operating under the
control of any suitable operating system (OS), such as MS-DOS,
MacINTOSH OS, WINDOWS NT, WINDOWS 95, WINDOWS 2000, WINDOWS NT,
SOLARIS, OS/2, UNIX, LINUX, XENIX, HP-UX, and the like.
[0026] On each client machine 12, one or more software applications
16 may run. Each application 16 may interact with an operating
system of the client machine 12. These applications 16 may support
numerous services or functions such as, for example, document
sharing, accounting, word processing, application sharing, file
transfer, remote control, voiceover Internet Protocol (IP), user
authentication, meeting scheduling, address book, files and
folders, invoices, billing, scheduling, telephone conferencing,
authentication, database management, etc. These applications 16 may
also support a website or web server for distribution of web pages
and access to back-end applications. Each application 16 can be a
network application which may require efficient and reliable
real-time data communication between client machines 12 during
operation of system 10.
[0027] Each application 16 may include a client messaging library
18. In one embodiment, the applications 16 make application
programming interface (API) calls to the linked-in messaging
libraries 18. A messaging library 18, according to an embodiment of
the present invention, may support peer-to-peer messaging within
system 10 without use of a daemon application or a separate
stand-alone messaging server connecting all of client machines 12.
A messaging library 18 is able to communicate or exchange messages
between its corresponding application 16 and other applications 16
residing on either the same client machine 12 or other client
machines 12. In one embodiment, as depicted, a separate messaging
library 18 is provided for each application 16. In other
embodiments, one messaging library 18 may be provided for multiple
applications 16, or multiple messaging libraries 18 may be provided
for a single application 16. The messaging library 18 includes a
number of modules or components which enable it to exchange
messages with other messaging libraries 18.
[0028] The messaging library 18 may utilize, support, or implement
a specialized form of User Datagram Protocol (UDP). UDP is a
communications protocol for Internet network layer, transport
layer, and session layer. Like Transmission Control Protocol (TCP),
UDP is used with Internet Protocol (IP). Unlike TCP, the standard
form of UDP is connectionless--i.e., it provides for exchange of
messages (or datagrams) without acknowledgements or guaranteed
delivery. This makes UDP a relatively low-overhead protocol for
delivering messages. At the same time, however, the standard form
of UDP does not guarantee reliable communication; an application
itself must process any errors and check for reliable delivery. The
standard form of UDP has a "multicast" form of delivery for sending
a single message to a select group of recipients. Standard UDP also
has a "unicast" form of delivery for sending control messages
between a single sender and a single recipient. In addition to
multicast and unicast forms of delivery, the specialized form of
UDP according to embodiments of the present invention also provides
for a reliable unicast form of delivery. With the reliable unicast
delivery form, message acknowledgement is provided for reliable
delivery.
[0029] Communication link 14 can be a communication line in copper
wire, fiber-optic cable, or other suitable medium, that is part of
a local area network (LAN), wide area network (WAN), or other
network. For example, in some embodiments communication link 14 can
be a dedicated T1 or T3 or optical carrier-class link, such as one
employing the well-known SONET standard and OC-48 or OC-192
framing. One of ordinary skill in the art will readily recognize
that many other equivalent network standards, including non-optical
standards, may be employed for implementing communication link 14.
Communication link 14 can include one or more lines or buses for
communicating data between the various client machines. These can
be physical lines such as copper wire or optical fiber, along with
suitable routers, amplifiers, and other circuitry necessary for
transmission, delivery and protocol. In one embodiment, a suitable
bridge is connected to communication link 14, thus enabling the
client machines 12 of system 10 to communicate with an outside
network. This bridge, for example, can communicate over the
Internet with client computers located at another location.
[0030] In one embodiment, one or more groups are formed from the
client machines 12 or the applications 16 running thereon. Each
group may be defined or characterized by a particular message
"topic" or "subject" (e.g., meetingdomain.meetingzone.mzm.
serverid) for which all members of the group should desirably
receive data or information. Thus, any message relating to a
particular subject should be sent to and received by the respective
group of client machines 12 or applications 16. Each group can
include up to all of the applications 14 or client machines 12.
Applications 14 or client machines 12 which are members of a group
may be deemed to "subscribe" to the particular subject which
defines the group.
[0031] In operation, in one embodiment, the UDP multicast form of
delivery is used to send messages from a sending client machine 12
to a select group of receiving client machines 12. If, for whatever
reason, some of the multicast messages do not make it to one or
more intended receiving client machines, the messaging client
library may utilize the UDP reliable unicast form of delivery to
resend the messages. In particular, the UDP multicast form of
delivery does not guarantee that messages will be received in the
same order they are sent out. Therefore for each sender in every
subject, each message sent is given an incremental sequence number.
If an intended client machine 12 receives an unordered message, it
will send a request for the one or more missing messages to the
sending client machine via UDP reliable unicast delivery. The
sending client machine 12 will then re-send the missing messages
via UDP reliable unicast delivery.
[0032] The lightweight peer-to-peer messaging, in one embodiment of
the present invention, is able to handle a high volume of messages
(e.g., up to 800 messages per second). This peer-to-peer messaging
does not require a separate messaging daemon or stand-alone
messaging server. The simplicity of this design improves
reliability, performance, and configuration ease in system 10.
[0033] With the peer-to-peer messaging system 10, reliability is
improved since there is no messaging daemon on each client machine
12 that can fail or be accidentally stopped as in the previously
developed heavyweight peer-to-peer messaging systems. Also, there
are no messaging server machines that can fail or be disconnected
as with previously developed client-server models for
messaging.
[0034] Performance is improved because client machines 12 in system
10 broadcast their messages directly to other client machines 12.
In system 10, no inter-process communication between messaging
client applications and a messaging daemon is necessary as in the
previously developed heavyweight peer-to-peer model. Nor is there
any delay caused by routing all messages through a separate
messaging server, which then broadcasts the messages to the other
clients computer, as with the previously developed client-server
model. Furthermore, the use of the UDP multicast form of delivery
in lightweight peer-to-peer messaging system 10 improves bandwidth
consumption significantly. For example, to send a message to five
recipients with TCP/IP unicast, as employed by previously developed
systems, requires five transmissions of the same data. Using the
UDP multicast form of delivery requires 1/5 the same bandwidth
since the data is only transmitted once for all five
recipients.
[0035] Configuration of peer-to-peer messaging system 10 is simpler
since it is not necessary to set up a messaging daemon on each
client machine like in the previously developed heavyweight
peer-to-peer model. Furthermore, there are no messaging server
machines to configure and maintain as in the previously developed
client-server model.
Exemplary Environment
[0036] FIG. 2 illustrates a logical view of an exemplary computer
system environment 20 in which a system 10 of the present invention
may be employed. In this computer system environment 20, a number
of server computers and databases may be in communication to
provide for collaborative meeting or computing. The details for
such can be found in U.S. application Ser. No. 09/751,424 entitled
"Distributed Network System Architecture for Collaborative
Computing," filed on Dec. 29, 2000, assigned to the same assignee
and incorporated by reference herein in its entirety.
[0037] Referring to FIG. 2, in environment 20, a number of
processing facilities, including, for example, one or more of a web
server 22, a log server 24, a ping server 26, and a collaboration
server 28, license manager 34, primary and secondary meeting
managers 36, application servers (e.g. telephone agent 38, poll 40,
chat 42, video 44, voice over IP 46, document view 48, application
share 50, and file share 52) may be integrated with a number of
data storage facilities, such as, for example, a web database 30
and a meeting database 32 to implement a system for collaborative
meetings over the Internet. As depicted, the processing and
database facilities of environment 20 are divided into a web zone
and one or more meeting zones for interaction with one or more
client browsers 54.
[0038] A web zone can be one or more server machines that share a
common web database 30. In the web zone, web server 22 may have a
unique IP address (which can be associated with a particular
website) and responds to Hyper-Text Transport Protocol (HTTP)
requests coming to that IP address from client browser 54. Web
server 22 serves or supports web pages. Web database 30 may contain
static information for the website including site specific data,
web pages, and user data.
[0039] A meeting zone is a collection of servers and databases that
help perform all the synchronous activity of an on-line
collaborative meeting. In the meeting zone, the meeting managers 36
may be servers which communicate with other servers in the meeting
zone (e.g., collaboration server 28, log server 24, ping server 26,
etc.) to keep track of the on-line meetings in progress in the
meeting zone. Meeting managers 36 may log meeting information into
meeting database 32. Ping server 26 works with meeting managers 36
to determine a collaboration server 28 that is most suitable for
hosting a particular meeting; it may act as a load balancer for the
meeting service. Collaboration servers 28 may handle all real time
control and communication during an on-line collaborative meeting.
The application servers (e.g., servers 38 through 52) may support
specific features that may be available as part of an on-line
collaborative meeting, such as, for example, telephony, polling,
chatting, video, voice over IP, document review, application
sharing, and file sharing. License manager 34 may keep track of and
enforce licensing conditions and charges for the meeting. The log
server 24 keeps track of meeting logs. Meeting database 32 can
maintain at least a portion of the transient data required to
conduct and keep track of on-line meetings. This data would
include, for example, site and user information that would be
required to establish and conduct a meeting.
[0040] Each of the processing and database facilities in
environment 20 can be implemented on one or more client machines
12, which run appropriate applications to support the desired
functionality. These applications may need to exchange information
and data during operation to support the collaborative meeting. The
information is exchanged via message packets carried over
appropriate communication links between the various processing and
database facilities. In one embodiment, client machines 12 can be
employed for any one or more, up to all, of web server 22, primary
and secondary meeting managers 36, license manager 34, log server
24, ping server 26, collaboration server 28, and various
application servers. Each of these servers may thus include a
respective messaging library 18 for communicating with the each
other using the peer-to-peer messaging technique according to
embodiments of the present invention. Furthermore, the client
machines 12 in one meeting zone (e.g., Meeting Zone A) may
communicate with client machines in another meeting zone (e.g.,
Meeting Zone B) using the peer-to-peer messaging technique.
Messaging Library
[0041] FIG. 3 illustrates a messaging library 18, according to an
embodiment of the present invention. Messaging library 18 may be
associated with or integrated into an application 16 residing or
running on a client machine 12. Messaging library 18 generally
functions to support the exchange or transfer of messages
containing data or information with other messaging libraries 18
associated with respective applications 16 during operation of
system 10 in the peer-to-peer messaging technique, according to
embodiments of the present invention. These other messaging
libraries 18 may be running on the same or separate client machine
12 linked by communication link 14.
[0042] Messaging library 18 serves as a transport layer for linking
data between the associated application 16 and a network layer. The
transport layer provides multiplexing/demultiplexing service in
order to pass data between the network layer and the respective
application 16. The messaging library 18 does not include any
messaging daemon, nor does it require a separate server to
function. As depicted, messaging library 18 includes a message
handling component 60 and a delivery service component 62.
[0043] Message handling component 60 general functions to
coordinate or manage the handling of messages which may be
transmitted from or received by messaging library 18 for the
associated one or more applications 16. Message handling component
60 may include a number of modules for supporting or providing this
message handling functionality. These include a sequence number
generator 64, a receiver list 66, a subject manager 68, a flow
control 70, and a ledge file 72. Each of these modules 64 through
72 may comprise one or more computer programs, processes, or
routines which, when executed, perform the functionality described
herein.
[0044] Sequence number generator 64 generally functions to generate
individual sequence numbers for different messages that are output
from messaging library 18. These sequence numbers may be used as a
check to verify that all messages which are intended to be received
by a particular client machine 12 have indeed been received.
Receiver list 66 generally functions to keep track of which clients
machines 12 are listening to a particular sequence of messages
which may be related to a particular topic or subject. The subject
manager 68 generally functions to manage the subjects to which the
application 16 (or client machine 12) may subscribe. Flow
controller 70 controls the flow of data or information through
messaging library 18. It coordinates so that data/information from
various applications 16 can reach the proper recipient and also be
distributed to the proper components. Ledge file 72 generally
functions to act as a buffer which tracks the information that is
transmitted/received. In case of a computer or system crash, the
information in ledge file 72 can be used for data/information
recovery.
[0045] Delivery service component 62 generally functions to provide
or support the delivery of messages from application 16 or client
computer 12. In one embodiment, this delivery can be accomplished
with the specialized form of User Datagram Protocol (UDP) messaging
of the present invention. UDP is a connectionless protocol which
runs on top of Internet protocol (IP) networks. The standard form
of UDP/IP provides very few error recovery services, instead
offering a direct way to send and receive datagrams or messages
over an UDP network comprising an interconnected set of computers.
UDP is "connectionless" in the sense that a sending machine (or
host) can send a message without establishing a connection with a
receiving machine (or recipient). That is, there is no handshaking
between the host and the recipient before sending a message. The
host simply puts the message onto the network with the destination
address and hopes that it arrives.
[0046] UDP allows an application 16 to send messages to other
applications 16 with a minimum of protocol mechanism. UDP sends
messages without many formal preliminaries. Thus, UDP offers a
relatively fast and efficient way of transporting messages within
system 10. UDP takes messages from an application process, attaches
source and destination port number fields from a
multiplexing/demultiplexing service, adds two other fields, and
passes the resulting "segment" to the network layer. The network
layer encapsulates a segment into an IP datagram or message and
then makes a best-effort attempt to deliver the segment to the
intended recipient(s). If the segment arrives at the recipient, UDP
uses the port numbers in the IP source and destination addresses to
deliver the data in the segment to the correct application process.
Furthermore, since UDP is connectionless, it does not need to
maintain a connection state nor does it need to track any of the
parameters for a connection. UDP only has an overhead of eight
bytes. The speed at which UDP sends data is only constrained by the
rate at which the application 16 generates data/information, the
capabilities of the source (e.g., CPU, clock rate, etc.) and the
access bandwidth to the communication link 14.
[0047] In the specialized form of UDP according to embodiments of
the present invention, delivery service component 62 supports three
different forms of message delivery: multicast, unicast, and
reliable unicast. In multicast delivery, a message is sent to a
select group of receiving client machines 12 on the communication
link 14. Each of these receiving machines may look at the message
and determine whether or not it has any interest in that message.
In unicast delivery, a message is directed to a single, specific
receiving machine. In reliable unicast delivery, a message is
directed to a specific receiving machine and a
sequence/acknowledgement procedure is used to ensure that the
message is indeed received by the intended recipient.
[0048] As depicted, delivery service component 62 comprises
separate modules for the various forms of delivery: multicast
module 74, unicast module 76, and reliable unicast module 78.
Multicast module 74 is used to sent out messages to one or more
groups. Unicast module 76 is used for purposes such as, for
example, monitoring information. Reliable unicast module 78 is used
to recover lost messages and track a receiver list. Each of these
modules 74 through 78 may comprise one or more computer programs,
processes, or routines which, when executed, perform the
functionality described herein.
Message
[0049] FIG. 4 illustrates a message 80 for the specialized form of
UDP, according to an embodiment of the present invention. As
depicted, this message 80 comprises an overhead component 82 and a
body component 84. Overhead component 82 in one embodiment may
comprise 8 bytes of information of overhead information. This
overhead information, which can be used for communicating the
message between a sending and one or more receiving client machines
12, may specify, for example, a source port, a destination port, a
length of the packet, and a checksum. The body component 84 of the
message 80 contains data or content that is to be delivered between
applications. The body component 84 may include a subject line 86.
The subject line 86 may specify a subject or topic of the message.
Each client machine 12 may "subscribe" to certain subjects of
interest. The client machine 12 may review messages delivered in
multicast in order to view the specified subjects and determine
whether or not it subscribes to the particular subject. If it does
not subscribe to such subject, it will discard the message. Thus, a
client machine 12 will only process messages that are related to a
subject for which the machine has subscribed.
Method For Peer-to-Peer Messaging
[0050] FIG. 5 illustrates a method 100 for peer-to-peer messaging,
according to an embodiment of the present invention. Method 100 can
be performed by a client machine 12 acting as a sending computer
and at least one client machine 12 acting as a recipient computer.
Method 100 begins at step 102 where the sending machine transmits a
multicast message. The multicast message may be related to a
particular subject, which is specified in the body component of the
message. The multicast message is intended for a select group of
client machines on communication link 14.
[0051] At step 104 the multicast message may be received at one or
more client machines 12. Each client machine 12 which receives a
multicast message may at step 106 determine whether it is
interested in (or subscribed to) the subject matter of the message.
If it is not interested in the subject matter of that message, then
the client machine 12 will discard the message at step 108, after
which the method 100 ends for that particular receiving machine.
Otherwise, if the receiving client machine 12 is interested, then
at step 110 the machine requests to be part of the communication
for that message.
[0052] At that point, the request is sent back to the original
sending client machine 12, which completes a handshake for all
interested recipient machines at step 112. At step 114 the sending
client machine 114 then transmits additional multicast messages to
the recipient machines via communication link 14. Each recipient
client machine 12 which is part of the communication receives one
or more of the additional multicast messages at step 116. Each such
multicast message will have a sequence number which identifies
where in the sequence of messages it falls.
[0053] At step 118 each recipient machine that is part of the
communication determines whether it is missing any of the messages
that are part of the communication. In one embodiment, this can be
accomplished by looking at the sequence numbers of all of the
received multicast messages and determining if any sequence numbers
are missing. Thus, for example, for a sequence of messages that
range from 91 through 110 in sequence number, the client machine 12
may determine that messages with sequence numbers of 98, 99, and
105 were not received. If there are no missing sequence numbers,
then method 100 moves on to step 124 (described below). Otherwise,
if there are missing sequence numbers, then at step 120 the
recipient client machine transmits a message for the missing
sequence numbers back to the sending machine.
[0054] At step 122, the original sender machine transmits in
reliable unicast the messages corresponding to the missing sequence
numbers for each receiving machine that has indicated that it did
not receive at least some of the messages. Reliable unicast
messages are directed at particular client machines rather than
multicast throughout the system 10. When the messages are received
at the individual recipient machines, they are processed at step
124. After that method 100 ends.
[0055] The lightweight peer-to-peer messaging according to
embodiments of the present invention is optimized for communicating
a large number of messages from one sender to many receivers. It
offers significant advantages in terms of performance, reliability,
configuration and bandwidth over previously developed
techniques.
[0056] Although particular embodiments of the present invention
have been shown and described, it will be obvious to those skilled
in the art that changes and modifications may be made without
departing from the present invention in its broader aspects, and
therefore, the appended claims are to encompass within their scope
all such changes and modifications that fall within the true scope
of the present invention.
* * * * *