Electrical computers and digital processing systems: multicomput – Network computer configuring – Reconfiguring
Reexamination Certificate
1998-12-23
2002-04-16
Winder, Patrice (Department: 2155)
Electrical computers and digital processing systems: multicomput
Network computer configuring
Reconfiguring
C709S223000, C709S228000
Reexamination Certificate
active
06374294
ABSTRACT:
FIELD OF THE INVENTION
This invention relates to a method and a system for negating network addresses It is particularly applicable to network applications and may be used to negate obsolete network addresses such as hardware network addresses and software module addresses. The invention also extends to a computer readable storage medium including a program element executable by a general-purpose computer to implement the network address negation functionality.
BACKGROUND
Distributed processing is a powerful way to make software scaleable. Many standards for distributed processing exist and are commonly used. As a specific example, the Common Object Request Broker Architecture (CORBA) provides a basic mechanism for transparently distributing software objects across multiple processors connected to a network. Communicating CORBA software objects may be written in a variety of programming languages, and may run on a variety of computer processor types. The communication, and any needed translation between the different data formats of varying processor types and programming languages, is handled automatically by CORBA. CORBA is a standard defined by the Object Management Group (OMG) For more information on the CORBA standard the reader is invited to consult “The Essential CORBA: Systems Integration Using Distributed Objects”, by Thomas J. Mowbray and Ron Zahavi, Object Management Group Inc, 1998, whose content is hereby incorporated by reference.
Telecommunication software is an example of a distributed network system. Typically, entities (software and hardware) in a distributed system communicate with one another by sending messages.
To provide a more reliable communication, communication protocols have built-in message acknowledgement capabilities. The protocol dictates that a message must be re-sent when no acknowledgement to a previous message is received from the addressee. Typically, the communication protocol defines the number of times the sender will re-send a message and how long the time intervals between resent messages will be. Usually, the time before retransmission increases for each retransmission of the same message. If no acknowledgment is received after a pre-determined number of times that a given message is resent, an error is generated For instance, a message sender may set a timer when it sends the original message, and automatically re-send the message if an acknowledgement fails to arrive before the timer expires.
Such communication protocols may be implemented either at system level or application level. Repeating a message when no acknowledgement is received is well known in the field of data communication. Specific examples of such protocols include the Internet TCP/IP protocol and the Novell IPX protocol.
A deficiency of these frequently used protocols is that if a formerly valid destination of a message becomes invalid, the protocol typically returns an error to the sender only after a long delay during which the message is sent many times. This results in delays in corrective action such as reporting the problem to the sender of the message. Commonly this problem is ignored under the assumption that invalid addresses are relatively rare in the system and that negating them systematically would be prohibitive.
A possible solution to this problem is to maintain a list at the system level of all clients who hold copies of a given software address. If the system determines that an address is invalid, all clients are informed. This eliminates delays due to use of addresses that have been discovered to be invalid, and permits all entities holding copies of the address to be up to date. However, this approach is wasteful since the system must maintain a list of clients for every address that may be negated, requiring a large amount of memory. Furthermore, upon negation of an address, the system must inform all the clients even though many of them might not intend to use the cancelled address again. Additionally, the clients must be configured to be able to receive a negation message and update their address lists accordingly. In an existing system this may be a costly endeavor.
Thus, there exists a need in the industry to provide an improved system and method for negating invalid addresses in a network system.
SUMMARY OF THE INVENTION
For the purpose of this specification, the expression “software object” is used to designate a collection of related data with an interface that defines the operations available on that data. The software code for the software object is generally written in a programming language appropriate to its functions, such as Smailtalk, C++, Pascal, Java, or Assembler.
For the purpose of this specification, the expression “persistent name” is used to designate the static name of a software entity that external software objects use to communicate with it. The persistent name is typically independent of the location of the software entity in the software system. In a specific example, the persistent name of an object is in the form of a character string.
For the purpose of this specification, the expression “software object address” is used to designate the software location of an instance of a software object in a software system. This expression should be given a broad interpretation to include a handle to actual object addresses, handles to memory locations containing software addresses and other equivalents. Typically, within the object address is a hardware node address that specifies the network location of the software object. In the preferred embodiment, a Name Service translates the persistent name of a software object into its software object address. A particular object with a certain persistent name maintains its persistent name irrespective of the instantiation of that object. On the other hand, each instantiation of a certain object is typically given a different object address that is valid only for that particular instantiation. For example, if a subsystem of a distributed software system is taken out of service then is subsequently restarted on the same node or on some other node, each object in the restarted subsystem keeps the same persistent name that it had formerly, but is given a new object addresses.
For the purpose of this specification, the expression “visible software object” is used to designate a software object that may communicate with external software objects in software system.
In the preferred embodiment of this invention, addresses used in communication are stored in system-managed data structures, herein referred to as the Address Registry. Software objects in the software system access addresses in the Address Registry through handles or equivalent forms of indirect access. A common form of communication in such software systems is through message passing. The destination addresses of messages being sent from one software object to another are passed in the form of handles to entries held in the Address Registry. This use of handles or references to actual destination addresses is common in message systems such as CORBA. When a software object address is found to be invalid, it is cancelled by marking it invalid in the Address Registry, a process herein referred to as negating. When any holder of a handle to that address attempts to use the negated software object address, the message system by looking at the Address Registry determines that the address is invalid and returns an error at once without attempting to send the message. Software objects learn of the negation of a given software object address when they attempt to use the negated software object address. In this regards, software objects do not need to wait for a message to be sent multiple times and the message system does not need to maintain a list of the software objects that hold handles to a particular address in the Address Registry.
The invention also extends to a computer system implementing the above described Address Registry, and to a method for implementing a software Address Registry.
REFERENCES:
patent: 543491
Nortel Networks Limited
Winder Patrice
LandOfFree
Method and apparatus for negating invalid networking addresses does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Method and apparatus for negating invalid networking addresses, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Method and apparatus for negating invalid networking addresses will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2817793