JPH05189389A - Method for connecting large-scale distributed computer system forming hierarchical structure - Google Patents

Abstract

PURPOSE:To obtain a large-scale distributed computer system excellent in uniqueness, mobile transmission, extension, efficiency, availability and failure-durability by utilizing relative expression and changing the 'expression depending on a used location. CONSTITUTION:In the case a message is delivered by an object C to an object D, '3:2.21.52' which is the object ID(OID) of a receiver is converted into '2.21.52' when it is received by a name space manager having a local object ID (LID) is '12'. Then it is converted into '1:2.21.52', '0:2.21.52','0:21.52', '0:52' and '0' and delivered to the object D, and when it is received by the object D, it is converted into the OID indicating itself. To the contrary, '0:' which is the OID of a transmitter is converted into '3:1.12.41' when it is received by the object D. That is, the expression of the identifier of the object within the system is made based on the relative relationships between the position of the object using the identifier and that of the object indicated by the identifier when it is generated.

Description

Detailed Description of the Invention

[0001]

BACKGROUND OF THE INVENTION The present invention is an ID capable of uniquely identifying an object in the entire system from a locally unique ID.
The present invention relates to a method of configuring a large-scale distributed computer system that configures a network and realizes position transparent communication.

[0002]

2. Description of the Related Art In order to share one thing in a computer system, that is, to refer to the same thing from various places, it is convenient to give it a name. In the object oriented system, an object identifier (hereinafter referred to as ID) that is unique in the system is used for each object in order to share the object. In a distributed system, the object ID of the host where the object was born is
Uniqueness in the system by including the ID (the same ID corresponds to the same object, and the same ID represents the same object. That is, until the object ends its life,
ID does not change. ) Is a general method of guaranteeing.

In recent years, however, the scale of the system has been increasing, and it is becoming difficult to give each host a unique ID in the system unless an institution for allocation is made in each country. Also, in order to use a unique object ID in the system, it is necessary to prepare a very large ID. For example, in a conventional distributed system, an object is specified by a very large ID (for example, 72 bits). Moreover, considering the future development, there is always a risk of shortage.

Further, in a large-scale distributed system, there are hosts that can be moved, it is necessary to move objects for load distribution and communication efficiency, and the network structure may change. In such a case, for example
The IP address changes when the host moves to a different network, so it is necessary to be aware of the current location of the other party during communication. Therefore, it is desirable that communication can be performed without showing the user that the actual position of the host or object has changed (movement transparency).

Conventionally, there has been proposed a method for facilitating name management in a large-scale distributed system by expressing it using a hierarchical structure. However, the conventional method relies on the fact that the host identifier or the directory identifier is unique in the whole world, and in order to carry out the conventional method, one identifier assigning organization in the whole world is required. To do.

There is also known a method of converting the expression of the identifier according to the place where it is used. For example, in a system having a plurality of namespaces (domains), there is a system that names objects by sequentially specifying domains to pass through by ports. The name of the same object depends on the domain used. However, in order to realize uniqueness of the name, it is necessary to uniquely determine the naming path between two points regardless of the actual route, and as a result of realizing it by the conversion rule of the domain, When the rules were incomplete, the uniqueness could not be satisfied.

Furthermore, by expressing the identifiers of the object and the host in a position-independent manner and expressing the positions of the object and the host in a different manner, communication is performed without showing the user that the actual position of the object or the host has changed. Methods for doing so have also been proposed. For example, Virtual Internet Protocol (VIP). However, it uses the assumption that the host's identifier (virtual address) is globally unique, and, like the above, requires one identifier assigning authority worldwide to implement this method. ..

[0008]

SUMMARY OF THE INVENTION The present invention has been made in view of the above-mentioned circumstances, and has uniqueness, mobility and
Large-scale distribution with excellent scalability, efficiency (less overhead due to the use of wide area ID), availability and fault tolerance (less operation of ID due to distant host failure) The purpose is to provide a computer system.

[0009]

In order to achieve the above object, the invention of claim 1 of the present invention is an identifier of an object in a system in a large-scale distributed computer system having a local name space having a hierarchical structure. Is expressed on the basis of the relative relationship between the position of the object using it and the position at the time of generation of the object indicated by the expression, and the invention of claim 2 relates to the present position of the object in the system. The feature is that the expression is performed based on the relative relationship between the position of the object using it and the position indicated by it.

[0010]

According to the above means, the expression of the identifier of the object in the system is expressed based on the relative relationship between the position of the object using it and the position at the time of generation of the object indicated by it. Moreover, since the representation of the current position of the object in the system is performed based on the relative relationship between the position of the object using it and the position indicated by it, uniqueness, movement transparency, expandability, It is possible to realize a large-scale distributed computer system with excellent efficiency, availability, and fault tolerance.

[0011]

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS A local namespace having a hierarchical structure is logical, and the present invention can be applied to a system having a physically different structure. For example, several hosts connected by a network may share the same namespace, or one host may have several namespaces.

When the hierarchy is represented by a tree structure, it is assumed that the objects connected by the branches of the tree can communicate with each other, but other connections may be used as in a normal network. This kind of connection may be done manually, but if hosts at different layers are connected to the same local network, there is also an implementation method that automatically creates a connection as a result of communication through a tree branch. Conceivable.

In the present invention, OID (object ID) and OA
D (object address) is supposed to be converted every time it is transferred to another namespace, but the communication path is recorded for the argument OID other than the sender and receiver during communication. By doing so, the recipient can convert them all at once. Even if the communication is encrypted, the recipient can convert it after decryption.

The present invention is a logically close object ID.
Has the characteristic that it can be expressed shortly and that even if the system grows, there is no shortage of IDs. In addition, this is an extension of the conventional virtual network and diffusion cache method, and can realize transparency regarding object migration and host / gateway movement.

Virtual networks address the problem of mobile transparent communication with a moving host. In the present invention, the virtual network and diffusion cache method are applied to the object instead of the host. Furthermore, by using this hierarchically, it is possible to cope with the movement of the host and the structural change of the network. In virtual networks, the host ID is assumed to be unique across all networks. In the hierarchical relative naming method, the expression of the object ID and the object address is rewritten every time the namespace having the tree structure is transferred, thereby giving a short ID and address to a close object,
The object ID can be uniquely identified by the object ID in any namespace.

In the present invention, a method of constructing an object ID and a virtual concept of "interpretation" will be described below. Furthermore, we describe the realization of transparency for the object migration and explain it for the movement of the host and the change of the network. Next, we describe a method of connecting and growing distributed systems, and describe problems and solutions when implementing them.

The large-scale distributed system used in the present invention is
It has the following properties. Very large scale: The scale of the system is so large that broadcasting is impossible. It is also difficult to give a unique fixed length ID to all hosts. In addition, the objects / hosts move individually. Locality: distant (eg different local networks)
Communicating with, moving an object to, or moving a host to is far less common than doing it nearby.

(1) Object ID and its Interpretation Here, it is assumed that the system has a hierarchical local namespace (this is not a constraint on the physical structure of the system). That is, each local namespace gives the object created there a local object ID (LID) that is unique in that local namespace. The namespace is also an object, so it has a unique LID within its parent namespace. Actually, it is possible to correspond to the hierarchy of wide area network, local network, and host, and the hierarchy of microkernel, operating system, and process. This does not necessarily correspond to the physical structure. For example, several hosts connected by a network may share the same namespace. In this case, uniqueness can be guaranteed by including the host ID in the LID. Also, although it may be unrelated to the social structure (company, country, etc.), when the hierarchy is represented by a tree structure, it is assumed that objects connected by tree branches are always communicable. Other connections, like normal networks, are fine. This kind of connection may be done manually, but if hosts in different layers are connected to the same local network, an implementation that automatically creates a connection as a result of communication through a tree branch is also considered. Be done.

FIG. 1 shows an example of a hierarchical local namespace. To avoid confusion, we used all different LIDs, but duplicate namespaces are allowed in different namespaces.
Connections other than the hierarchical tree structure are omitted.

Using this LID, an object ID (hereinafter referred to as OID) that is substantially unique in the entire system is constructed. "Practically" means that the OID itself is not unique,
The interpretation of the OID in the namespace in which it is used is to uniquely identify an object in the entire system, similar to the conventional object ID. OIDs that represent the same object vary depending on the namespace used, and in different namespaces, the same OID can represent different objects. However, within the same namespace, the same
OIDs represent the same object, different OIDs represent different objects.

The interpretation of the OID is a virtual one for showing uniqueness, and is not actually used in the namespace. In each namespace, the object can be identified only by the OID and does not need global information used for interpretation.

The format of OID is as follows. m: l _{1.l2 .. ..l n} where m, n are positive or integers 0 and each l _i is LI
It is D. That is, `` ..
Think of the number of / '' written before the :.

The "interpretation" of OID is defined as follows. Definition 1: Interpretation of OID OIDm: l _1.l2 .... _{.l n} The interpretation in the namespace S is the root of the current namespace hierarchy (the root may change depending on the growth of the system, but there is always one There is only one in the system) and the sequence of _LIDs from S to L _1.L2.
.L _n , then L _1.L2 .... .L _{Nm .l1.l2 .. ..l n} .

This is considered to represent the namespace in which the object was born and its LID. The position of the object is represented by the object address described in the next section. According to this interpretation, from the perspective of a namespace manager, the OID that represents an object whose LID is l is 0: l
Is. Also, when the object is not moving, the OID that represents the object whose LID is l in the same namespace from the viewpoint of an object is 1: l, and the OID that represents itself is
Is 0 :. Note that the OID as seen by the namespace manager is different from the OID as seen by the objects in that namespace. In Figure 1, B has an OID of 1:32 and D has an OID of 3: 2.21.52 as viewed from object A. Looking at B and D from C, the OID is 2: 11.32,
3: 2.21.52. The interpretation of OID of B is 1.11.32 from both A and C, and that of D is 2.21.52.

When transferring an OID, for example, when a message (one unit of communication is called a message here) for communication is transferred to another namespace, the sender, receiver, and argument OID of the message are , OID is converted so that it does not change the interpretation. If we send a message from C to D in Figure 1, the recipient OID 3: 2.21.52 has a LID of 1
2.21 when received by a namespace manager that is 2.
Converted to 52. Below 1: 2.21.52, 0: 2.21.52, 0:21.
It is converted to 52, 0:52, 0: and reaches D. When you arrive at D, it has been converted to an OID that represents you. Conversely, the sender OID 0: is 3: 1.1 when it reaches D.
It has been converted to 2.41. The rules for this conversion are as follows. If OID is m: l _{1.l2 .. .l n} ,

Rule 1: OID conversion a) When transferring to the parent namespace, m is decremented by 1 if m is positive. If m is 0: followed by your LI
Insert D. However, this conversion is done in the parent namespace. You no longer need to know your LID. b) When transferring to a child namespace or normal object whose LID is l, increase m by 1 if m is positive. If m is 0, l and l ₁ are compared, if they are equal, delete it, and if they are different, m is incremented by 1.

C) When directly transferring to a namespace other than the above, the above conversions that are performed when the namespace is reached through the branches of the namespace tree are performed in order. In summary, the OID of the destination namespace is M: L _1.L2 .... L _N , and the OID of the destination as viewed from the destination is N: L '_1.L'2 .... If L' _M and m> M, then replace m by m-M + N. m <M
In case of, replace m with N, and after L: _1.L'2.
・． Insert L' _Mm . When m = M, l _{1 = L1,} ...
_{Find the} maximum k such that, l _{k = Lk} (k = 0 if l ₁ ≠ L ₁ ), delete k LIDs after: and replace m with Nk.

According to this rule, the manager of each namespace is
You don't have to know how the OID is interpreted. In particular, when communicating directly with the parent or child namespace only, the namespace manager need only know the child's LID, not the other manager's LID and so on. To check whether two OIDs in different namespaces represent the same object, you can transfer to the same namespace using Rule 1 and then compare without using interpretation.

(2) About Object Address and Object Migration The object address (hereinafter referred to as OAD) is a hint of the current position of the object. In addition to its body, the OAD has a time stamp that indicates when the information was. OA
The body of D uses a local object address (LAD) instead of the LID part of OID.
That is, each namespace gives its objects a unique LAD in that namespace and uses it to construct the OAD. When an object is born, LID and LAD are equal. The interpretation of OAD is similar to that of OID, but what it represents is a hint of the position of the object.

When sending a message, the OID of the other party is used to specify the recipient. Actually, it is used as a pair of OID and OAD of the other party by adding a namespace manager, but this is invisible to the user. The other party is specified by OID and the other party's position is specified by OAD. The optimal route to the location indicated by the OAD is a routing issue and will not be discussed here. At worst, you can choose a route that goes through a tree branch. The message also includes your OID / OAD pair. The time stamp of your OAD is the current time.
When there is no object migration, OID and OA
The body of D has the same value, and the conversion rule when transferring is the same. In order to explain what happened when an object migration occurred, let me explain the information that each object has.

Each object has its own OID. This is 0: when the object is born, but it changes depending on the migration. This is used as the OID when the object is viewed from the outside.
When the namespace moves, as in (3), the OID is converted inside and outside the namespace, but in the case of moving the object, it can be considered that it has been optimized. In addition to this, the namespace manager, Object, is responsible for all objects created in that namespace.
It has a set of LID and OAD, and a set of OID and LAD for all objects currently in the namespace.
The one that applies to both of these is OID = LAD, so
For implementation, remember the LID in use. Furthermore, looking at the message that passed through that namespace,
Support LAD support (this can be omitted). The reason why the information of the recipient is not cached is that uncertain information is not learned. If there is a connection other than the parent or child, the OID of the connection destination and the OID that viewed you from the connection destination are required. In addition, when moving the namespace as described in (3), an OAD that represents the source to the destination is also required.

The object migration follows the following procedure. Step 1: Object migration a) Start of movement The manager of the current namespace (hereinafter, the current address) knows that the object will start moving. The current address manager invalidates the OID / LAD pair for that object.
Communication to that object is suspended. b) Movement The object actually moves. The OID of an object is converted including its own OID. c) End of transfer Ask to assign a new manager LAD with the current address. LA
D should not be duplicated with the LID of the object whose home is here. This is even after migrating
This is because when the object comes back, it will be a problem.
The current address manager remembers this OID / LAD pair.
The object then notifies the OID and LAD of the manager of the namespace (hereinafter referred to as the permanent domicile) in which the object was born. It should be noted that, in practice, the management may be carried out by the manager of the current address. The permanent manager updates the OAD and returns a confirmation notice. The moved object repeatedly sends OID and OAD notifications at appropriate intervals until it receives a confirmation notification. This is to deal with the case where the permanent manager is separated by the network division.

In FIG. 2, the object B moves and the LID
And as a LAD from the namespace manager whose LAD is 21
I just got 53. At this time, B's own OID is converted from 0: to 3: 1.11.32. B
Is a permanent manager 3: 1.11 with his OID 3: 1.11.3
Send 2 and OAD 0 :. This information is cached in the namespace indicated by *. In particular, the permanent address and the current address (marked with a circle) are always stored. Movement notification OID and OA
Since D is also converted according to Rule 1, for example,
It is a set of 0:32 and 2: 2.21.53.

At the time of communication, in each name space, the OID of the recipient of the message is checked and the following rewriting is performed on the OAD.
This is after the conversion of rule 1 of (1) when it is an OID / OAD received from a child, and before it when it is received from a parent or other, that is, the expression of OID / OAD in the namespace. Do when

Rule 2: Object in namespace N
Rewriting A's OAD a) If A is in N, or is an object born in N, replace OAD with the correct OAD known by N. b) According to OAD, A will send back an error message if it is in N but not really. It should be noted that there is a method to return the OAD to the same as the OID and transfer it to the OID with the time stamp as it is, without making an error. In the namespace where the error message passed, if the OID and OAD
Disable if the correspondence of is cached. c) If N is a combination of OID and OAD of A, and the cache is newer, replace OAD with the OAD of the cache. d) In other cases Do nothing.

After that, a message is transmitted using this address information. Assuming that a message is sent from object A to B in Fig. 2, BID's OID when the message is constructed.
Both OAD and OAD are 1:32 (OAD is not used in normal objects, but treated as OID = OAD).
D is rewritten from 0:32 to 2: 2.21.53. On the other hand, when sending a message from object E to B, the recipient OAD, which was 3: 1.11.32 at the time of configuration, uses the information that the LID and LAD are cached in the namespace of 1: 1.11.
Rewritten from 32 to 0: 21.53, reaching Object B without going through permanent domicile.

(3) Movement of Name Space and Dynamic Change of Network Here, the name space is moved by software, the host is physically moved, or the gateway is moved together with the local network. Discuss the case. Here, it is assumed that the host and the local network also constitute one namespace. In the case of such movement, it is considered that the objects in the namespace also move together. Otherwise, for example, when one host has only a part of the namespace, it can be treated as the migration of the object on that host.

When the namespace moves, it is not efficient to convert the OIDs of all the objects in it. Therefore, the OIDs other than the name space manager are left unchanged, and the managers convert each other when communicating with the outside. The OID of the manager is changed according to Rule 1 as in (2). Also, in the connection confirmation notification, the OAD of the transfer destination as seen from the original domicile is requested to be returned to myself (so as not to be converted due to the OAD being transferred). Then, because of the address conversion of the descendant object of the manager, the conversion by the cache is also performed for the OID of the descendant object. The change in OAD due to the movement of the manager is transmitted by the diffusion cache, so the message is correctly sent to the object in that namespace. Even if the manager communicates with an object he has migrated before moving, the message is sent correctly because the manager knows the correct location.

The rewriting rule 2 of (2) is changed as follows. Rule 3: Rewriting OAD of object A in namespace N a) When A is an object or its descendant in N, that is, when OID of A is m: l _1.l2 ..... l _n , There exists 1 ≤ k ≤ n, and when the object B with OID m: l _1.l2 .... .l _k is N, and the LAD of B is L, the OAD of A is 0: replaced by Ll _{k +} 1 ··· .l _n. The time stamp is the current time. If b) A is born Obujiekuto and their descendants in the N In other words, the OID of the A _0:. When the _l 1.l2 ··· .l _n, LI
O of B if the object of D is l ₁ and B is born of N
_Is M: L _1.L2 ..... L _N , the OAD of A is M: L _{1.L2.
.. Replace with} .L _{N .l2} .... _{.l n} . The time stamp is the time stamp of OAD of B. c) When the OAD of A is a descendant of N but the current address is different, that is, the OAD of A is 0: L _1.L2 ..... L _N, but the LAD is L ₁
If no object in N exists, return an error message.

D) If A is N and the object or its descendant that has a combination of OID and OAD and the cache is newer, that is, the OID of A is m: l _1.l2 .... l _n When there is a certain 1 ≤ k ≤ n, the OAD of the object B _whose OID is m: l _1.l2 .... .l _k is cached, and its time stamp is greater than the time stamp of the OAD of A. When it is new (when there are multiple k's, the newer time stamp is used), the OAD of B is M: L _1.L2 ..... L _N, and the OAD of A is M: L _{1.L2. .} replaced by _{··· .L N .lk + 1. ···} .l n. The time stamp is the time stamp of OAD of A. e) In other cases Do nothing.

In the moved namespace, OID and OAD
The following conversion is performed. Rule 4: OID in namespace N and conversion of OAD OID of N is M: L _{1. L2} ..... L _N , NAD of OAD at the destination seen from the domicile of N-1: L ' _{1. L'2} .... When we say L' _M ,

I) When transferring to the parent namespace: After rewriting the OAD according to rule 3, a) OID conversion: If OID is m: l _1.l2 .... l _n , m> N When: Replace m with m-N + M. When m <N: Replace m with M, and after: L _1.L2 ...
・ Insert .L _Mm . When m = N: Find the maximum k such that l _{1 = L'1} ..., l _{k = L'K} (if l ₁ ≠ L ' _1, set k = 0), Remove the LID and replace m with Mk. b) OAD conversion: OID only if OAD is not a descendant of N
Do the same conversion as. When this is transferred to the parent, the parent (1)
The conversion described in Rule 1 is performed.

Ii) When received from the parent namespace: a) OID conversion: _Letting OID be m: l _{1.l2 .. .l n} , if m> M: m is m-M + Replace with N. When m <M: Replace m with N, and after: L'_1.L'2.
・ Insert _.L'Mn . When m = M: _{Find the} maximum k such that l _{1 = L1,} ..., l _{k = Lk} (k = 0 if l ₁ ≠ L ₁ ) and delete k LIDs after: And replace m with Nk. b) OAD conversion: OID only if OAD is not a descendant of N
Do the same conversion as. After that, the OAD is rewritten according to Rule 3.

A specific example will be given. Figure 3 shows that LID and LAD
The namespace N, which is 12, has just moved and has received 23 as the LAD. The OID and OAD of this namespace are cached as in Section 4 (indicated by * and ○). Now, if you want to send a message from object A to F, initially, the OID and OAD of F are 2: 12.42, but the LID and LAD are 1.
OAD is rewritten from 0: 12.42 to 1: 2.23.42 in the namespace. When it reaches N, the OID is 2: 1.12.42, OA
D is 0:42, but here the OID is 4 by 0:42
Converted to (as OAD is a descendant, so it is), and the object
Reach F On the other hand, when sending a message from object C to B, the OID of B seen from C does not change even when N moves, so at first it is 2: 11.32, but at N it is rule 4
Will convert from 1: 11.32 to 2: 1.11.32.

A problem when the host physically moves is how to configure its own OID at the move destination. This is also necessary to know the OID of the permanent manager who should tell you where to connect. In the case of object migration, there was no problem because my own OID was also converted during movement, but in the case of physical movement, since it is connected suddenly, OID conversion is not possible. In addition, there are few cases where the destination is known at the time of cutting.

By the way, considering the format of OID, it is understood that it is sufficient if the number of stages to a common ancestor and the sequence of LIDs from that point to oneself are known. Therefore, at the time of disconnection, some OID candidates are received from ancestors according to the range to be moved. Whether or not the permanent manager can be called correctly is confirmed by an appropriate authentication method (for example, public key authentication). If successful, the OID is confirmed. Authenticating with a key is similar to having a unique ID in the entire system, but since it is used in a limited number of cases, it is possible to reduce the duplication probability by using as long as necessary. Since it is used together with OID candidates, this probability is originally small.

(4) Connection of Systems Here, a method of connecting systems using the hierarchical relative naming method will be described. If you don't disturb the tree structure, the connection is fine. In other words, you can either make one root a child of the other namespace or create a new root that is the parent of both roots. In some cases, the interpretation of OID and OAD will change at the same time as connection, but since this correctly represents the permanent domicile after connection, the LID there, and the hint of the current position, it is not necessary to change the existing OID or OAD, and the connection The work for is local.

In a very large scale distributed system, it is possible to try to connect the same two systems at different places. For example, when the left and right systems in FIG. 4 are connected like I, they are connected like II at another place. If you connect in this way, there will be two or more OIDs that represent the same object, and you will not be able to meet the requirements for an ID. This can happen because of the way one (system A) root becomes a child of another (system B) namespace. In this case, assuming the proper authentication method, the following connection protocol is used.

Confirmation at the time of connection a) Confirmation of the root Obtain the authentication of the root of B and check whether it belongs to A's root. If they are different, you can connect them, so proceed to the next step. If they are the same, then it is likely that they are already connected, so send the message as the OID of the root of B and confirm that the root of A receives. b) Rock the root of rock A and make sure that the root of rock B is not locked. If it was locked, unlock A to avoid deadlock, wait for B to unlock, and try again. c) Determine the LID of A in the namespace of connection B and connect. d) Unlock the root lock of Unlock A.

When it is desired to make a connection other than the parent-child relationship of the hierarchy,
For example, if you want to connect two systems at one place and then increase the number of connections, you need to know each other's OIDs. In a very large-scale distributed system, it is often the case that the OID of the other party cannot be immediately known even if they are connected as one system. Even in such a case, if an appropriate authentication method is used, the common ancestry can be found and the OID of the other party can be determined by obtaining authentication of ancestors in the order of 1 :, 2 :, 3:, .... it can.

(5) Problems in implementation When implementing the hierarchical relative naming method, there are problems that did not exist in the past, that OID / OAD has a variable length, OID / OAD
Is required to be rewritten each time it is transferred. It is inefficient because it needs to know which part of the message represents the OID / OAD and rewrite it (to a different length). Also, the method of assigning a host ID is not a global finite ID like the current IP address, but a method suitable for a hierarchical relative naming method is desired. Hereinafter, these problems will be described in order.

Variable length of OID / OAD OID and OAD are actually used only when objects are referenced in different address spaces. A short fixed-length ID when dealing with objects in the program
(Hereinafter referred to as SID). SID is a unique ID in the program's address space. When an object is created in that address space, only the SID is assigned. When it becomes known to the outside by making the object an argument of a message, assign the LID,
Configure OID. When an object in the external address space is referenced, the SID is assigned to it and used for reference. If an object is no longer referenced, that is, it has no LID assigned and is no longer referenced in its address space, its SID is reused. For this reason, it is sufficient for the SID length to be able to assign different SIDs to all the objects used in the address space.

The SID is actually the index of the object table. The addresses of objects in the same address space are written in the table.
The OID is written to the external object or the object referenced from the outside. Neither of these objects can be written, so this table tells you how to access them. At the time of communication, the program executes a kernel call for communication with SID as an argument. In the kernel, the SID is converted to OID and sent out, and the receiving kernel converts the OID into the SID of the recipient's address space. If the recipients have the same address space, this conversion can be omitted. Also, even if the address space is different, if the same host, it can be converted to the receiver SID in a more efficient way.

OID / OAD must be rewritten each time it is transferred. OID / OADs other than the sender and the receiver are not used in the middle of communication, so if they are converted collectively by the receiver, it will be considerably faster. Can be expected. Therefore, the route being communicated is recorded and collectively converted as in the case of “direct transfer” in rule 1 of (1). Even if the communication is encrypted, the recipient can convert it after decryption, so there is no problem.

How to assign a host ID When a host constitutes one namespace, when assigning an OID (host ID) of that namespace, ideally it should be done as follows. It gets the LAD from the local network that first connected the host and uses it as the network address. When sending a packet, specify the LADs of yourself and the other party as sender and receiver, and treat the sender and receiver OIDs as the packet data. When connecting a local network to another (large) network via the gateway, use the local network as one namespace and get the LAD of the local network from the connected network. This is used as the gateway address in the connected network. The gateway address is known to all hosts on the local network. If necessary, make connections other than parent-child relationships in the hierarchy. If you repeat this connection,
Host ID without needing a single ID assigning agency worldwide
Can be attached, and there is no shortage of ID.

However, the compatibility with the existing IP connection network cannot be ignored. At present, the IP address is a host address whose uniqueness is guaranteed on a global scale, so it is possible to implement the LAD without changing the IP address. In this case, the network communication will be more efficient if the conventional virtual IP implementation is used.

[0057]

【The invention's effect】

(1) In the present invention, in a large-scale distributed computer system having a local name space having a hierarchical structure, the representation of the identifier of an object in the system, the position of the object that uses it, and the generation time of the object indicated by the object And the representation of the current position of the object in the system based on the relative relation between the position of the object using it and the position it indicates. Therefore, it has the following effects. a) A unique ID can be given to an object. b) Can communicate with nearby objects using short IDs. c) Capable of supporting system growth. d) Communication is possible only with local information. e) It can handle the movement of objects. f) It can cope with the movement of the host and the dynamic change of the network.

(2) The details are as follows. In the present invention, the expression and the interpretation of the object ID and the object address are separated, and the relative specification is used for the expression, and the expression can be changed depending on the place to be used, so that the efficiency can be improved. Also, since the ID is associated with the conventional ID and address by interpretation, the guarantee of uniqueness can be handled in the same manner as in the conventional case. Interpretation is virtual and does not require the global information used for interpretation in the implementation. In particular, when connecting to another distributed system, the interpretation of IDs and addresses that have been used remains unchanged and the interpretation changes all at once, making it scalable and suitable for large-scale systems and growing systems. Being able to operate IDs and addresses with only local knowledge improves availability. Furthermore, by using the virtual network and the diffusion cache method in a hierarchical manner, it is possible to realize the migration transparency to the object migration, the migration of the host, and the structural change of the network.

Further, in the present invention, an appropriate authentication method is required to ensure the movement of the host and the connection of the system. However, when actually using a large-scale distributed system, confidentiality protection and authentication are always required. So this is not a particular limitation.

[Brief description of drawings]

FIG. 1 illustrates a hierarchical namespace according to the present invention.

FIG. 2 is a diagram showing a state of object migration in a hierarchical name space according to the present invention.

FIG. 3 is a diagram showing movement of namespaces in a hierarchical namespace according to the present invention.

FIG. 4 is a diagram showing a situation in which a problem occurs in a system connection in a namespace.

Claims (2)

[Claims] 1. In a large-scale distributed computer system having a hierarchical local namespace, the identifier of an object in the system is represented by the position of the object that uses it and the position at the time of generation of the object indicated by it. Large-scale distributed computer system characterized by being performed based on the relative relationship with 2. The hierarchy according to claim 1, wherein the representation of the current position of the object in the system is performed based on the relative relationship between the position of the object using it and the position indicated by it. A large-scale distributed computer system with a structured local namespace.