DE3855152T2

DE3855152T2 - Verteiltes Computersystem

Info

Publication number: DE3855152T2
Application number: DE3855152T
Authority: DE
Inventors: Daniel C Swinehart; Douglas B Terry
Original assignee: Xerox Corp
Current assignee: Xerox Corp
Priority date: 1987-11-06
Filing date: 1988-11-02
Publication date: 1996-10-02
Anticipated expiration: 2008-11-03
Also published as: EP0315426A3; US4914586A; EP0315426A2; JP2795856B2; JPH01156840A; DE3855152D1; EP0315426B1

Description

Diese Erfindung betrifft verteilte Digitalcomputersysteme (einschließlich Systemen mit heterogenen Betriebsumgebungen) und im besonderen Verfahren und Einrichtungen, die (1) Benutzern solcher Systeme ermöglichen, datenintensive Dateien, z.B. digitale Sprach- und Musikdateien, "eingescannte" Bilddateien sowie Trickbilddeteien oder Deteien mit bewegtem Video, zu erzeugen, zu manipulieren, daran teilzuhaben und praktisch unbeschränkt zu benutzen, während (2) die Notwendigkeit vermieden wird, mehrfache Copien von solchen Dateien zu erstellen, zu speichern und zu handhaben, und (3) den solchen Dateien zugeteilten Speicherraum wiederzuverwenden, wenn sie nicht mehr gebraucht werden.
Herkömmliche verteilte Computersysteme haben begrenzte Anwender für alphanumerische und einfache graphische Kommunikation (hierin kollektiv als "Textkommunikation" bezeichnet), wenngleich Sprache, Video und sogar Musikmedien für die zwischenmenschliche Kommunikation oft leistungsfähiger und wirkungsvoller sind. Andere haben die Notwendigkeit erkannt, solche Systeme ausreichend zu erweitern, um die Nicht- Text-Kommunikation als eine Alternative oder Ergänzung zur Textkommunikation zu unterstützen. Erhebliche Bemühungen und Kosten sind z.B. sowohl der Entwicklung von Sprachnachrichtensystemen als auch der Entwicklung von Multimediasystemen, um Text mit Sprache zu kommentieren, gewidmet worden. Sprache ist das Nicht-Text-Kommunikationsmedium, das zur Verwendung in verteilten Computersystemen - weitesten untersucht worden ist, so daß diese Erfindung in diese Kontext beschrieben werden wird, um ein repräsentatives Beispiel zur Verfügung zu stellen. Dessen ungeachtet versteht sich, daß die breiteren Aspekte dieser Erfindung auch auf andere Arten von datenintensiven Nicht-Text-Kommunikationen in verteilten Computersystemen anwendbar sind.
Verschiedene interessierende und potentiell wichtige Vorteile fließen vom Umgehen mit Sprach- und anderen Nicht-Textmedien als Daten in eine verteilte Rechenumgebung. Siehe Nicholson, "Integrating Voice in the Office World", Byte, Band 8, Nr. 12, Dez. 1983, Seiten 177-184. Sie ermöglicht, Nicht-Textmedien in elektronische Briefnachrichten und in Anmerkungen, die sich auf gewöhnliche Textdateien beziehen, sowie in Aufforderungen und andere interaktive Nachrichten, die die Benutzerschnittstelle der Rechenumgebung zur Verfügung stellt, leicht einzubeziehen. Kurz gesagt, eine derartige Handhabung erlaubt den Benutzern, diese Nicht-Text-Datendateien in ziemlich derselben Weise wie sie herkömmliche Textdateien handhaben, zu erzeugen zu manipulieren und daran teilzuhaben, und ermöglicht den Programmierern, Funktionen, die solche Nicht-Text-Datendateien einschließen, allgemein in derselben Weise zu implementieren, wie sie Funktionen, die Textdateien umfassen, implementieren.
Sprach- und andere Nicht-Text-Datendateien unterscheiden sich jedoch wesentlich von gewöhnlichen Text-Datendateien. Zum Beispiel können klassische Workstations keine Sprach-Datendateien in Analogform aufzeichnen oder abspielen, so daß für diesen Zweck besondere Einrichtungen benötigt werden. Noch wichtiger, Sprach-Datendateien sind typischer viel größer als Textdateien, die dieselben Wörter enthalten. In der Tat verbraucht die Aufzeichnung unverdichteter Sprache mit normaler Telefonqualität etwa 64 kBit Speicher pro Sekunde, was mehrere Größenordnungen größer ist als die Speicherkapazität, die für eine gleichwertige Passage von geschriebenem Text benötigt wird. Noch ein anderer zu berücksichtigender Faktor ist, daß es für das Übertragen von Sprache strenge Echtzeitforderungen gibt, weil unbeabeichtigte Pausen oder das Zerhacken von Wörtern bei der Wiedergabe von Sprache ein Wahrnehmungsproblem erzeugt, das das Bestreben zu kommunizieren stört oder gar zunichte macht.
Benutzer von verteilten Computersystemen befinden sich gelegentlich in heterogenen Rechenumgebungen mit diversen Netzwerkdieneten, die unter Verwendung von verschiedenen Übertragungsprotokollen durchgeführt werden. Außerdem kann der Verkehr zwischen solchen Rechenumgebungen über ein Vielfalt von öffentlichen oder privaten Netzbetreibern geleitet werden, was vorstellbar verschiedene Leitungsschaltschemas umfassen kann. Gateways sind entwickelt worden, um Textnachrichtenverkehr zwischen heterogenen Umgebungen zu vermitteln, so daß der Wert und der Nutzen von Nicht-Text-Übertragungen in solchen Systemen zum wesentlichen Teil von der Einfachheit abhängen kann, mit der Nicht-Text- Kommunikationen über solche Gateways übermittelt werden können.
Andere haben einige der Probleme angesprochen, die zu lösen sind, um Sprach- und ähnliche Nicht-Text-Kommunikationen in verteilten Rechenumgebungen durchzuführen. Der 'Sydis Information Manager' benutzt besondere Workstations (genannt "VoiceStations") zum Aufnehmen, Editieren und Wiedergeben von Sprache. Siehe Nicholson, "Integrating Voice in the Office World", Byte, Band 8, Nr. 12, Dez. 1983, Seiten 177- 184. Außerdem ist ein System zum Integrieren von Sprache und Daten für einfache Workstation-Anwendungen beschrieben worden, nämlich Ruiz, "Voice and Telephone Applications for the Office Workstation", Proceedings 1st International Conference on Computer Workststions, San Jose, Ca., November 1985, Seiten 158-163. Sprachspeichersysteme mit Einrichtungen zum Aufzeichnen, Editieren und Abspielen von Sprache sind vorgeschlagen worden, nämlich Maxemchuk, "An Experimental Speech Storage and Editing Facility", Bell System Technical Journal, Band 58, Nr. 9, Okt. 1980, Seiten 1383-1396.
Noch mehr zu dem Punkt, es gibt Systeme, die Benutzern ermöglichen, Dokumente zu benutzen, die eingebette Verweise auf Nicht-Text-Mediaobjekte enthalten, die in einem gemeinsamen Dateidienst liegen, und den "Abfall" von diesen Objekten zu sammeln, um den diesen zugeteilten Speicherraum wiederzuverwenden, wenn es keine Dokomente oder Dokumentenableger mehr gebt, die Verweise auf sie enthalten. Siehe Thomas et al., "Diamond: A Multimedia Message System Built on a Distributed Architecture", Computer, Band 18, Nr. 12 Dez. 1985, Seiten 65-78. Systeme wie das Diamond-System, die textlich eingebettete Verweise benutzen, um auf Sprach-, Video- und diverse andere Arten von Nicht- Textdaten zu verweisen, werden gelegentlich als "Hypermedia-Systeme" bezeichnet. Siehe Yankelovich et al., "Reading and Writing the Electronic Book", Computer, Band 18, Nr. 10, Okt. 1985 Seiten 15-60. Anders als die meisten anderen vorgeschlagenen Systeme umgehen die von dem Diamond-System benutzten eingebetteten Verweise die Notwendigkeit, Kopien der Nicht-Text-Datendateien (d.h. Sprachdateien) in jede Dokumentendatei, zu der sie gehören, einzuschließen. Das einfache auf Verweiszählung basierende Abfallsammelscheme des Diamond-Systems ist jedoch unverträglich mit dem Erlauben, Verweise auf intern gespeicherte Objekte in Dokumente oder Dokumentenableger, die außerhalb des Systeme gespeichert werden, einzuschließen.
Der interessierende Stand der Technik, der die Abfallsammlung von gewohnlichen Datendateien betrifft, ist ebenfalls aufgedeckt worden. Der 'Cambridge File Server' verlangt von den Klienten, eine bestimmte Aktion zu ergreifen, um zu verhindern, daß Dateien als Abfall gesemmelt werden, weil er Dateien automatisch löscht, die von klientenaktualisierten und server-unterhaltenen Indizes nicht zugänglich sind. Siehe Mitchell et. al., "A Comparison of Two Network-Based File Servers", Communications of the ACM, Band 25, Nr. 4, April 1982, Seiten 233-245. Etwas weniger relevant, aber doch als ein Beispiel von Interesse, wie ein hochzuverlässiger Verweis-Server zu bauen ist, ist das in Liskov et al. beschriebene System "Highly-Available Distributed Services and Fault Tolerant Distributed Garbage Collection", Proceedings of Symposium on Principles of Distributed Computing, Alberta, Kanada, August 1986, Seiten 29-39. Das Abfallsammelscheme, das sie sich vorstellen, verlangt von allen Stellen, die Verweise auf entfernt gespeicherte gemeinsame Objekte speichern, lokal einen Abfallsammler ablaufen zu lassen, der den Zweck hat, Information über verteilte Verweisungen an einen gemeinsamen Verweisungs-Server zu senden.
Ebenfalls von Interesse ist Swinehart et al., "Adding Voice to an Office Computer Network", Proceedings of the IEEE GlobCom, Nov. 1983, Seiten 392-398. Swinehart et al. beschreiben einen besonders konstruierten Prozessor, der an ein Telefongerät angeschlossen wird und digitalisierte Sprache, Signalisierung und Überwachungsinformation in einzelnen Paketen über ein Ethernet LAN sendet.
Ebenfalls von Interesse ist Terry et al., "Managing Stored Voice in the Etherphone System", ACN Transactions on Computer Systeme 6(1): 3-27, Februar 1988.
Wenigstens zwei Probleme sind noch zu lösen. Angesichts der sehr großen Größe der meisten Nicht-Text-Datendateien (z.B. Sprach-Datendateien) ist es wichtig, daß ein Verfahren entwickelt wird, um diese Dateien mit Hilfe von einfachen Datenbänken zu editieren, ohne daß die Dateien bewegt, kopiert oder entschlüsselt (wenn in verschlüsselter Form gespeichert) werden müssen, und um die Ergebisse der Editiervorgänge zu beschreiben. Ferner wird ein Verfahren zur Verwendung einfacher Datenbänke benötigt, um einen Abfallsammler zu unterstützen, der automatisch den Speicherraum wiederverwendet, der überholten Nicht-Text- Datendateien zugewiesen ist.
Die Erfindung ist wie in Anspruch 1 beansprucht.
Erfindungsgemäß wird eine interessierende Datenbank in einem verteilten Rechensystem unterhalten, um die einzelnen Interessen von Benutzern an zentral gespeicherten Nicht-Text-Mediendateien, z.B. digitale Sprach- eingescannte Bild- und Video-Dateien, zu registrieren, wobei einmalig benamte, stücklistenartige dauernde Datenstrukturen verwendet werden, um den Beutzern einen kontrollierten Zugriff auf die darunterliegenden Nicht-Text-Mediendateien durch eingebettete Namensverweise auf solche Stücklisten in gewöhnlichen Nachrichten- oder Textdateien zu geben, also wird auch eine Datenbank von Stücklisten unterhalten. Ein Abfallsammler zählt periodisch die Interessen-Datenbank auf, um Interesseneinträge zu löschen, die ungültig gemecht worden sind. Alte Stücklisten werden aus der Verweisdatenbank gelöscht, wenn es keine aufgezeichneten Interessen mehr gibt, die auf sie verweisen, und Nicht-Text-Nediendateien werden gelöscht, um den ihnen zugeteilten Speicherraum wiederzuverwenden, wenn es keine Stücklisten mehr gibt, die auf sie verweisen.
Weitere Merkmale und Vorteile dieser Erfindung werden ersichtlich, wenn die folgende ausführliche Beschreibung in Verbindung mit den anliegenden Zeichnungen gelesen wird.
Inhalt der Zeichnungen:
Fig. ist eine schematische Zeichnung, die zwei Lokale Netzwerke zeigt, die auf Befehl durch Gateways und einen Kommunikationskanal verbunden sind, wobei die Netzwerke nach Naßgabe dieser Erfindung konfiguriert sind, um zusätzlich zu gewöhnlichen Textübertragungen Sprachübertragungen zu unterstützen.
Fig. 2 ist ein Workstation-Schirmbild, das eine geeignete Benutzerschnittstelle zum Aufzeichnen, Editieren und Wiedergeben von Sprachdateien veranschaulicht.
Fig. 3 ist eine geschichtete Darstellung eines Sprachmanagers für ein Lokales Netzwerk.
Fig. 4 ist eine Darstellung, die die Korrelation der Sprachdateien mit den Datenstrukturen zeigt, die benutzt werden, um auf sie zu verweisen.
Fig. 5 ist ein vereinfachtes Funktionsflußdiagramm eines Interessen- Abfallsammlers.
Fig. 6 ist ein vereinfachtes Funktionsflußdiagramm eines Sprachstrang- Abfallsammlers.
Fig. 7 ist ein vereinfachtet Funktionsflußdiagramm eines Sprachdetei- Abfallsammlers.
Fig. 8 ist ein vereinfachtes teilweises Funktionsflußdiagramm für einen integrierten Sprachstrang/Sprachdatei-Abfallsammler.
Fig. 9 ist ein vereinfachtes teilweises Funktionsflußdiagramm für einen integrierten Interessen/Sprachstrang-Abfallsammler.
Fig. 1 zeigt ein verteiltes Computersystem 21 (nur im relevanten Teil dargestellt), das ein Lokales Netz (LAN) 22 mit einem Gateway 23 umfaßt, das es mit einem anderen LAN (nicht gezeigt) direkt oder möglicherweise über eine geschaltete Kommunikationseinrichtung verbindet. In Einklang mit der üblichen Konfiguration von CSMA/CD (d.h. Ethernet) Netzen besitzt das LAN 22 eine lineare Topologie zum Verbinden einer Mehrzahl von Workstations 24a und 24b, aber es wird ersichtlich sein, daß es oder jedes andere LAN, mit dem es verbunden ist, eine andere Topologie, z.B. eine ringartige Topologie, haben kann. Noch weitere Beispiele der heterogenen Umgebung, die vorhanden sein kann, die diversen Eigenschaften kommerziell erhältlicher Workstations und LANs vorausgesetzt, werden ersichtlich sein, so ist zu verstehen, daß das Gateway 23 Funktionen der Reformatierung und der Zeitneusteuerung ausführt, die benötigt werden, um Daten von einem LAN, das nach Maßgabe eines Übertragungsprotokolls arbeitet, an ein anderes LAN, das nach Maßgabe eines anderen Übertragungsprotokolls arbeitet, zu übertragen. Weitere Gateways können, wenn gewünscht, bereitgestellt werden, um das System 21 zu erweitern, um noch mehr LANs (nicht gezeigt) zu umfassen.
Um Benutzern zu ermöglichen, über das LAN 22 zusätzlich zu oder anstelle von üblichen Textnachrichten und Datendateien, die sie über ihre Workstations 24a und 24b austauschen, Sprachnachrichten zu senden und zu empfangen, sind mikroprozessorgestützte Telefongeräte 31a und 31b vorhanden, die sich in der Nähe der Workstations 24a bzw. 24b befinden, aber damit physikalisch nicht verbunden sind. Diese Telefongeräte setzen Sprache in das digitale Datenformat um, das benötigt wird, um dem Übertragungsprotokoll des LAN zu genügen, mit dem sie verbunden sind. Die Telefongeräte 31a und 31b z.B. digitalisieren, paketieren und verschlüsseln Sprache in Telefonqualität zur direkten Übertragung über das Ethernet-artige LAN 22. Hinsichtlich einer ausführlicheren Beschreibung, wie dies durchgeführt wird, siehe Swinehart et al., "Adding Voice to an Office Computer Network", Proceedings IEEE Globecom '83, Nov. 1983, und Swinehart et al., "An Experimental Environment for Voice System Development", IEEE Office Knowledge Engineering Newsletter, Feb. 1987. Wie vorangehend zum Ausdruck gebracht, sind die Telefongeräte 31a und 31b nicht direkt mit den Workstations 21a und 21b verbunden, da ähnliche Telefongeräte mit verschiedenen Workstations benutzt werden können, wie sie z.B. in einer heterogenen Umgebung vorhanden sein können.
Erfindungsgemäß enthält das System 21 einen Sprachmanager 34, der mit dem LAN 22 verbunden ist, um eine Speicherung für Sprache, Telefongespräche, Musik und andere mit annehmbarer Tonqualität aufgezeichnete Klänge bereitzustellen. Andere spezialisierte Quellen von, oder Senken für, Schall, z.B. ein Text/Sprache-Umsetzer (nicht gezeigt), der Textfolgen empfängt und die entsprechende Sprach-Datendatei zur Wiedergabe über ein oder mehr Telefongeräte 31a und 31b zurückgibt, können, wenn gewünscht, in dem Sprachmanager 34 enthalten sein.
Ein Sprach-Steuerserver 35 liefert Steuerfunktionen ähnlich denen eines herkömmlichen Geschäfts-Telefonsystems und dirigiert die Interaktionen zwischen den anderen Komponenten des Systems 21, während sie auf Sprache arbeiten. In Einklang mit seinen gewöhnlichen Telefonsystemfunktionen erlaubt der Sprach-Steuerserver 35, spracheführende Dialoge sowohl zwischen zwei oder mehr Benutzern als auch zwischen jedem Benutzer und einem Sprach-Dateiserver 36 über die Benutzertelefone 31a und 31b, die LANs 22 und, wenn angebracht, das Gateway 23 schnell herzustellen. Wenn ein solcher Dialog hergestellt ist, verteilt der Steuerserver 35 außerdem einen Kommunikationsweg- Identifizierer, DialogID, an alle Teilnehmer in dem Dialog, einschließlich der Telefongeräte und der Workstations der Benutzer, die darin verwickelt sind, als auch an den Sprach-Dateiserver 36, wenn er aktiviert ist, um den Dialog aufzuzeichnen. Wie man sehen wird, wird diese DialogID benutzt, um den Dialog in Anforderungen und Berichten zu identifizieren, die nach dem Ende des Dialogs vom Sprach- Steuerserver 35 oder den Teilnehmern ausgegeben werden können.
Die ganze für die Sprachübertragungen benötigte Steuerung wird über einen entfernten Prozeduraufruf (RPC), Protokoll, vollbracht, das vorzugsweise ein gesichertes Protokoll ist. Siehe z.B. Birrell et al., "Implementing Remote Procedure Calls", ACM Transactions on Computer Systems, Band 2, Nr. 1, Feb. 1984, Seiten 39-69, und Birell et al., "Secure Communications Using Remote Procedure Calls", ACM Transactions on Computer Systems, Band 3, Nr. 1, Feb. 1985, Seiten 1-14. Mehrfache Implementierungen des RPC-Protokolls erlauben die Integration der Workstations 24a und 24b für Sprachoperationen, auch wenn sie Programme ablaufen lassen und Sprachanwendungen ausfghren, die unter Verwendung verschiedener Programmierungsumgebungen programmiert sind. Wie man sehen wird, halten die vom Sprach-Steuerserver 35 als Reaktion auf die RPCs, die er im Verlauf eines Dialogs empfängt, ausgegebenen Berichte die Teilnehmer über die relevanten Systemektivitäten, die den Dialog unterstützen, informiert.
Die aktiven Teilnehmer an einem Dialog tauschen Sprache mit Hilfe eines geeigneten Sprachübertragungsprotokolls aus. Man vergleiche wieder den vorerwähnten Artikel von Swinehart "Adding Voice to an Office Cauputer Network". Während jedes Dialogs wird die gesamte gesendete Sprache codiert, vorzugsweise mit einer gesicherten Verschlüsselung, z.B. die DES electronic-codebook (ECB) Verschlüsselung, die auf einem zufällig erzeugten Codierungsschlüssel basiert, der vom Sprach-Steuerserver 35 ausgegeben wird. Siehe z.B. National Bureau of Standards, "Data Encryption Standard", Federal Information Processing Standard (FIPs), U.S. Department of Commerce, Veröffentlichung Nr. 46, Januar 1977. Dieser Schlüssel wird an die Dialogteilnehmer als Reaktion auf die von ihnen ausgegebenen RPCs verteilt) um dadurch ihren Telefongeräten 31a und 31b zu ermöglichen, den Dialog zu entschlüsseln.
Entsprechend einem oder mehr wichtigen Merkmalen dieser Erfindung versehen die Workstations 24a und 24b die Benutzer mit einer erweiterten Kontrolle über die Sprachmöglichkeiten des Systems 21. Fig. 2 zeigt das Schirmbild 41 einer typischen Workstation, z.B. der Workstation 24a, wie es erscheint, wenn der Benutzer zwei Fenster 42 und 43 geöffnet hat, eines zum Betrachten von Text kommentiert mit Verweisen auf eine Sprachpassage wie bei 42, und ein anderes zu Betrachten einer graphischen Darstellung einer gegebenen Sprachpassage wie bei 43. Diese Sprachverweise werden typischerweise durch ballonartige Symbole, die in den Text des kommentierten Dokuments, wie bei 44, eingebettet sind, angezeigt, so daß ein beliebiges ausgewähltes Symbol "geöffnet" werden kann, um seine graphische Darstellung, wie bei 43, zu betrachten, während es wiedergegeben und/oder editiert wird. Die graphische Darstellung der Sprache benutzt geeigneterweise eine lineare Kette von abwechselnden hellen und dunklen Balkan, um proportional lange Intervalle von Sprache und Stille darzustellen. Die Stille wird über eine Schwellenoperation ermittelt, wenn der Energiepegel der Sprache unter einen vorbestimmten Schwellenpegel abfällt, also wird man verstehen, daß ein solcher Begriff hier in seinem relativen Sinn gebraucht wird.
Als Einleitung zu einer Beschreibung der Sprach- und anderer Ton-Editierfunktionen, die die Benutzer durch die Benutzung ihrer Workstations 24a und 24b durchführen können, wird es hilfreich sein, die elementaren Funktionen RECORD, PLAY und STOP, die die Benutzer aufrufen können, kurz zu durchzugehen. Wenn ein Benutzer eine RECORD-Anweisung ausgibt, gibt der Sprach-Steuerserver 35 eine DialogID aus, die einen Übertragungsweg zum Verbinden des Benutzertelefongerätes mit dem Sprach-Dateiserver 36 identifiziert. Der Sprachmanager 34 reagiert auf die DialogID, indem er Speicherplatz auf dem Sprach-Dateiserver 36 zum Aufzeichnen einer neuen Sprachdatei zuweist und indem er einer ner solchen Sprachdatei einen einmaligen Namen, SprachStrangID erteilt. Danach wird die Aufzeichnung fortgesetzt, bis der Benutzer eine STOP- Anweisung ausgibt. Während die Aufzeichnung stattfindet, akkumuliert außerdem der Sprachmanager eine Zählung, um die Länge des Sprachstranges, VR, in geeigneten Zeiteinheiten, z.B. 1/8000 Sek. pro Einheit, festzustellen. Als Reaktion auf die STOP-Anweisung werden alle Aufnahme oder Wiedergabeoperationen, die dann im Gange sind oder für die durch die gegebene DialogID identifizierte Sitzung eingeplant sind, sofort angehalten. Die PLAY-Anweisung ist ähnlich der RECORD-Anweisung außer, daß sie durch einen Benutzer eingeleitet wird, der eine SprachStrangID und ein spezifiziertes Intervall ausgibt, das entweder den ganzen Sprachstrang oder ein spezifiziertes Intervall davon bei einer geeigneten Auflösung (in diesem Fall 0.1 ms) definiert. Der Sprach-Steuerserver 35 reagiert auf die PLAY-Anweisung, indem er eine DialogID ausgibt, um einen Übertragungsweg vom Sprach- Dateiserver 36 zum Benutzertelefongerät herzustellen, und der Sprachmanager 34 veranlaßt den Sprach-Dateiserver 36, das benutzergewählte Intervall der ausgewählten VF, wie durch die benutzerspezifizierten VRs (ID, Intervall) bestimmt, zu senden.
Typischerweise werden die Funktionen RECORD und PLAY asynchron mit entfernten Prozeduraufrufen durchgeführt, die zurückkehren, nechdem sie durch den Sprach-Dateiserver 36 eingeplant worden sind. Geplante Operationen werden im allgemeinen der Reihe nach ausgeführt, um dedurch dem Sprachmanager 34 zu ermöglichen, eine Geradeausprozedur zum Erzeugen von Berichten zu benutzen, um die Benutzer über den Statue ihrer Anforderungen auf dem gleichen Stand zu halten. Der Sprachmanager 34 gibt z.B. geeigneterweise eine RequestID zurück, wenn jede geplant. Operation begonnen und vollendet ist, um ihm dadurch zu ermöglichen, Aufrufe an jeden an einer solchen Operation beteiligten Benutzer abzugeben, wobei die Aufrufe typischerweise wie folgt aussehen:
REPORT[RequestID, {begonnen/beendet/ausgespült}].
Sprachstränge, VRs, die aufgezeichnete Sprachdateien, VFs, oder Teil. und Kombinationen davon identifizieren, sind unveränderbar, können aber von den Benutzern benutzt werden, um durch Anwenden der normalan Editierfunktionen ihrer Worksatations 24a und 24b neue unveränbare VRs zu erzeugen. Um das Editieren zu unterstützen, kann eine Operation DESCRIBE (VoiceRopeID) aufgerufen werden, um den Sprachmanager 34 zu veranlassen, an die Workstation des Anforderers eine Liste von Zeitintervallen zurückzugeben, die die nicht-stillen Sprachstöße (wie hierin verwendet ist "Sprachstoß" eine Folge von Sprachproben begrenzt durch ein vorbestimmtes Mindestintervall von Stille) des spezifizierten VR bezeichnen. Diese Sprachstoßliste wird wiederum benutzt, um die graphische Darstellung der Sprachstöße und der dazwischenliegenden Intervalle von Stille des ausgewählten VR zu erzeugen, wie in dem Fenster 43 von Fig. 2 gezeigt. Vorzugsweise wird eine Suchtabelle der mit allen auf dem Sprach-Dateiserver 36 aufgezeichneten Sprachdateien, VFs, verbundenen Sprachstöße unterhalten, um das beim Zusammenstellen der Sprachstoßliste für einen gegebenen Sprachstrang enthaltene Overhead zu verringern.
Die herkömmlichen Texteditierfunktionen, die direkt auf das Sprachstrang-Editieren angewandt werden können, sind:
CONCATENTATE [SprachStrangID&sub1;, SprachStrangID&sub2;,...] - bringt eine neue Sprach-ID zurück, um einen neuen VR zu erzeugen, der die Verkettung von bestehenden VRs ist;
SUBSTRING [SprachStrangID&sub1;, Intervall] - bringt eine neue Sprach-StrangID zurück, um einen neuen VR zu erzeugen, der aus einem spezifizierten Abschnitt eines vorhandenen VR besteht;
REPLACE [SprachStrangID&sub1;, Intervall, SprachStrangID&sub2;,]bringt eine neue SprachStrangID zurück, um einen neuen Sprachstrang zu erzeugen, bei dem die bestehende SprachStrangID&sub2; für ein spezifiziertes Intervall der bestehenden SprachStrangID&sub1; eingesetzt wird, wodurch eine Verbindung der Funktionen CONCATENATE und SUBSTRING durchgeführt wird.
LENGTH [SprachStrangID) - bringt eine Länge zurück, um die Länge eines bestehenden VR in geeigneten Zeiteinheiten, z.B. ms zu bestimmen.
Diese Funktionen stehen typischerweise dem Sprachmanager 34 über RPC- Aufrufe zur Verfügung.
Den VRs können Zugriffssteuerungen überlagert werden, um den Wiedergabezugriff auf ihre darunterliegen VFs zu steuern und das Editieren der VRs zu begrenzen. Diese Zugriffssteuerlisten können Namen von Einzelpersonen oder Gruppen enthalten. Siehe Birrell et al., Grapevine: "An Exercise in Distributed Computing", Communications of the ACM, Band 25, Nr. 4, April 1982, Seiten 260-274. Solche Zugriffskontrollen können z.B. vom Erzeuger eines gegebenen VR jederzeit eingerichtet und geändert werden durch Aufrufen: PERMIT [SprachStrangID, Spieler, Editierer], um den Zugriff auf den spezifizierten VR auf die benannten Spieler und die benannten Editierer zu beschränken. Eine geeignete Voreinstellung für den Zugriffssteuermechanismus würde entweder den unbeschränkten Zugriff auf den VR ermöglichen oder den Zugriff auf seinen Erzeuger beschränken.
Wie man einsehen wird, haben VRs den wichtigen Vorteil, daß sie von vielen Benutzern geteilt und in vielfache normale Textdokumente einbezogen werden können, um berechtigten Benutzern Zugriff auf die darunterliegenden VFs zu gewähren, ohne daß diese datenintensiven Nicht- Text-VFs kopiert, bewegt oder an mehreren Stellen gespeichert werden müssen. Gemäß einem wichtigen Merkmal dieser Erfindung steht es außerdem den Benutzern frei, Dokumente, die VRs enthalten, je nach ihren einzelnen Bedürfnissen und Wünschen On-line oder Off-line zu speichern.
Um dem Benutzer diese Freiheit zu gewähren, während sichergestellt wird, daß Platz auf dem Dateiserver 36, der durch veraltete VFs belegt wird, rechtzeitig zurückgewonnen wird, gibt es einen auf Interessen basierenden Abfallsammler, der veraltete VFs identifiziert und löscht, wie unten ausführlicher beschrieben wird. Vorzugsweise sind diese Benutzerinteressen benutzer- und klassenspezifisch, so daß sie auf der Basis der gewöhnlichen Verzeichnisoperationen jedes Benutzers erzeugt und automatisch gelöscht werden können, wobei jeder Benutzer verantwortlich ist, sein eigenes persönliches Interesse an einer gegegebenen Klasse eindeutig zu identifizieren. Wenn z.B. ein Benutzer in ein Dokument eintritt, das einen VR In sein Dokumenten- oder Briefverzeichnis enthält, kann ein RPC eingeleitet werden, um des Interesse Benutzers an diesem VR im Sprachmanager 34 In der folgenn Form zu registrieren: RETAIN[SprachStrangID, Klasse, Interesse, BenutzerID].
Diese Prozedur registriert das Interesse eines spezifizierten Benutzers in einem gegebenen VR durch eine gegebene Klasse (z.B. Dateianmerkung oder Nachricht). Diese Operation ist idempotent, so daß nachfolgende Aufrufe mit denselben Argumenten nur ein Interesse an einem gegebenen Sprachstrang registrieren. Außerdem gibt es eine Prozedur FORGET [SprachStrangID, Klasse, Interesse], die gelegentlich durch einen RPC, der an den Sprachmanager 34 ausgegeben wird, wenn der Benutzer das Dokument oder die Nachricht, die den VR enthält, aus seinem verzeichnis löscht (im Gegensatz zum Verlagern derselben in ein anderes On-line- oder Off-line-Verzeichnis) und sonst als Resultat eines unten zu beschreibenden Abfallsammelvorgangs aufgerufen wird. Des weiteren kann eine Prozedur LOOKUP [Klasse, Interesse] bereitgestellt werden, die eine ungeordnete Liste von Sprachsträngen, die mit einem einzelnen Interesse verbunden sind, zurückbringt, um die normalen Systemverwaltungsfunktionen zu erleichtern.
Die Interessen- Klassenattribute des von Benutzer aufgerufenen Interessenmechanismusses sind typischerweise beliebige Textkettenwerte. Die Form des Interessenwertes ist aber vorzugsweise klassenspezifisch, so daß jede Klasse ihren eigenen Namensraum von Interessen durch die Verwendung einer hierarchischen, flachen oder anderen Form von Identifizierung für ihre Interessenwerte steuert. Die Klasse eines Interesses identifiziert andererseits gewöhnlich die Art, in der Sprachstränge für eine einzelne Anwendung benutzt werden. Zum Beispiel kann eine "DateiKommentar"-Klasse benutzt werden, tat anzuzeigen, daß ein in einer benannten Datei gemeinsam benutztes Dokument durch einen Satz von Sprachsträngen kommentiert wird, wobei das Interessenfeld benutzt wird, um den Dateinamen bereitzustellen. Ebenso kann eine "Nachrichten"-Klasse anzeigen, daß eine elektronische Briefnachricht auf aufgezeichnete Sprache verweist, wobei das Interessenfeld den eindeutigen Aufgabestempel enthält, der von dem Nachrichtensystem der einzelnen Briefnachricht, in der ein solcher Verweis enthalten ist, geliefert wird.
Der Sprachmanager 34 (Fig. 1) ist typischerweise, wie in Fig. 3 gezeigt, logisch geschichtet, um eine einfache, aber robuste Einrichtung zur Implementierung der oben beschriebenen Sprachstrang-Editiermerkmale und zur Verwaltung der Benutzerinteressen in solchen Sprachsträngen und ihren darunterliegenden Sprachdateien zur Verfogung zu stellen. Der Sprach-Dateiserver 36 muß imstande sein, eine ununterbrochene Datenübertragungsrate von 64 kBit/s für Sprache aufrechtzuerhalten und das Abspielen von willkürlich eingeplanten Sequenzen von Sprachdateiabschnitten zu unterstützen, wobei eine angemessene Pufferung bereitgestellt wird, um wahrnehmbare Pausen zwischen aufeinanfolgenden Sequenzen zu vermeiden, aber diese Anforderungen sind relativ gemäßigt und werden, den augenblicklichen Stand der Technik vorausgesetzt, leicht erfüllt.
Ein einfaches Datenbanksystem 41 wird zur Verfügung gestellt, um die Sprachstränge und ihre zugehörigen Interessen zu implementieren. Zu diesem Zweck speichert das Datenbanksystem 41 die Sprachstränge (VRs) als unveränderbare Stücktabellen, die auf unveränderbare Dateien und/oder Dateisegmente verweisen, stellt elementare Abfrage- und Aktualisierungsmöglichkeiten bereit und unterstützt die gemeinsame Benutzung der VRs unter den vielen Benutzern, die sie verwenden können, um auf die darunterliegenden Sprachdateien zu verweisen. Jedes Datenbanksystem, das diese mäßigen Forderungen erfüllt, würde genügen. Ein derartiges System speichert z.B. jeden Eintrag als eine Folge von Attributen augedrückt als Schlüssel/Wert-Paare in einem Vorausschreib-Protokoll, etwa wie von Gray, "Notes on Database Operating Systems" in Bayer et al., Operating Systems: an Advanced Course, Springer-Verbig, 1978, Seiten 393-481 beschrieben. Anders als die meisten Datenbanksysteme, bei denen die Daten nur protokolliert werden, bis sie an eine dauerhaftere Stelle übergeben und geschrieben werden, ist jedoch das Vorausschreib-Protokoll innerhalb des Datenbanksysteme 41 die permanente Quelle der Daten (h.h., einmal geschrieben, werden die Daten niemals bewegt). Daher können B-Baum-Indexe durch direkten Verweis auf das Vorausschreib-Protokoll gebildet werden, um die Werte von einem oder mehr Schlüsseln zu den entsprechenden Stellen in den Protokolldateien zuzuordnen. Ähnliche Verfahren sind verwendet worden, um Protokolle für elektronische Briefsysteme zu konstruieren. Siehe Donahue et al., "Walnut: Storing Electronic Mail in Databases", Xerox Palo Alto Research Center, Technical Report CSL-85-9, Nov. 1985. Siehe ferner Lampson, "Hints für Computer System Design", Proceedings Ninth Symposium on Operating System Principles, Bretton Woods, Nem Hampshire, Okt. 1983, Seiten 33-48.
Die minimale Datenstruktur, um einen Sprachstrang darzustellen, besteht aus [SprachDateiID, Schlüssel, Intervall] Tupeln. Weitere Attribute können für SprachStrangID, Identität des Erzeugers, Zugriffssteuerlisten und Gesamtlänge des Sprachstrangs eingeschlossen werden. Das heißt, daß ein typischer Datenbank-Protokolleintrag für einen Sprachstrang die folgende Form haben kann:
SprachStrangID: Hugo.pa#575996078
Erzeuger: Hugo.pa
Länge: 80000
Abspielzugriff: Sprachprojekt ^.pa
Editzugriff: keiner
SprachDateiID: 235
Schlüssel: 17401121062B 10300460467B
Intervall: 0 80000
Ein solcher Eintrag kann benutzt werden, um einen Index zu konstruiren, der es erlaubt, Sprachstrangstrukturen durch ihre SprahhStrangIDs effizient zurückzugewinnen. Er erlaubt ferner, einen Index von Sprach- DateiIDs zu unterhalten, der zur Abfallsammlung nützlich ist, wie unten ausführlicher beschrieben wird.
Wie man sich erninnern wird, können komplexere Sprachstränge mit Hilfe des vorerwähnten Sprachstrang-Editierprozesses konstruiert werden. Wie z.B. in Fig. 4 gezeigt, können zwei einfache Sprachstränge VR&sub1; und VR&sub2; mit den folgenden Strukturen vorhanden sein:
VR&sub1; = < SprachdateiID: VF&sub1;, Schlüssel: K&sub1;, Intervall: [Start: 0, Länge: 4000]>
VR&sub2; < SprachdateiID: VF&sub2;, Schlüssel: K&sub2;, Intervall: [Start: 500, Länge: 2000]>
in diesem Fall erzeugt die Operation:
REPLACE[Base: VR&sub1;, Intervall: [Start: 1000, Länge: 1000], mit: VR&sub2;)
einen neuen Sprachstrang VRs mit der Struktur:
VR&sub3; : (SprachdateiID: VF&sub1;, Schlüssel: K&sub1;, Intervall:
[Start: 0, Länge: 1000],
SprachdateiID: VF&sub2;, Schlüssel: K&sub2;, Intervall:
[Start: 500, Länge: 2000]
SprachdateiID: VF&sub1;, Schlüssel: K&sub1;, Intervall:
[Start: 2000, Länge: 2000]>
Revidiert man kurz die Verwaltung und das Editieren von digital aufgezeichneter Sprache und anderen datenintensiven Nicht-Textdaten, mit denen diese Erfindung benutzt werden kann, wird man sich erinnern, daß, wenn Sprache aufzuzeichnen ist, der Sprachmanager 34 den Sprach- Dateiserver 36 anruft, eine neue VF zu erzeugen und die Sprache, die über einen spezifizierten Dialog mit einer gegebenen DialogID eintrifft, als der Inhalt dieser neuen VF zu speichern. Nach dem Ende der Aufzeichnung fügt der Sprachmanager 34 eine einfache VR der Sprachstrang-Datenbank in dem Datenbanksystem 41 hinzu, um die neu aufgezeichnete VF darzustellen. Der Codierungsschlüssel, der durch den Sprach-Steuerserver 32 zugewiesen wurde, um den Dialog zu codieren, wird in dem Sprachstrang-Datenbankeintrag gespeichert, so daß dieser Schlüssel zusammen mit der SprachdateiID während aller folgenden Editieroperationen, die ein oder mehr Intervalle des VR betreffen, mitgeführt wird. Die Sprachdatei wird, auch bei. Editieren, weder bewegt noch kopiert, sobald sie einmal in einer VF&sub1; aufgezeichnet ist.
Wenn ein VR abgespielt wird, gewinnt der Sprachmanager 34 zuerst die VR-Struktur aus dem Datenbanksystem 41 zurück. Wenn die verbürgten Identitäten aller Teilnehmer an der Wiedergabe des VR mit allen mit dem VR verbundenen Zugriffssteuerungen übereinstimmen, setzt der Sprachmanager 34 den Wiedergabevorgang fort, indem er den oder die Codierungsschlüssel für die spezifizierten Intervalle der mit dem gegebenen VR verbundenen VFs an die Teilnehmer verteilt und den Sprach-Dateiserver 36 veranlaßt, diese VF-Intervalle in der richtigen Reihenfolge zu spielen. Wie zuvor dargelegt, besitzt der Sprach- Dateiserver 36 einen ausreichend großen Ausgabepuffer, um zu ermöglichen, daß zwei oder mehr VF-Intervalle gespielt werden können, ohne irgendwelche Pausen dazwischen einzuführen.
Die VRs besitzen vorteilhafterweise eine flache struktur, um die Wiedergabeleistung zu erhöhen, d.h., ein einziger Datenbankzugriff reicht aus, um die vollständige Struktur eines gegebenen VR zu ermitteln, weil jeder VR direkt auf seine zugehörigen VFs verweist. Alternativ könnten komplexe VRs als Abschnitte anderer VRs in einer baumorganisierten Datenbank mit VRs, die Abschnitte von VFs in den Blättern des Baumes darstellen, gemeinsam benutzt werden. Dieser Weg würde die Verarbeitungskosten des Editierens von VRs reduzieren, würde aber die Zahl von Datenbankzugriffen erhöhen, die benötigt wird, um komplexe VRs abzuspielen, die zwei oder mehr spezifizierte Abschnitte derselben oder verschiedener VFs darstellen. Mit anderen Worten, es ist ein Kompromiß zu machen, um die VR-Datenbankstruktur für ein einzelnes Anwendungsmuster zu optimieren.
Wie man einsehen wird, wird, sobald alle VRs, die auf eine gegebene VF verweisen, gelöscht worden sind, keine VR jemals wieder auf diese einzelne VF verweisen, somit wird der Speicherraum auf dem Sprach- Dateiserver 36, der dieser VF zugeteilt ist, durch Löschen der VF zur nachfolgenden Wiederverwendung vorteilhaft zurückgewonnen. Eine Geradeaus-Abfrage der Sprachstrang-Datenbank innerhalb des Datenbanksystems 41 reicht aus, um festzustellen, ob noch irgendwelche VRs existieren, die auf eine gegebene VF verweisen. Schwerer ist es jedoch, festzustellen, ob ein gegebener VR gelöscht werden kann oder nicht. Die oben beschriebenen "Interessen"-Operationen sind daher der Schlüssel, der es erlaubt, Vrs und ihre zugehörigen VFs automatisch zurückzugewinnen.
Von den Benutzern wird verlängt, daß sie ihre VR-Interessen in einer bekannten Stelle, z.B. in einer Interessen-Datenbank innerhalb des Datenbanksystems 41, speichern. Diese gespeicherten Interessen dienen dann als Stellvertreter für die VR-Verweise, die der Benutzer übergibt, wodurch eine logische Basis zum Unterscheiden zwischen gültig verwiesenen aktiven VRs und nicht-verwiesenen veralteten VRs bereitgestellt wird. Ein Verweis-Entkräftungmechanismus, z.B. eine spezifizierte Zeitsperrendauer, kann, wenn gewünscht, in ein getrenntes Interesse eingeschlossen werden, also wird man verstehen, daß das VR- Veralten eintritt, wenn es keine existierenden gültigen Verweise auf den gegebenen VR, einschließlich nicht abgelaufener Zeitsperren, gibt.
Es wurde vorangehend zum Ausdruck gebracht, daß, wenn eine RETAIN- Prozedur aufgerufen wird, der Interessen-Datenbank ein Eintrag hinzugefügt wird, vorausgesetzt, daß der Eintrag nicht bereits existiert. Der Datenbankeintrag umfaßt die SprachStrangID, die Klasse des Interesses, einen Interessenwert und die Identifikation des Benutzers, wodurch Interessen-Datenbankabfragen auf der Basis eines dieser Attribute erlaubt werden. Leider ist es manchmal unpraktisch, bestehende Workstations und Dateiserver zu modifizieren, um die RETAIN- und ihre komplementäre FORGET-Prozedur automatisch aufzurufen, um Benutzerinteressen an einem gegebenen VR zu speichern und zu löschen, wenn Dokumente oder Nachrichten, die Verweise auf diesen VR enthalten, in die Benutzerverzeichnisse eingetragen bzw. daraus entfernt werden. Es ist aber machbar, in das Betriebssystem jedes Benutzers ein zusätzliches Programm aufzunehmen, das automatisch aufgerufen wird, wenn der Benutzer eine Datei, die einen VR-Verweis enthält, von der vorübergehenden Speicherung der Workstation in einen Dateiserver zur dauerhafteren Speicherung verlagert, wobei ein Aufruf des folgenden Typs für jeden in einer sochen Datei verwiesenen Sprachstrang ausgegeben wird:
RETAIN [VRID: SprachStrangID, Klasse "Dateikommentar,
Interesse: Kommentierte Datei Name",
Benutzer: Verbürgter Name]
Daher kann zu jedem späteren Zeitpunkt eine normale Dateiserver-Verzeichniszähloperation durchgeführt werden, um für jedes gegebene Benutzerinteresse festzustellen, ob der benutzerbenannte Fall der Datel (z.B. Kommentierte Datei Name"), die den VR-Verweis enthält, auf den sich das gegebene Interesse bezieht, noch existiert oder nicht. Die Anwendungen jedes Benutzers ermitteln die Klasse oder Klassen der durch einen solchen Benutzer registrierten Interessen, und diesen Interessen werden benutzerbestimmte Werte gegeben (z.B. "Kommentierte Datei Name" für die Interessenklasse "Dateikommentar"). Dies bedeutet, daß die einzelnen Benutzer für die Zuweisung einmaliger Werte, z.B. verschiedene Versionsnummern, an die verschiedenen Interessen verantwortlich sind, die sie innerhalb einer gegegeben Klasse von Interessen einzutragen wünschen.
Um veraltete Interessen automatisch zu lokalisieren und aus der Interessen-Datenbank zu entfernen, kann der Implementierer jeder Interessenklasse eine Prozedur des folgenden Typs bei dem Sprachmanager 34 registrieren:
IS GARBAGE [SprachStrangID, Interesse] - {Ja/Nein}
Diese Prozedur stellt in einer klassenspezifischen Weise fest, ob ein gegebenes Interesse noch für einen spezifischen VR gilt oder nicht. Für die vorerwähnte Klasse Dateikommentar bringt z.B. diese Prozedur "Ja" nur zurück, wenn der benutzerspezifizierte Wert des Interessenparameters auf keinem Dateiserver irgendwo innerhalb des verteilten Computersystems 21 mehr existiert.
Wie in Fig. 5 gezeigt, enthält der Sprachmanager 34 geeigneterweise einen Interessen-Verifizierer, der periodisch die Interessen-Datenbank aufzählt, 51-54, und die klassenspezifische IS GARBAGE-Prozedur (sofern eine eingetragen worden ist) für jedes Interesse aufruft, 55- 56. Die IS GARBAGE-Prozedur für jede Interessenklasse kann verschiedene Kriterien benutzen, um festzustellen, ob ein Eintrag innerhalb der gegebenen Klasse gültig ist oder nicht, 57. Die Prozedur kann z.B. den Eintrag gegen intrinsiche Entkräftungskriterien, z.B. den Ablauf einer vorbestimmten Zeitsperrendauer und die Vereinbarkeit mit einer Zugriffssteuerliste, prüfen. Sie kann ferner eine Verzeichnisabfrage an die Dateiserver des verteilten Computersystems 21 ausgeben, um festzustellen, ob der für den untersuchten Eintrag spezifizierte Interessenwert (z.B. "Kommentierte Datei Name") auf einem oder mehr Dateiservern noch existiert. Wenn festgestellt wird, daß das gegebene Interesse aus irgendeinem Grund ungültig ist, wird eine Prozedur FORGET [SprachStrangID, Klasse, Interesse] aufgerufen, 58, um es aus der Interessen-Datenbank zu entfernen, 59.
Gemäß Fig. 6 besitzt der Sprachmanager 34 auch einen Sprachstrang-Abfallsammler, der periodisch die Sprachstrang-Datenbank aufzählt, 71- 74, so daß verwaiste VRs daraus entfernt werden, 75. Wünschenswert wird eine Vorkehrung getroffen, um VRs einiger oder aller Klassen wenigstens für eine endliche Zeitdauer nach ihrer Erzeugung intrinsisch zu schützen, 76, so daß interessierte Benutzer eine annehmbare Gelegenheit haben, ein interesse an ihnen zu registrieren. Bei Nichtvorhandensein eines solchen intrinsischen Schutzes wird eine gegebene VR jedoch aus der sprachstrang-Datenbank entfernt, sofern nicht bei 77 festgestellt wird, daß auf die untersuchte VR noch von wenigstens einem gültigen Interesse in der Interessen-Datenbank verwiesen wird.
Wie in Fig. 7 gezelgt, kann ein getrennter Sprachdatei-Abfallsammler in den Sprachmanager 34 eingeschlossen werden, der periodisch die Sprachdatei-Datenbank aufzählt, 81-84, so daß die VFs, die bei 85 gefunden werden und keine auf sie verweisenden VRs mehr haben, gelöscht werden, 86, wodurch der Speicherraum auf dem Sprach-Dateiserver 36 (Fig. 1), der ihnen zugeteilt war, zurückgewonnen wird.
Alternativ kann aber, wie in Fig. 8 gezeigt, der Sprachdatei-Abfallsammler mit dem Sprachstrang-Abfallsammler integriert werden, so daß diese Funktionen gleichzeitig ausgeführt werden. Wenn z.B. festgestellt wird, daß ein gegebener VR zur Waise geworden ist, bei 77 in Fig. 6, können die VFs, auf die der verwaiste VR verweist, aufgezählt werden, 91-93. Dies macht es möglich, jede dieser FVs gegen die Sprachstrang-Datenbank zu vergleichen, um festzustellen, ob auf sie von irgendwelchen anderen VRs verwiesen wird, 94, so daß verwaiste VFs gelöscht werden, 95. Nachdem alle VFs, auf die ein verwaister VR verweist, untersucht worden sind, wird der VR gelöscht, 75, und der Prozeß geht dann zurück, um die Aufzählung der VRs mit dem nächsten VR, 72 In Fig. 6, fortzusetzen.
Desgleichen kann, wie in Fig. 9 gezelgt, der Sprachstrang-Abfallsammler mit dem Interessen-Abfallsammler integriert werden. Jeder Eintrag in der Interessen-Datenbank verweist auf einen einzigen VR, so daß, wenn festgestellt wird, daß ein gegebenes Intersesse ungültig ist, 57 in Fig. 5, die Interessen-Datenbank untersucht werden kann, 96 in Fig. 9, um festzustellen, ob sie noch andere Interessen enthält, die auf den mit dem ungültigen Interesse verbundenen VR verweisen, 97. Wenn kein anderer Verweis auf den gegebenen VR gefunden wird, werden sowohl der VR als auch der ungültige Interesseneintrag gelöscht, 98 bzw. 99. Andererseits wird, wenn andere auf den VR verweisende Interessen vorhanden sind, nur das ungültige Interesse gelöscht, bevor der Prozeß zurückspringt, um die Aufzählung der Interessen-Datenbank mit dem nächsten Interesse fortzusetzen, 52 in Fig. 5.
Angesichts des Vorangehenden wird man nun verstehen, daß die vorliegende Erfindung einen leistungsfähigen und wirkungsvollen Abfallsammler für Hypermedia-Anwendungen von verteilten Rechensystemen zu Verfügung stellt.

Claims

1. Verteiltes Rechensystem, das umfaßt:

eine Kommunikationseinrichtung (22),

eine Mehrzahl von Arbeitsplätzen (24), die mit der Kommunikationseinrichtung verbunden sind und Benutzer befähigen, digitale Text-Datendateien zwischen den Arbeitsplätzen hin und her zu übertragen,

einen Dateiserver (36), der mit der Kommunikationseinrichtung verbunden ist und digitale Nicht-Text-Datendateien, die menschlich wahrnehmbare Information darstellen, speichert,

Wandler, die in der Nähe von wenigstens einigen der Arbeitsplätzen gelegen sind, wobei die Wandler mit der Kommunikationseinrichtung verbunden sind, um Benutzer zu befähigen, eindeutig benannte Nicht-Text- Datendateien auf dem Dateiserver aufzuzeichnen und solche Dateien abhängig von der Zugriffsberechtigung abzuspielen, und

eine Verwaltungseinrichtung (34), die mit der Kommunikationseinrichtung und dem Dateiserver verbunden ist, wobei die Verwaltungseinrichtung ein erstes Datenbanksystem enthält, das eine erste Datenbank (41) von eindeutig benannten Verweiseinträgen (VR1, VR2, VR3) umfaßt, die durch Dateiname und Zeitintervall auf die Nicht-Text-Datendateien verweisen, wodurch Benutzern ein selektiver Zugriff auf ausgewählte und ausgewählte Teile von ausgewählten der Nicht-Text-Datendateien durch Einlagern der ihnen entsprechenden Verweiseintragsnamen in die digitalen Text-Datendateien, die über die Kommunikationseinrichtung an ausgewählte Benutzer verteilt werden, gewährt werden kann, gekennzeichnet durch

eine zweite Datenbank von benutzerregistrierten Interesseneinträgen in dem Datenbanksystem, wobei jeder der Interesseneinträge den Verweiseintrag (VR1, VR2, VR3), zu dem er gehört, die digitale Text-Datendatei, in die der Verweiseintrag eingelagert ist, und den Benutzer, der die digitale Text-Datendatei benutzt, identifiziert,

eine erste Einrichtung, die mit der zweiten Datenbank von benutzerregistrierten Interesseneinträgen verbunden ist und die periodisch alle registrierten Interesseneinträge aufzählt und irgendwelche Interesseneinträge, für die die digitale Text-Datendatei für den Benutzer nicht mehr existiert, löscht,

eine zweite Einrichtung, die mit der Datenbank von Verweiseinträgen verbunden ist und die periodisch die Verweiseinträge (VR1, VR2, VR3) aufzählt und irgendwelche Verweiseinträge von mehr als einem spezifischen Alter, die keine auf sie verweisenden Interesseneinträge in der zweiten Datenbank besitzen, löscht, und

eine dritte Einrichtung, die mit dem Dateiserver (36) verbunden ist und die in dem Dateiserver (36) irgendwelche Nicht-Text-Datendateien, die keine auf sie verweisenden Verwelseinträge in der ersten Datenbank besitzen, löscht, um dadurch den von veralteten Dateien belegten Speicherraum zurückzugewinnen.