WO1998013758A1 - Distributed processing - Google Patents
Distributed processing Download PDFInfo
- Publication number
- WO1998013758A1 WO1998013758A1 PCT/GB1997/002606 GB9702606W WO9813758A1 WO 1998013758 A1 WO1998013758 A1 WO 1998013758A1 GB 9702606 W GB9702606 W GB 9702606W WO 9813758 A1 WO9813758 A1 WO 9813758A1
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- computer
- data records
- compiler
- data
- code
- Prior art date
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/465—Distributed object oriented systems
Definitions
- This invention relates to distributed processing, particularly but not exclusively distributed processing for control of a telecommunications network, and with developing and updating the control systems implemented on the distributed processors, which are preferably (but not necessarily) processes implemented in an object-oriented fashion.
- Telecommunications networks are increasingly required to support high bandwidth, low delay information flow.
- the bandwidth required is rapidly progressing from kilobits per second to megabits per second and even, for some applications, gigabits per second (particularly, for example, for video on demand; animated shared simulations, and distributed computing).
- object oriented computing refers to the computing technique in which data is stored in "encapsulated” form in which, rather than being directly accessible by a calling program or routine, the data is accessible only by a limited part of a program which can read, write and edit the data.
- a record of data and its associated computer code are referred to as an "object".
- Communication to and from an object is generally by "message passing"; that is, a call to the object passes data values and invokes the operation of one of the programs comprised within the object, which then returns data values.
- Distributed processing differs from single processor operation in several respects. Firstly, different access techniques may be required depending on whether other programs or data are located on the same host computer as a calling program or on a different host computer. The location of a program or data will also affect the speed with which it can be reached from another program. Also, one or more host computers may fail whilst leaving others in operation.
- Distributed computing is conventionally performed, by using a "client-server” arrangement in which a "client” program on one computer interrogates a “server” program on another computer which then performs the function or returns the data required by the client program.
- the present invention provides a compiler (or pre-compiler) for generating code for use in distributed processing on a plurality of host computers (for example for controlling telecommunications systems) which is arranged to receive a source program written in a computing language, and to amend the source program to adapt it from single processor execution to multiple processor execution.
- a compiler or pre-compiler for generating code for use in distributed processing on a plurality of host computers (for example for controlling telecommunications systems) which is arranged to receive a source program written in a computing language, and to amend the source program to adapt it from single processor execution to multiple processor execution.
- this aspect of the invention comprises a pre-compiler which can then be used with a more conventional compiler, it but will be recognised that the functionality of the invention could be incorporated directly into a re-written compiler.
- the invention conceals from the programmer the complexities of adapting the program to operate on many different processors, reducing the time required to produce an executable program.
- the executable program produced by the invention is a single executable program which may be distributed to all processors of the distributed computing system in identical copies. This makes it easy to add new host processors to the distributed computing system.
- the source program is in an object oriented language, and is preferably in C++.
- C++ provides additional problems in compilation for distributed environments, since it is intended for single processor compilation and different processes communicate via shared memory pointers, which cannot operate in a multi processor environment.
- a virtual function is usually used to support the possibility of "inheritance”, which is often used in object oriented programming, as a way of indicating that one class of objects is a type of example of a more general class.
- Virtual functions are provided in C++ by declaring a virtual function name in a (superior) class, but providing the code to execute the function in one or more inferior classes; in other words, subordinate classes which inherit the properties of the superior class.
- Each C++ object in a conventional, single processor C++ system, occupies a certain amount of computer memory within which the data comprised within that the object are stored. Additionally, if the object is of a class which uses virtual functions, the memory within which the object is stored will also store a table of pointers (the "virtual pointer table” or VPTR) which, as the name implies, stores one or more pointers to the memory locations of corresponding one or more blocks of program code which implement the virtual function for the object.
- VPTR virtual pointer table
- C++ is intended as a single processor language, rather than a distributed processing language, this arrangement is usually satisfactory. However, we have realised that it is unsuitable for use in a distributed object oriented environment if it is desired to move objects between different host computers (or, more generally, different processes).
- a particular aim of the present invention is therefore to provide a distributed object oriented computing system in which objects using virtual pointers may be moved or copied within the system.
- each host computer within the distributed computing system, means for reading an object; separating the data elements thereof from the virtual pointers thereof; and transmitting the data elements thereof to a further computer.
- each computer preferably additionally or alternatively comprises means for receiving data elements of an object from a further host computer; means for creating a new object of the same type but with dummy data locally; and means for inserting the received data values, but not virtual pointer values, into the object thus created to replace the dummy data therein.
- a compiler or precompiler which accepts conventional C++ (or other object oriented) source code, and, on detection of virtual functions, adds additional code to make objects of classes having the virtual functions movable to and/or from the target processor for which the code is compiled.
- the additional code comprises, for each class, a special object constructor function which can create a new object with dummy data values but correct virtual pointers; a function for receiving messages or datagrams containing object data elements and inserting them into a created dummy object; and a function for copying object data elements into a message or datagram and transmitting the same to another host computer.
- This embodiment may be utilised in a system in which a single compiler compiles all copies of the code to run on the computers of the distributed system, but its use is not limited to this situation; an advantage of the embodiment is that an object may be sent from a first computer running code compiled by a first compiler to a second computer running code compiled by a second, different, compiler.
- Figure 1 is a block diagram illustrating the elements of a telecommunications systems embodying the invention
- Figure 2 is a block diagram illustrating further embodiments of the system of Figure 1 ;
- Figure 3 is a block diagram illustrating the elements of a host computer forming part of the system of Figures 1 and 2;
- Figure 4 is a block diagram illustrating the elements of a compiler apparatus forrriing part of the system of Figures 1 and 2;
- Figure 5 is a flow diagram illustrating the operation of the compiler apparatus of Figure 4;
- Figure 6 is an illustrative drawing indicating the products of stages of processing performed in Figure 5;
- Figure 7a is a diagram representing the structure of data held within the intelligence domain forming part of Figure 1 ;
- Figure 7b is a diagram representing the structure of data held within the transport domain forming part of Figure I ;
- Figure 8 illustrates the data structure within memory of one component of Figure 7a
- Figure 9 illustrates the operation of the pre-compiler of Figure 4 in augmenting original source code held in the source code store of Figure 4 to produce extended source code
- Figure 10 illustrates schematically the movement of an object according to an embodiment of the invention
- Figure 1 1 is a flow diagram showing schematically the pre-compiling process performed in an embodiment of the invention
- Figure 12 illustrates the structure of an object location table held within memory as part of the object manager program of the host computer of Figure 3;
- Figure 13 illustrates the structure of a host status table stored within the memory of the host computer of Figure 3 as part of the object manager thereof;
- Figure 14 (comprising Figures 14a and 14b) is a flow diagram illustrating the updating of the host status table;
- Figure 15 is a flow diagram illustrating the process of moving an object from one host computer to another.
- Figure 16a is a flow diagram illustrating in greater detail part of the moving process of Figure 15 performed at the originating computer
- Figure 16b shows the corresponding process performed at the destination computer
- Figure 17a shows the structure of a message used to convey an object in the embodiment; and Figure 17b shows in greater detail a portion of that message;
- Figure 18 (comprising Figures 18a, 18b and 18c) is a flow diagram showing the process of transmitting a message to an object on a remote host computer.
- a telecommunications system produced according to the invention comprises a plurality of switching centres or exchanges 2a, 2b interconnected by communications channels 4 (e.g. microwave links, fibre-optic cables, coaxial copper cable or virtual circuits carried on any of the foregoing) making up a transport domain 6.
- communications channels 4 e.g. microwave links, fibre-optic cables, coaxial copper cable or virtual circuits carried on any of the foregoing
- an intelligence domain 8 comprising a plurality of host computers 10a, 10b in signalling communication with the switch centres 2a, 2b via signalling links 12a, 12b, 12c which also interconnect the host computers 10a, 10b.
- the two may be interconnected using protocols such as signalling system 7 (SS7).
- SS7 signalling system 7
- End user apparatus such as telephones 14a, 14b and broad bandwidth communication devices such as video players 16, jointly comprise an end user domain 18 connected to the transport domain 6 via local loop connections 20a, 20b. 20c (for example optic fibre, cellular radio or twisted pair copper cable links).
- 20c for example optic fibre, cellular radio or twisted pair copper cable links.
- a service provider domain 22 consisting of equipment for providing services (for example video services), such ELS a video player 24 and a computer terminal 26, connected with the transport domain 6 via local loop connections 28a, 28b, 28c such as ISDN channels or other high bandwidth links.
- an end user terminal 14 or 16 is used to pass a request, via the transport domain 6, to the service provider domain 22.
- a channel is set up through the transport domain 6 and the service provider domain 22 transmits a service via the channel to the end user domain 18 (for example by transmitting a real time video film, or a file of data in electronic format).
- the transport domain 6 is controlled simply by the dialled numbers generated in the end user domain to set up the transport path.
- "intelligent network" control of the transport domain is provided by the intelligence domain 8.
- the intelligence domain 8 receives from the transport domain 6 the dialled number and/or the dialling number, and performs some call processing in accordance with either the dialled or the dialling number, or both.
- the intelligence domain typically provides number translation services, where a dialled phone number is translated to provide a call forwarding service to another number.
- the dialled number corresponds to a stored record on one of the host computers 10, which is accessed in response to a signal on one of the links 12, to generate a corresponding re-direction number.
- the intelligence domain in response to the occurrence of an event in the transport domain 6 (such as the initiation of a call from the end user domain 18) the intelligence domain supplies control information to control the transport domain 6.
- billing data for each call is stored in the intelligence domain, to enable periodic billing of each customer.
- the intelligence domain 8 further comprises a compiler apparatus 30, consisting of a programmed workstation, connected to the host computers 10 via network servers 1 1 a- 1 1 c and a wide area network (WAN) running between the compiler apparatus 30, the hosts 10 and the servers 1 1.
- a compiler apparatus 30 consisting of a programmed workstation, connected to the host computers 10 via network servers 1 1 a- 1 1 c and a wide area network (WAN) running between the compiler apparatus 30, the hosts 10 and the servers 1 1.
- WAN wide area network
- the servers are also connected to one or more World Wide Web (WWW) server computers comprised within the Internet 32, and hence to editing terminals 15a- 15d connected to the Internet (e.g. via a local packet switching node).
- WWW World Wide Web
- each host computer 10 comprises a mainframe or server comprising communications hardware 100 connected via the WAN to the servers 11; a processor 102; and storage 104, comprising both rapid access storage in the form of random access memory and offline storage in the form of magnetic or optical disc drives.
- Each editing terminal 15 comprises a personal computer, and may be connected via modem to a common telephone socket with a corresponding telephone 14 at a user's premises.
- Each editing terminal 15 therefore comprises a processor, a screen output device, an input device (e.g. keyboard and/or cursor control device such as a mouse), and storage apparatus ROM, RAM and a hard disc) containing a graphical user environment (e.g. Windows (TM)), a communications program and a object browser program.
- the compiler apparatus comprises a communications interface circuit board 300 connected to the WAN servers 1 1 ; a processor 302; and a storage apparatus 304 (not indicated separately) comprising rapid-access memory (RAM) and high capacity memory (e.g. a hard disc drive) and storing an operating system (e.g. UNIX (TM)), a C++ compiler program 312) (such as SunPRO available from Sun Microsystems); a pre-compiler 316 to be described in greater detail below; and a library 314 storing standard functions and definitions (specifying subprograms or subroutines) to be incorporated into new programs.
- RAM rapid-access memory
- high capacity memory e.g. a hard disc drive
- an operating system e.g. UNIX (TM)
- C++ compiler program 312 such as SunPRO available from Sun Microsystems
- pre-compiler 316 such as SunPRO available from Sun Microsystems
- library 314 storing standard functions and definitions (specifying subprograms or subroutines) to be
- the C++ compiler comprises, as is conventional, a compiler which compiles to relocatable binary code and a linker program 312b which concatenates the binary code with the binary code routines stored in the library 314 and locates the concatenated code in a memory address space for execution.
- Such compilers also generally include a pre-processor which interprets compiler directives, such as "include” statements to read in additional code, or perform other operations during compilations.
- a storage area 308 for storing input source code defining a C++ program (e.g. input via the input device 320, or downloaded via the communications circuit 300, or loaded via a disc drive comprised within the storage apparatus 204); and a storage area 310 for storing executable code generated by the C++ computer 312 (i.e. by die processor 302 acting under control of the compiler program). Also included is a storage area 318 which stores system data concerning the number of distributed processors 10; the capacity of the available storage memory on each of the processors 10; the speed of operation of the processors 10 and so on.
- the processor 102 is arranged to selectively run either the C++ compiler 312 on the source code in the source store 308, or the pre-compiler 316 followed by the C++ compiler 312 on the source code in the source store 308, to generate executable code in the executable code store 310.
- the processor 302 is, in the embodiment, itself arranged to be capable of executing the code directly generated in this manner by the C++ compiler, enabling the user to test immediately whether the program operates generally as expected
- the pre-compiler 316 first processes the source code in the source store 308 (taking into account any system data relating to the distributed system compnsing the host 10 on which the code is to be executed), and generates amended source code in the source store 308 which is then compiled by the compiler 312 to generated executable code in the executable code store 310.
- This executable code is, however, not necessanly executable on the compiler apparatus 30 since it is for execution on the multiple distributed hosts 10
- source code is input into the source code store 308 (e.g. via the input device 320).
- the human operator may decide to edit the source code in the source store 308, in which the edited text is input mto the source store 308 (e.g. using a conventional text processor).
- a step 206 the user may elect whether or not to test the source code locally. In the event that he does so, m a step 208 the processor executes the C++ compiler 312 on the source code in the source code store
- a simulation program may be provided to intercept meaningless operations and substitute operations such as displaying on the output screen 322, to enable the user to see what is happening.
- a step 212 the user may decide to return to step 204 to edit die source code in the source code store 308. If the source code appears satisfactory, then in a step 214, the pre-compiler 316 is applied to the source code in the source code store 308 to generate amended code, which is then compiled in a step 216 by the C++ compiler to generate executable code in the executable code store 310. This is then transmitted to the distributed host computers 10 in a step 218 via the WAN servers 1 1. This is illustrated graphically in Figure 6. The data model employed within the intelligence domain will now briefly be described.
- each "object” is a data record comprising a number of fields of data, which is accessed only by code which corresponds to that object (in a one to many relationship, in the sense that the same code which relates to a class of objects actually accesses all objects of that class).
- objects are grouped into classes, the objects of the same class containing different data but in the same format.
- Each object is associated also with one or more subroutines (generally termed “methods” or “functions”) which operate on the data, and which generally constitute the only means of doing so.
- Each class of object may be a subdivision of a more generic class, as is conventional in object oriented programming.
- the code may be stored instead in relation to the more generic class (the "superclass").
- the object manager 108 contains a list of the locations of the data making up each object, and on each invocation of (i.e. call to), an object, the object manager accesses the relevant subroutine code within the class code storage area 110 and supplies to the code the address of the data for the relevant object within the object storage area 112.
- the objects provided within the hosts 10 of the intelligence domain comprise a plurality of customer objects 500 (one holding data relating to each of tens of millions of customers) which are created on the accession of a new customer; destroyed when the customer voluntarily departs or is cut off from the network; and edited when a customer's requirements change: a plurality of call objects 600a-600c which are created at the outset of call and destroyed after the termination of the call; and a plurality of communication device objects 700a-700c which each relate to an item of customer terminal equipment, and are created on first connection of that customer terminal equipment to the network.
- customer objects 500 one holding data relating to each of tens of millions of customers
- the switching centres 2a, 2b... of the transport domain 6 further comprise host computers on which are stored objects 800a- 800b, 900a-900f which represent, respectively, the switches and the ports of the switches within the switching centres.
- each switch object 800 contains a record of the state of the corresponding switch at any moment; these objects exist permanently in memory and have a one to one mapping to the physical devices present in the switching centres 2, so that writing to the port or switch objects changes the state of the respective ports or switches, and reading the port or switch objects gives an accurate reflection of the actual condition of the corresponding physical devices.
- the attribute data maintained by the object 500 comprises a customer type field 502 (which may indicate that the customer is an employee or some other unusual status, or is a normal customer); a user ID field 504; a host field 506 indicating the host 10 on which the object 500 was created (conveniently as a Uniform Resource Location (URL), compatible with http and TCP/IP). Also stored is data relevant to the services provided to the customer; for example, the normal telephone number of the customer (field 508); a telephone number to which the customers calls are to be re-routed at particular times of day (field 510); and the times of day during which calls are to be re-routed (field 512). Finally, billing information for the customer is stored, in the form of a call log field 514 storing, for each call, the called (and/or calling) telephone number, the date and time of the call, and the cost of the call (field 514).
- a customer type field 502 which may indicate that the customer is an employee or some other unusual status, or is a normal customer
- the fields 508- 12 which define the service to be offered to the customer may be edited by customer service personnel or by the customer himself via an end user terminal 15, whereas billing data (field 514) should be writable only by the billing and accounting personnel operating the network. Certainly, no customer should be able to re-write his billing records from an end user terminal 15.
- the occurrence of events in the transport domain invokes the operation of the code associated with an object in the intelligence domain. For example, on a telephone going off hook in the end user domain, the code to create a new "call" object 600 is invoked.
- the called number is detected, it is transmitted via the signalling links 12 to the intelligence domain 8; the customer object 500 of the calling party is activated to amend the billing record field thereof; and the customer object 500 of the called party is accessed to determine the number to which the call should be forwarded, which information is then transmitted to the switch objects 800 within the transport domain to set up the path over which the call will be carried.
- the role of the intelligence domain is usually limited.
- the billing function code associated with the customer object(s) 500 updates the billing data field, and the call object is deleted by the object manager 108.
- the pre-compiler 316 in this embodiment comprises a parser program 316a which examines successive C++ statements in the source code store 308 and refers to stored C++ syntax graphs 316b to determine which elements of each statement are functions, variables and so on; and a code writing program 316c which, on detection of predetermined syntax conditions by the parser 316a, creates corresponding additional source code which is added to the source code in the source code store 308.
- the precompiler 312 reviews the original source code, locates classes which include virtual functions, and generates extended source code which provides additional code to enable such functions to be moved.
- Figure 10 illustrates generally the objective of the added code.
- XI on a first processor I0a is to be moved to a second processor 10b.
- the object includes a pointer to a function FI, which is at a memory location Ml in the memory space of the processor 10a.
- the corresponding function FI is at a memory location M2.
- the data contained within the object XI is moved by sending a message 3000 from the processor 10a to the processor 10b, the message containing the data elements of the object XI but not the pointer value pointing to memory location Ml .
- the precompiler 312 reads the source program in the source code store 308, in a step 2106, the preprocessor creates a new base class (e.g. DC as shown in Figure 9).
- the new base class may be included in the source code by a "#Include" statement to read in the new base class DC.
- msgtx which corresponds to the operation of reading the data elements from an object on the host computer on which it is running and writing them into a message for transmission for a remote host computer
- msgrx for receiving a message from another host computer, extracting data elements from it and inserting the data elements into an existing object to replace the dummy data stored therein.
- special constructor for creating a new object and filling its data fields with null or dummy data.
- the precompiler 312 also adds code (by including a #Include statement) to form part of the object manager program 108, specifically to send and receive messages and. on receipt of a message, to invoke the special constructor code to create a new null object in step 2104.
- step 2108 On each occasion (step 2108) on which the precompiler 312 encounters a class which declares a virtual function in the source code store 308, it amends the class declaration to make the class dependent on the new source class (DC), in step 2110. Then (step 21 12) the preprocessor 212 amendments the code for each subclass of the base class which declared the virtual function, so as to add definitions for each class of the three new functions defined in the new base class DC; in other words, code which reads the data values of an object of a class and packs them into a message; code which constructs a new object of the class and fills it with null data values; and code which unpacks a received message and edits the null data values to substitute the received data values.
- the precompiler 312 may perform the other operations referred to in our above referenced earlier patent applications. Runtime Operation
- the object manager program 108 (the "daemon") comprises, as will be described in greater detail, processes for creating new objects; processes for determiiiing the location (i.e. the host computer 10) on which given objects are stored; processes for sending messages to remote host computers; and processes for receiving messages therefrom.
- the object manager 108 for each host computer 10 comp ⁇ ses an object location table 1500 stonng a list 1510 of the objects currently in existence by name, and, associated with the record 1510a- 151 Oz for each object, an entry 1520a-1520z stonng the host computer 10 on which the object is currently stored, and an entry 1530a-1530z storing the identity of the host computer on which the object was initially created.
- a host table 1600 comp ⁇ sing status data on each of the host computers, from which the most suitable host computer to create a new object on can be de ⁇ ved
- This table therefore comp ⁇ ses a first set of entnes 1610a- 161 Oz stonng the identities of each host computer; an associated second set of entnes 1620a-1620z stonng the amount of free memory available on that host computer; a third associated set of entnes 1630a-1630z storing connectivity data for each of the host computers 10 (for example the number of other computers to which it is connected), and optionally other ent ⁇ es relating to, for example, processor speed.
- the object manager 108 of each host computer 10 penodically interrogates the operating system 106 thereof to determine whether there has been any change in any of the data stored in the table 1600 for that processor (e.g. whether there is now less memory available than previously) in a step 2002 and, on detection of a significant change in any such item of information, in a step 2004 the object manager 108 causes the transmission of a broadcast message via the communications apparatus 100 to all other host computers 10 listed in the table 600, signalling the new information concerned.
- any host computer 10 receives such a message in a step 2006
- the object manager 108 thereof updates the status table 1600 of Figure 13 to reflect the new information in a step 2008.
- each host computer 10 maintains up to date status information for all other host computers, as well as its own, within the table 16 of Figure 13. Moving/copving an Object
- objects need to permanently reside on a given host but may be moved from one host to another (i.e. deleted from the storage of one host and included in the storage memory of another).
- the object manager 108 for each host computer 10 reviews the status table 1500 thereof.
- the object manager program 108 determines whether an object is to be moved from the host computer 10 on which the object manager 108 is resident; for example if that host computer 10 is running out of available memory. If so. a suitable object to move is selected (for example, a rarely accessed object).
- a step 2034 the object table 1500 is reviewed to determine, from the entry in the corresponding field 1530 for the object, whether the object is currently residing on the host on which it was created. If so, (i.e. if the object has not moved since it was created) then in a step 2036, a new host is selected (in exactly the same manner as described above in relation to creation of a new object) and in a step 2038, the object is moved.
- step 2034 If in step 2034 it is determined that the object is not currently resident on the host computer 10 on which it was created (i.e. the object has already moved since it was created), in a step 2040 the object manager sends a message with this new host location to the original host computer 10 on which the object was originally created (as determined from the entry 1530 and the table 1500 for the object) and, after receiving an acknowledgement from that original host computer in step 2042, proceeds as described above (step 2036).
- the object manager or "daemon" 108 calls the message packing function (msgtx) of the object to be moved, and this function packs the data elements of the object into a message format (step 2124).
- the message 3000 consists of a header 3100 containing routing information (i.e. the address of the host computer 10b for which the object is destined) and information identifying the object (e.g. its name); and a plurality of data member segments 3200, 3300, 3400, ....
- a data segment 3200 consists of a header portion 3210, identifying the data member stored within the segment (e.g. by its field name); a data type field 3220 identifying the type of the data (e.g. single precision, double precision, floating point, string and so on); a field 3230 specifying whether the data member is a single element, an array element or a list element; and a field 3240 specifying the value of the data member.
- a header portion 3210 identifying the data member stored within the segment (e.g. by its field name); a data type field 3220 identifying the type of the data (e.g. single precision, double precision, floating point, string and so on); a field 3230 specifying whether the data member is a single element, an array element or a list element; and a field 3240 specifying the value of the data member.
- the first processor 10a under control of the message sending code of the object manager program 108. transmits the message 3000 to the second processor 10b. If no acknowledgement is received (step 2128) the message is retransmitted. On receiving an acknowledgement that the message was received, if (step 2130) the operation was an object moving operation, then the object manager program 108 deletes the object from the memory of the processor 10a (step 2132). Otherwise, if the operation was an object copying operation, the object is not deleted.
- the message is received (step 2142) and, in step 2144, the object manager program 108 determines the object name and class, and invokes the special creator function to create a new object of the required name, but with all data values set to null.
- the special constructor function acts as would a normal constructor function for an object of the class specified, and therefore creates an area of memory for each variable type declared for that class. It also creates a virtual pointer table, pointing to the addresses of the virtual functions declared within that class.
- step 2146 the object manager program 108 invokes the message unpacking function (msgrx) to store the received data element values in the corresponding data elements of the newly created object, overwriting the null values.
- msgrx message unpacking function
- step 2148 the object manager program 108 on the processor 10b transmit back an acknowledgement signal to the processor 10a to acknowledge receipt of the object data.
- the object manager 108 determines the current host processor 10, on which the object is recorded as being located, within the object located table 1500, and sends a message, calling the object, to that current host in a step 2050.
- the host computer 10 to which the message is addressed receives the message in a step 2052, it determines whether or not the object is recorded as being present within its own object location table 1500 in a step 2054. If present, the object is called in a step 2056 and any return message is transmitted back in step 2058, as described above.
- the host computer If not, then in a step 2060, the host computer signals back a failure to call the object.
- the originating host computer on receiving such a message in a step 2062, then sends an interrogation message to the original host computer 10 which is recorded in the table 1500 as being that on which the object in question was originally constructed, in a step 2066. Because of the separate location signalling steps 2040, 2042 of Figure 15, the object location table 1500 on the original host on which the object was constructed should be fully up to date in respect of that object.
- step 2068 when the original host computer receives, in step 2068, a location interrogation signal the object manager 108 thereof refers to the object location table comprised within it in a step 2070, and signals back the determined location of the object concerned in a step 2072.
- the first host computer receives the location signal from the original host and determines, in a step 2074 of Figure 18a, whether the host computer thus indicated as the location of the object differs from that to which a message for the object has already been directed in step 2050. If so, the object manager 108 updates the location table 1500 in a step 2076, and returns to step 2050 to repeat transmission of the message to the newly indicated host computer 10 location for the object.
- the object manager program 108 If the address received is the same as the address to which the message was previously directed, in a step 2078 the object manager program 108 returns a message indicating a failure to reach the object to the object, process or user from whence the attempt to call the object originated.
- each host computer 10 carries an object location table in which the location of all objects in the system is recorded, and each host is therefore able to operate autonomously, without reference to the central database, to call other objects on different host computers. Nonetheless, a higher level of integrity is added by providing that each host computer 10 additionally keeps track of the locations of all objects which were originally created on that host computer, even if the location of those objects subsequently moves to a different host computer.
- each host computer 10 maintains accurate records of those objects which are located within its own storage area.
- the invention is usable not only with C++ but with other object oriented languages such as Smalltalk (TM) which are to be provided in a distributed environment. More generally, it would be possible to utilise equivalent techniques with a non object-oriented language and on a non-distributed system.
- TM Smalltalk
Abstract
Description
Claims
Priority Applications (5)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US09/091,741 US6256779B1 (en) | 1996-09-27 | 1997-09-25 | Distributed processing |
EP97941128A EP0928450B1 (en) | 1996-09-27 | 1997-09-25 | Distributed processing |
CA002266912A CA2266912C (en) | 1996-09-27 | 1997-09-25 | Distributed processing |
AU43149/97A AU4314997A (en) | 1996-09-27 | 1997-09-25 | Distributed processing |
DE69734352T DE69734352T2 (en) | 1996-09-27 | 1997-09-25 | DISTRIBUTED PROCESSING |
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
GB9620196.7 | 1996-09-27 | ||
GBGB9620196.7A GB9620196D0 (en) | 1996-09-27 | 1996-09-27 | Distributed processing |
Publications (1)
Publication Number | Publication Date |
---|---|
WO1998013758A1 true WO1998013758A1 (en) | 1998-04-02 |
Family
ID=10800607
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
PCT/GB1997/002606 WO1998013758A1 (en) | 1996-09-27 | 1997-09-25 | Distributed processing |
Country Status (7)
Country | Link |
---|---|
US (1) | US6256779B1 (en) |
EP (1) | EP0928450B1 (en) |
AU (1) | AU4314997A (en) |
CA (1) | CA2266912C (en) |
DE (1) | DE69734352T2 (en) |
GB (1) | GB9620196D0 (en) |
WO (1) | WO1998013758A1 (en) |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2002048886A2 (en) * | 2000-12-13 | 2002-06-20 | Telefonaktiebolaget Lm Ericsson (Publ) | Telecommunications platform with processor cluster and method of operation thereof |
Families Citing this family (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6757903B1 (en) * | 1999-04-05 | 2004-06-29 | Gateway, Inc. | Object driven software architecture method and apparatus |
US20020129345A1 (en) * | 2000-09-27 | 2002-09-12 | Tilden Mark D. | Scripting business logic in a distributed object oriented environment |
JP2002116917A (en) * | 2000-10-05 | 2002-04-19 | Fujitsu Ltd | Compiler for compiling source program by object-oriented programming language |
US7047525B2 (en) * | 2001-04-02 | 2006-05-16 | American Express Travel Related Services Company, Inc. | System and method for an interoperability framework |
US7167893B1 (en) * | 2001-10-03 | 2007-01-23 | Bellsouth Intellectual Property Corp. | Methods and systems for processing a plurality of errors |
US8527970B1 (en) * | 2010-09-09 | 2013-09-03 | The Boeing Company | Methods and systems for mapping threads to processor cores |
US8745741B1 (en) * | 2012-08-31 | 2014-06-03 | Google Inc. | Detecting and handling vtable pointer corruption |
Family Cites Families (17)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5983004A (en) * | 1991-09-20 | 1999-11-09 | Shaw; Venson M. | Computer, memory, telephone, communications, and transportation system and methods |
DE4131380A1 (en) * | 1991-09-20 | 1993-03-25 | Siemens Ag | METHOD FOR ADAPTING AN OBJECT-ORIENTED APPLICATION |
US5497463A (en) * | 1992-09-25 | 1996-03-05 | Bull Hn Information Systems Inc. | Ally mechanism for interconnecting non-distributed computing environment (DCE) and DCE systems to operate in a network system |
JPH0827769B2 (en) * | 1992-10-30 | 1996-03-21 | インターナショナル・ビジネス・マシーンズ・コーポレイション | Communication interface generation system and method |
JPH09502547A (en) * | 1992-11-13 | 1997-03-11 | マイクロソフト コーポレイション | Method and system for marshalling interface pointers for remote procedure calls |
CA2107299C (en) * | 1993-09-29 | 1997-02-25 | Mehrad Yasrebi | High performance machine for switched communications in a heterogenous data processing network gateway |
US5596579A (en) * | 1993-10-01 | 1997-01-21 | International Business Machines Corporation | High performance machine for switched communications in a heterogeneous data processing network gateway |
CA2115464C (en) * | 1994-02-11 | 1998-12-15 | William G. O'farrell | Concurrent processing in object oriented parallel and near parallel systems |
US5835757A (en) * | 1994-03-30 | 1998-11-10 | Siemens Telecom Networks | Distributed database management system for servicing application requests in a telecommunications switching system |
US5764977A (en) * | 1994-03-30 | 1998-06-09 | Siemens Stromberg-Carlson | Distributed database architecture and distributed database management system for open network evolution |
US5793965A (en) * | 1995-03-22 | 1998-08-11 | Sun Microsystems, Inc. | Method and apparatus for determining the type of an object in a distributed object system |
US5689664A (en) * | 1995-04-14 | 1997-11-18 | Microsoft Corporation | Interface sharing between objects |
US5794030A (en) * | 1995-12-04 | 1998-08-11 | Objectivity, Inc. | System and method for maintenance and deferred propagation of schema changes to the affected objects in an object oriented database |
GB9600823D0 (en) * | 1996-01-16 | 1996-03-20 | British Telecomm | Distributed processing |
US5960200A (en) * | 1996-05-03 | 1999-09-28 | I-Cube | System to transition an enterprise to a distributed infrastructure |
WO1997049039A1 (en) * | 1996-06-21 | 1997-12-24 | Bell Communications Research, Inc. | Apparatus and methods for highly available directory services in the distributed computing environment |
US5790789A (en) * | 1996-08-02 | 1998-08-04 | Suarez; Larry | Method and architecture for the creation, control and deployment of services within a distributed computer environment |
-
1996
- 1996-09-27 GB GBGB9620196.7A patent/GB9620196D0/en active Pending
-
1997
- 1997-09-25 US US09/091,741 patent/US6256779B1/en not_active Expired - Lifetime
- 1997-09-25 EP EP97941128A patent/EP0928450B1/en not_active Expired - Lifetime
- 1997-09-25 DE DE69734352T patent/DE69734352T2/en not_active Expired - Lifetime
- 1997-09-25 WO PCT/GB1997/002606 patent/WO1998013758A1/en active IP Right Grant
- 1997-09-25 CA CA002266912A patent/CA2266912C/en not_active Expired - Fee Related
- 1997-09-25 AU AU43149/97A patent/AU4314997A/en not_active Abandoned
Non-Patent Citations (4)
Title |
---|
ALEXANDER B. SCHILL ET AL.: "DC++: distributed object-oriented system support on top of OSF DCE", DISTRIBUTED SYSTEMS ENGINEERING, vol. 1, no. 2, December 1993 (1993-12-01), UK, pages 112 - 125, XP000607911 * |
CHANG-HYUN JO ET AL.: "PARALLELIZING TRANSLATOR FOR AN OBJECT-ORIENTED PARALLEL PROGRAMMING LANGUAGE", PROCEEDINGS OF THE ANNUAL INTERNATIONAL PHOENIX CONFERENCE ON COMPUTERS AND COMMUNICATIONS, SCOTTSDALE, ARIZONA, US, 27 March 1991 (1991-03-27) - 30 March 1991 (1991-03-30), INSTITUTE OF ELECTRICAL AND ELECTRONICS ENGINEERS, pages 265 - 271, XP000299058 * |
ERIC JUL ET AL.: "Fine-Grained Mobility in the Emerald System", ACM TRANSACTIONS ON COMPUTER SYSTEMS, vol. 6, no. 1, February 1988 (1988-02-01), ISSN 0734-2071, US, pages 109 - 133, XP002023563 * |
H. SIVARAMAN ET AL.: "Parallelizing Sequential Programs to a Cluster of Workstations", PROCEEDINGS OF THE 1995 ICPP WORKSHOP ON CHALLENGES FOR PARALLEL PROCESSING, RALEIGH, NC, USA, 14 August 1995 (1995-08-14), ISBN 0-8493-2618-4, 1995, BOCA RATON, FL, USA, CRC PRESS, USA, pages 38 - 41, XP000566779 * |
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2002048886A2 (en) * | 2000-12-13 | 2002-06-20 | Telefonaktiebolaget Lm Ericsson (Publ) | Telecommunications platform with processor cluster and method of operation thereof |
WO2002048886A3 (en) * | 2000-12-13 | 2002-08-15 | Ericsson Telefon Ab L M | Telecommunications platform with processor cluster and method of operation thereof |
Also Published As
Publication number | Publication date |
---|---|
CA2266912C (en) | 2004-03-30 |
AU4314997A (en) | 1998-04-17 |
GB9620196D0 (en) | 1996-11-13 |
CA2266912A1 (en) | 1998-04-02 |
US6256779B1 (en) | 2001-07-03 |
EP0928450B1 (en) | 2005-10-12 |
DE69734352D1 (en) | 2005-11-17 |
DE69734352T2 (en) | 2006-07-06 |
EP0928450A1 (en) | 1999-07-14 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CA2242516C (en) | Distributed processing | |
Shapiro | Structure and encapsulation in distributed systems: The proxy principle | |
US20030093420A1 (en) | Method and system for retrieving sharable information using a hierarchically dependent directory structure | |
US20050055398A1 (en) | Protocol agnostic request response pattern | |
WO1998053398A1 (en) | Java virtual machine extension for instantiating objects | |
CA2345256A1 (en) | Text object compilation method and system | |
EP0875028B1 (en) | Distributed processing | |
US6738797B1 (en) | System and method for tracking records in a distributed computing system | |
US6256779B1 (en) | Distributed processing | |
AU747018B2 (en) | Distributed processing | |
CA2342423C (en) | Distributed processing | |
CA2437742C (en) | Distributed processing | |
US7266814B2 (en) | Namespace based function invocation | |
Tarau et al. | High-level networking with mobile code and first order AND-continuations | |
Olsson et al. | Remote procedure call | |
De Menezes | Resource management in open tuple space systems | |
Magnin et al. | Agents need to become welcome | |
Beattie | TkPerl-A port of the Tk toolkit to Perl5 | |
Ræder et al. | Quality-of-service directed targeting based on the ODP engineering model |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AK | Designated states |
Kind code of ref document: A1 Designated state(s): AL AM AT AU AZ BA BB BG BR BY CA CH CN CU CZ DE DK EE ES FI GB GE GH HU ID IL IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MD MG MK MN MW MX NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT UA UG US UZ VN YU ZW AM AZ BY KG KZ MD RU TJ TM |
|
AL | Designated countries for regional patents |
Kind code of ref document: A1 Designated state(s): GH KE LS MW SD SZ UG ZW AT BE CH DE DK ES FI FR GB GR IE IT LU MC |
|
DFPE | Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101) | ||
WWE | Wipo information: entry into national phase |
Ref document number: 09091741 Country of ref document: US |
|
121 | Ep: the epo has been informed by wipo that ep was designated in this application | ||
ENP | Entry into the national phase |
Ref document number: 2266912 Country of ref document: CA Ref country code: CA Ref document number: 2266912 Kind code of ref document: A Format of ref document f/p: F |
|
WWE | Wipo information: entry into national phase |
Ref document number: 1997941128 Country of ref document: EP |
|
NENP | Non-entry into the national phase |
Ref country code: JP Ref document number: 1998515397 Format of ref document f/p: F |
|
WWP | Wipo information: published in national office |
Ref document number: 1997941128 Country of ref document: EP |
|
REG | Reference to national code |
Ref country code: DE Ref legal event code: 8642 |
|
WWG | Wipo information: grant in national office |
Ref document number: 1997941128 Country of ref document: EP |