Distributed office automation system with specific task assignment among workstations5136708Abstract A distributed office automation system includes workstations and support stations which are interconnected via a network and which make use of the functionality of one another by subcontracting tasks. Various function modules are available in the system for numerous tasks and the system provides a distributed organization structure in which it is always clear what function module is required to perform a specifc task. Each of the stations is provided with a coordination unit which is continually aware of the state of the total system and which designates the required function module. Claims What is claimed is: Description FIELD OF INVENTION
______________________________________
name of station sending
sort of packet: "active"
loading figure over 1 min.
loading figure over 5 min.
loading figure over 15 min.
s.p. counter
______________________________________
A station is identified by a name or identifier. The "s.p. counter" field contains the current value of the "service" packet counter of the transmitting station. This value is used to check whether the "service" list of the receiving station is up-to-date with respect to the services offered by the transmitting station, as will be explained below. The "active" list contains information on every station in the system. It has an entry for every station, which contains at least: the name of the station; whether the station is active; the last time an "active" broadcast packet was received from the station; the latest loading figures received from the station; the most recently received value of the "service" packet counter of the station. Each time a new "active" broadcast packet arrives, the coordinator updates the entry in its list of the station concerned as soon as possible. If the "service" packet counter value is not equal to the one stored in the list, the coordinator asks the sending coordinator to retransmit the last sent update of the "service" list. A more detailed discussion of the communication between coordinators is given below. The coordinators maintain a constant watch on their "active" lists, to find out if all stations are still active. The time which may elapse between two consecutive broadcasts of a station is restricted to a maximum. If a station breaks down, then the broadcasts from its coordinator cease. The other coordinators note the absence of the broadcasts and wait for a predetermined time--which is, for instance, two times the maximum interval between two broadcasts--for--new broadcast. In the absence of the latter, they conclude that the station concerned is out of operation or at least inaccessible, and they change the entry of that station in their "active" lists accordingly. As a result, each coordinator knows which of the other stations are in operation and knows their loading. 3. The "service" lists. The local "service" list contains information on all services offered (i.e.. server processes waiting for a service request) in the coordinator's station. For every server there is a separate entry, which contains at least: the name of the server; the category of the server and, if appropriate, the priority number. (The category of the server is discussed below.) The system "service" list contains information on all services offered anywhere in the system. An entry contains at least: the name of the service; the number of stations offering this service; the names of the stations offering this service; the category of the service and, if appropriate, the priority sequence; the last time this entry was changed. (The category of the service is discussed below.) Every time a server process is activated or deactivated in the system, the coordinator of the station in which that process resides updates its local "service" list and broadcasts the updated list to the other coordinators, which then update their system "service" lists using the new information, as does the broadcasting coordinator itself. A broadcast packet for this purpose has the following form:
______________________________________
name of station sending
sort of packet: "service"
local "service" list of
station sending
s.p. counter value
______________________________________
The s.p. ("service" packet) counter value is used to make sure that no service packet is lost during broadcast, as the UDP Broadcast does not guarantee that every packet is actually received by all stations. It is chosen randomly when the station is booted and is incremented by 1 immediately after a "service" packet has been broadcast. As the s.p. counter value is transmitted with every "active" packet, every coordinator knows the counter value of the next "service" packet. Immediately after reception of a "service" packet, every coordinator increments the s.p. counter Value for the transmitting station in its "active" list by 1 in order to be read for receiving the next "service" packet. Coordinator Communication The communication between coordinators is shown in the flow sheets of FIGS. 3, 4 and 5. Actions of the coordinator of a station A (hereinafter referred to as "coordinator A") are shown at the left side of the vertical broken line and those of the coordinators of other stations B, C, etc. (hereinafter referred to as "coordinator B", "coordinator C", etc,) at the right side of that line. It is always assumed that stations B, C, etc. are running and are aware of each other's presence. Their reactions to actions of station A are identical, so only one sequence is shown at the right side. Therefore, if the actions of coordinator B are described, the same actions are performed by coordinators C, etc., but the latter have been omitted for reasons on clarity. FIG. 3 shows the event sequence following an "active" broadcast of station A. Station A may be running and be known to the other stations or it may have just been introduced into the system and still be unknown to the other stations. Last, it may have just rebooted after a breakdown and be known to the other coordinators, but still labeled "inactive" in their "active" lists. In all cases mentioned, coordinator A broadcasts an "active" packet 31 (step 30), which is received by coordinator B. The packet has an "s p. counter" field with the "service" packet counter value of the latest "service" packet broadcast by coordinator A. This value is called "I". Coordinator B checks step 32) if station A is in its "active" list 33, and, if so, if station A is labeled "active" (step 34). If station A is known as being active, coordinator B checks the s.p. counter value of the packet (I) against the value in its "active" list (N) (step 35). If I N, as it should be under normal conditions, coordinator B proceeds to step 36 and updates the fields "time latest "active"message" and "lf's" (loading figures) of the entry of station A in its "active" list, using the loading figures contained in the "active" packet and goes into a waiting state (37). If I<N, indicating that the received packet is an old one that has probably been held up somewhere in the network coordinator B discards the message. as is not relevant any more, (step 38) and goes into a waiting state (39). If I>N, indicating that "service" packet I-1 (or even more than one previous packet, when I-N>1) has not arrived, coordinator B requests coordinator A to transmit the last "service" packet and updates the entry of station A in its "active" list (step 40). Coordinator A transmits the specified packet (42) (step 41) and coordinator B updates its system "service" list with the data of the "service" packet, whereafter it writes the value I into the s.p. counter field of A's entry in its "active" list (step 43). Then it goes into a waiting state (44). The communication between the coordinators A and B described here is not by broadcast, but by an addressed transmission, which is more reliable and loads the communication process less. Also, the transmission of the "service" packet in step 41 does not change the s.p. counter value. In the case of station A having just been introduced into the system, its name is not in the "active" list of coordinator B. The letter now makes a new entry in its "active" list to accommodate station A (step 45), and fills in the s.p. counter value (step 46) and the "active", the "time latest "active"message" and the 1f's fields from the "active" packet received (step 36), after which it goes into a waiting state 37. If station A has just rebooted after a breakdown, its name is still known to coordinator B, but it has been labeled "inactive" in B "active" list. At the reception of the "active" packet of coordinator A, coordinator B goes through steps 32 and 34 and then updates its "active" list entry for station A by filling in s.p. counter value "I" (step 46) and the "active", the "time latest "active"message" and the 1f's fields according to the "active" packet received (step 36), after which it goes into a waiting state 37. FIG. 4 shows the event sequence following a "service" broadcast of station A. Although a station will, after start=up, always broadcast an "active" packet before it broadcasts "service" packets, it is always possible that the initial "active" packet has got held up or lost on the network and a "service" packet is the first to arrive. Therefore, there are three situations in which the "service" packet can arrive: 1) station A is running and known to the other stations, 2) station A has just been introduced into the system and is still unknown to the other stations, or 3) station A has just rebooted after a breakdown and is known to the other coordinators, but still labeled "inactive" in their "active" lists. In all casts it is assumed that the other stations are running and aware of each other's presence. Coordinator A broadcasts a "service" packet 51 (step 50), which is received by coordinator B. The "s.p. counter" value of the packet is called "I". Coordinator B checks (step 52) is station A is in its "active" (step 54). If station A is known as being active, coordinator B checks the s.p. counter value of the packet (I) against the value in its "active" list (N) (step 55). If I=N, as it should be under normal conditions, coordinator B proceeds to step 56 and updates its system "service" list using the data contained in the "service" packet. After this, coordinator B increments the s.p. counter value of A's entry in its "active" list by 1 and goes into a waiting state (57). If I>N, indicating that "service" packet I-1 (or even more than one previous packet, when I-N>1) has not arrived, coordinator B assumes that the "service" packet just received is the most recent anyway and uses the data contained in it to update its system "service" list. Then coordinator B writes the s.p. counter value of the packet, incremented by 1, into the s.p. counter field of A's entry in its "active" list to prevent "service" packet I-1 from erasing the more recent information of packet I, would it arrive later. If I<N, indicating that the received packet is an old one that has probably been held up somewhere in the network, coordinator B discards it, as is not relevant any more, (step 58) and goes into a waiting state (59). In the case of station A having just been introduced into the system, its name is not in the "active" list of coordinator B. The latter simply discards the packet, as it programmed to accept "service" packets from known stations only, after which it goes into a waiting state (59). If station A has just rebooted after a breakdown, its name is still known to coordinator B, but it has been labeled "inactive" in B's "active" list. At the reception of the "service" packet of coordinator A, coordinator B goes through steps 52 and 54 and then simply discards the packet as it programmed to accept "service" packets from active stations only, after which it goes into a waiting state (59). FIG. 5 shows the event sequence, in the case station A has just been introduced into the system or station A has just rebooted after a breakdown, following an "active" broadcast of one of the running stations in the system. The "active" packet of coordinator B is assumed to be the first one to arrive after station A gets active. Upon the reception of this "active" packet, station A initializes as a system station and subsequently handles all broadcasts in the way described with respect to FIG. 3 and FIG. 4. Coordinator B broadcasts an "active" packet (61) in step 60. Upon reception of this packet, coordinator A makes an entry for B in its "active" list, and fills it with the data contained in the packet (step 62). Then it transmits a request to coordinator B to transmit its system "service" list (step 63). Coordinator B does so (step 64) and coordinator A takes the list over as its own system "service" list (step 65), after which it goes into a waiting state (66). CLIENT-SERVER COMMUNICATION To make them suitable for use in the system described here, client and server program modules contain a set of library routines that can be activated by the following primitives: the "connect" primitive: this primitive is used by a client process to obtain a communication link with a certain server. It first addresses the coordinator of the client's station, which returns the addressing information of that particular server. After the server is located, the "connect" primitive establishes a "symbolic" link (i.e.. one that is addressed by name) between the client and the server processes; the "terminate" primitive: this primitive is used to remove the communication link between the client and server processes. the "register" primitive: this primitive is used by a server process to make itself known to the coordinator of its station. When a server process is activated, it reports to its coordinator, using a preprogramed name and category. The coordinator responds by writing the reporting server in its local "service" list and broadcasts the updated list to the other coordinators. As a result, every coordinator updates its system "service" list correspondingly. the "deregister" primitive: this primitive is used by a server process to communicate to its coordinator that it is no longer able to perform the task it is meant for. The coordinator then updates its local "service" list and broadcasts the latter to the other coordinators. As a result, every coordinator updates its system "service" list correspondingly. In addition, every client process has functionality to detect when a connection with a server process is broken off, e.g. by a malfunction of the station in which that server resides, and to call the "connect" primitive in order to obtain a communication link with a replacing server, if any. SERVER CATEGORY Because the system comprises several more or less identical stations, there will certainly be a number of server processes with multiple instances in the system, i.e.. there will be identical servers available. Such servers have the same preprogramed name and belong to one of two categories, i.e.. "equivalent" or "substitute". The category is always transmitted to the coordinator by the "register" primitive. An "equivalent" server is intended for a task not restricted to a specific station, e.g.. a text spelling check. Such a task can in principle be subcontracted to any station in the system and in case of failure of the station in which a particular server is performing such a task, the task may be performed once again by an identical server in another station. A "substitute"server is intended for a task which must be performed by one and the same server process in the entire system, e.g.. the updating of the list with operators access passwords. If there is more than one server available for that task, they are counted as a reserve. In the event that the station which contains the server actually performing the task breaks down, one of the reserves should take over. To this end, these servers are given a priority number which defines a sequence for performing the task, e.g.. by preprogramming or by a suitable algorithm for allocating a priority number upon registering. The substitute server processes are always written in the "service" lists with their priority number. In the case of substitute servers controlling a data file, such as the previously mentioned password collection, there is an extra precaution taken. In the event that the station containing the server actually performing the task breaks down, the data concerned should be kept accessible for the server process taking over. Therefore, all the identical server processes of this kind have their own data files in the memories of their stations, containing the same data, with the server actually performing the task maintaining all said files, either by broadcasting changes made to its own data file or by directly connecting to its substitutes and transmitting those changes. When a client process requests a connection to a server, its coordinator scans its system "service" list to find out in which station or stations the concerned server is available and of what category it is. Next, the coordinator looks in the "active" list, if the station or stations offering the service are active and removes the stations indicated as inactive from the selection. If there is only one server of the name specified in the request, the coordinator returns the addressing information the client process needs to communicate with that server. If the specified server is of the "equivalent" category, the coordinator selects the server in the least loaded station. To this end the coordinator calculates a loading indication from the loading figures in its "active" list, e.g., using the formula loading indication=1.times.1f(15)+3.times.1f(5)+15.times.1f(1) (wherein 1f (i)=loading figure over i minutes). The aim of bringing in the longer term loading figures is to avoid oscillation in the loading of a particular station. The coordinator compares the calculated loading indications of the active stations containing the specified server and selects the server in the station having the lowest loading. As the time intervals between two broadcasts of a station are rather long (e.g.. every 10 seconds, in order not to increase the loading of the station too much), it may be preferable for the coordinator to ask the stations containing the server to send their actual loading figures first and make its selection on the basis of the new loading figures. If the specified server is of the "substitute" category, the coordinator selects the server having the highest priority according to the priority sequence in the system "service" list. An example of the operation of the coordinators will now be explained with reference to FIGS. 2a-2f. FIG. 2a illustrates stations A, B and C, each provided with a coordinator 20A, 20B and 20C. The coordinators maintain mutual- contact via the connection 21. This connection is a "logic" connection via network 9 (FIG. 1). Each station is further provided with an "active" list (not shown), a local "service" list (not shown) and a system "service" list 24A, 24B, 24C. FIG. 2b illustrates a server process 22B which reports itself to its coordinator 20B and then is included local "service" list of that coordinator by name and category. In this example this server has the name TASK, belongs to the "substitute" category and has the priority number 1. The coordinator 20B writes in the server 22B in its system "service" list 24B and transmits the data immediately to the other coordinators 20A and 20C which also write in the server 22B in their system "service" 24C. The server now goes the standby position until there is work for it. FIG. 2c illustrates a second server process 22C which becomes written in. This server is intended for the same task as server 22B and therefore has the same name TASK, and is also of the "substitute" category and has the priority number 2. FIG. 2d illustrates the procedure when a client process 23A wishes to subcontract a task to a module having the name TASK. Process 23A asks its coordinator 20A selects, from its list 24A, server 22B having the priority number 1. A connection 24 is then established between client process 23A and server process 22B. Connection 24 is again a "logic" connection via the network 9 (FIG. 1). Server 22B then starts to perform the task. In the situation for example where the station containing server 22B breaks down as a result of a malfunction, coordinator 20B also breaks down. Consequently, reports on the degree of loading that coordinator 20B is required regularly to broadcast are absent and coordinators 20A and 20C conclude from this that station B is out of operation and change the "active" field in their "active" list into "inactive". This is represented in FIG. 2e. The client process 23A notes the malfunction because it no longer receives any reply from server 22B. Process 23A again asks for a connection to a TASK server and obtains connection 25 to the server having the priority number 2, 22C. This is represented in FIG. 2f. Since the task had not yet been completed, it must be completely or partially redone by If the task commanded by client process 23A has to be performed by a module of the "equivalent" category, the course of events is largely identical, but the criterion for selection of server 22 is not based on the loading data of the stations which the coordinators transmit to one another via the connection 21. Server 22 in the least loaded station is then designated. It will be apparent to those skilled in the art that numerous other embodiments are possible within the scope of the claims, e.g. systems in which the workstations are organized in groups each coordinated by a support station. The workstations may be permanently connected to the support station of their group and the support stations be interconnected via the network.
|
Same subclass Same class Consider this |
||||||||||