DE4436677A1 - Verfahren und Einrichtung zum Übertragen von Datenblöcken großer Objekte in einem Telekonferenzsystem - Google Patents
Verfahren und Einrichtung zum Übertragen von Datenblöcken großer Objekte in einem TelekonferenzsystemInfo
- Publication number
- DE4436677A1 DE4436677A1 DE4436677A DE4436677A DE4436677A1 DE 4436677 A1 DE4436677 A1 DE 4436677A1 DE 4436677 A DE4436677 A DE 4436677A DE 4436677 A DE4436677 A DE 4436677A DE 4436677 A1 DE4436677 A1 DE 4436677A1
- Authority
- DE
- Germany
- Prior art keywords
- request
- data
- blob
- participants
- queue
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/02—Details
- H04L12/16—Arrangements for providing special services to substations
- H04L12/18—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
- H04L12/1813—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast for computer conferences, e.g. chat rooms
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/40—Network security protocols
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Security & Cryptography (AREA)
- General Engineering & Computer Science (AREA)
- Multimedia (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Computer And Data Communications (AREA)
- Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
- Information Transfer Between Computers (AREA)
Description
Die Erfindung betrifft Telekonferenzsysteme. Insbesondere
bezieht sich die Erfindung auf Mechanismen zum Austauschen von
Daten zwischen einer Mehrzahl von Teilnehmern in einem elektro
nischen Konferenzsystem.
Ein sich zunehmend entwickelndes Gebiet bei der Vernetzung
von Computern ist das Gebiet der elektronischen Konferenzen.
Konferenzen bieten die Möglichkeit, ein elektronisches On-bine
"Treffen" zwischen einer Vielzahl von Benutzern an einem Compu
tersystem an einer Vielzahl von Orten durchzuführen. Benutzer
an unterschiedlichsten Stellen können miteinander kommunizie
ren, als ob sie im gleichen Raum wären. Unter Verwendung sol
cher Anwendungsprogramme haben moderne Kommunikationssysteme
die Möglichkeit geschaffen, Treffen durchzuführen, bei denen
sämtliche Benutzer über ihre individuellen Computersysteme
teilnehmen und sich Daten, Graphik, Text und andere Informati
onsarten teilen. Benutzer können miteinander kommunizieren,
indem sie sich Daten in Form von graphischen Abbildungen, Text
oder anderen Anmerkungen oder anderen auf einem Display des
Computersystems darstellbaren Informationen teilen. Dies findet
analog zu einem Treffen statt, bei dem die Teilnehmer sich ge
genübersitzen und Informationen einander auf einer weißen oder
schwarzen Tafel darstellen und wobei andere Teilnehmer Anmer
kungen hinzufügen oder löschen können oder die Tafel andere
Weise modifizieren können. Es ist darüber hinaus zu erwarten,
daß in dem Maße, in dem die Bandbreite von Kommunikationsmedien
verbessert wird und Kompressionsstandards für graphische Daten
robuster werden, Videodaten unter einer Vielzahl von
miteinander verbundenen Benutzern während solcher Fernkonferen
zen ebenfalls geteilt werden.
Eines der Erfordernisse eines elektronischen Konferenzsy
stems ist die Notwendigkeit, die gleichen Daten auf den Dis
plays sämtlicher an der Konferenz teilnehmender Benutzer zu re
produzieren. Solche Systeme implementieren typischerweise diese
Fähigkeit auf unterschiedlichste Weise. Der gebräuchlichste Weg
ist das Client/Server-Modell, bei dem ein einziger verbundener
Knoten als "Server" der anderen Knoten des Systems agiert, und
die restlichen in der Konferenz miteinander verbundenen Knoten
als Slaves oder Clients des Server-Prozesses agieren. Folglich
empfängt jeder dieser Clients überwiegend Daten von der Zen
tralmaschine, um sein Display zu aktualisieren. Solche Systeme
sind jedoch vollständig abhängig von den Diensten, die von dem
Server zur Verfügung gestellt werden, und dem Durchsatz des
Kommunikationsmediums. Offensichtlich leiden Systeme, in denen
die Clients mehr oder weniger als Displays und Eingabeeinrich
tungen für Benutzeranforderungen dienen, an schweren Leistungs
problemen infolge der sich ergebenen Aktualisierung von Daten
von dem Server, welche typischerweise seriell von dem Server
behandelt werden.
Eine andere bekannte Lösung zur Aufrechterhaltung der Syn
chronität sämtlicher Teilnehmer-Displays in einem Konferenzsy
stem stützt sich auf ein verteiltes Client/Server-System. Bei
einer verteilten Client/Server-Lösung wird eine geteilte Ob
jekt-Struktur auf dem Server gehalten und Clients werden über
Änderungen der verteilten Informationen durch Warnsignale oder
Dämonen (demons) informiert. Der Nachteil dieser Lösung ist,
ähnlich wie bei der zentralisierten Client/Server-Lösung, das
Angewiesen-Sein auf die Architektur selbst. Dies schließt eine
Datenkonferenz-Anbindung ein, welche in der Lage sein muß, ver
schiedene Benutzer über eine Telefonleitung von Punkt zu Punkt
ohne das Erfordernis eines Zugriffs auf einen zentralen gemein
samen Server zu verbinden.
Bei der Client/Server-Lösung leidet darüberhinaus die Lei
stungsfähigkeit in hohem Maße dadurch, daß Anforderungen zum
Hinzufügen oder Löschen von Objekten, wie beispielsweise Anmer
kungen, graphischen Abbildungen oder anderen Informationen auf
einem Teilnehmer-Display, vollständig von der Kommunikation von
dem Server abhängig sind. Somit leidet die Echtzeit-Leistungs
fähigkeit bei bekannten Client/Server-Modellen, da die Genehmi
gung zum Einwirken auf und manipulieren von Objekten auf einem
Teilnehmer-Display vollständig abhängig ist von einem gesamten
Satz abhängiger Variablen, wie beispielsweise der Anzahl der
beim Server anhängigen Anforderungen, dem Durchsatz des Kommu
nikationsmediums, der Anzahl der verbundenen Teilnehmer usw.
Eine weitere bekannte Lösung zur Aufrechterhaltung der Syn
chronizität einer Mehrzahl von Teilnehmern in einem Konferenz
system ist die Verwendung eines verteilten objekt-orientierten
Systems. Dies ist eine verallgemeinerte Lösung, welche sich,
bei einer bekannten Lösung, auf Erweiterungen der Smalltalk-
Sprache selbst stützt. Bei diesem bekannten System senden
"lokale" Objekte Nachrichten zu "Stellvertreter" -Objekten, wel
che lokale Repräsentanten für Objekte in dem "geteilten" Ob
jektraum sind. Die Stellvertreter-Objekte kommunizieren mit den
realen Objekten über einen RPC-Mechanismus (Remote Procedure
Call-Fern-Prozeduraufruf). RPC ist ein Protokoll, das das
Verfahren regelt, mit welchem eine Anwendung Prozesse auf ande
ren Knoten aktiviert und die Ergebnisse zurückgewinnt. Solch
ein herkömmlicher Mechanismus wird von Sun Microsystems, Inc.,
definiert und in RFC-1057 beschrieben, was einen Standard für
eine Initiierung und Erneuerung von Prozessen auf fernen oder
verteilten Computersystemen schafft.
Das Problem bei dieser Lösung liegt in seiner Allgemeingül
tigkeit, welche eine extensive Unterstützung bei der Teilung
beliebiger Objekte erfordert, während keine Annahmen über das
Verhalten der Objekte gemacht werden. Dies hat zwei Nachteile.
Zuerst wird ein komplexes "Smalltalk-System" benötigt, um die
Verteilung von Objekten allgemein zu unterstützten. Zweitens
ist das Konkurrenzproblem für ein beliebiges Objekt schwierig,
weil mehrere Teilnehmer unterschiedliche Objekte in ihren Sy
stemen haben können und solche unterschiedlichen Objekte mögli
cherweise nicht in der Lage sind, zu den restlichen Benutzern
kommuniziert oder übertragen zu werden.
Ein weiterer Nachteil bekannter Datenkonferenzsysteme liegt
in ihrer Fähigkeit zum Unterstützen der Übertragung sehr großer
Informationsblöcke. Typischerweise stützen sich solche Systeme
auf Punkt-Zu-Punkt-Kommunikationsschemen, bei welchen einzelne
Knoten, wie beispielsweise der Server in dem Client/Server-Mo
dell, die Informationen von einem einzelnen Knoten zu dem Ser
ver und dann von dem Server zu den restlichen Teilnehmersyste
men übertragen muß. Außerdem verbraucht die Übertragung sehr
großer Datenblöcke, wie beispielsweise Dateien, und/oder Abbil
dungen oder andere Daten, einen großen Teil der Ressourcen in
dem System und der Bandbreite des Kommunikationsmediums. Folg
lich leiden bekannte Konferenzsysteme an schweren Leistungsein
bußen, die von der Datenmenge verursacht werden, welche inner
halb des Systems während einer Telekonferenz übertragen werden
können.
Die Erfindung bezieht sich auf ein Verfahren und eine Ein
richtung zur Kommunikation zwischen Teilnehmern in einem elek
tronischen Konferenzsystem. Es wird ein Verfahren angegeben zum
Übertragen von Datenblöcken großer Objekte zwischen einer
Mehrzahl von Teilnehmern während einer elektronischen Konferenz
in einem elektronischen Konferenzsystem, in dem sich die Mehr
zahl von Teilnehmern während der elektronischen Konferenz Daten
teilen, das die folgenden Schritte aufweist:
- a) Empfangen einer asynchronen Anforderung nach Daten gro ßer Objekte;
- b) Anordnen der Anforderung in einer Anforderungswarte schlange;
- c) Empfangen einer asynchronen Anforderung zum Umpriorisie ren der Anforderungswarteschlange;
- d) Bestimmen der Fähigkeit eines Transportmediums;
- e) Partitionierung der Daten großer Objekte in Datenblöcke, wobei die Größe der Datenblöcke variabel ist und der Fähigkeit des Transportmediums angepaßt wird;
- f) Übertragen der angeforderten Daten großer Objekte zu je dem der Teilnehmer über das Transportmedium;
- g) Entfernen der Anforderung aus der Anforderungswarte schlange bei Abschluß des Sendens der angeforderten Daten der großen Objekte.
Die Erfindung schafft ein Datenkonferenzsystem, bei dem die
Echtzeit-Leistungsfähigkeit der einzelnen Teilnehmer des Daten
konferenzsystems nicht an Leistungsproblemen infolge des Durch
satzes des Mediums leidet.
Es wird ein verbessertes Datenkonferenzsystem geschaffen,
welches es den Benutzern gestattet, in der Konferenz von ihren
einzelnen Systemen eine Antwort mehr oder weniger in Echtzeit
zu erhalten.
Die Erfindung überwindet die Nachteile der bekannten Cli
ent/Server-Modelle, die für bestimmte Konferenzanwendungen zur
Verfügung gestellt werden.
Die Erfindung schafft ein System, welches die Konkurrenz
unter einer Mehrzahl von Teilnehmern in einer Konferenzanwen
dung ermöglicht, welches jedoch nicht die Echtzeit-Leistungsfä
higkeit verringert.
Die Erfindung schafft die Möglichkeit zum Übertragen sehr
großer Datenblöcke, ohne die Echtzeit-Leistung für Benutzer in
einem Konferenzanwendungsprogramm zu beeinträchtigen.
Im folgenden wird die Erfindung anhand von in der Zeichnung
dargestellten Ausführungsbeispielen näher beschrieben.
Fig. 1a veranschaulicht eine Topologie eines Systems, in
welchem verschiedene Teilnehmer in einem Konferenzsystem mit
einander verbunden werden können.
Fig. 1b veranschaulicht ein Blockschaltbild einer in einem
Teilnehmer eines Konferenzsystems enthaltenen Schaltung.
Fig. 2 ist eine Blockdarstellung der verschiedenen Steuer
prozeduren, welche in einem Teilnehmer einer Konferenz vorhan
den sind.
Fig. 3 ist eine Blockdarstellung der in einem implementier
ten Ausführungsbeispiel der Erfindung verwendeten Klassen.
Fig. 4 veranschaulicht die Arten von Anmerkungen, welche
auf einem Benutzer-Display des einzelnen Teilnehmers in ver
schiedenen Implementierungen des bevorzugten Ausführungsbei
spiels ausgeführt werden können.
Fig. 5 veranschaulicht die Objekt-Hierarchie, die in be
stimmten Ausführungsbeispielen der Erfindung verwendet wird.
Fig. 6a und 6b veranschaulichen Verfahrensablaufdiagramme
eines Prozesses, der bei Erfassung eines Ereignisses ausgeführt
wird, das die Erschaffung/Löschung/Modifikation von Objekten
während einer elektronischen Konferenz erfordert, wobei der
Prozeß in einem Ausführungsbeispiel der Erfindung von einer
Ereignisschleife des Objektmanagers ausgeführt werden kann.
Fig. 7a bis 7e veranschaulichen von einem Entscheider und
einem Teilnehmer in einem Konferenzsystem aufrechtgehaltene Ob
jektstrukturen zu verschiedenen Zeitpunkten, wenn ein Teilneh
mer Aktionen in seinem lokalen System ausführt.
Fig. 8 veranschaulicht ein Verfahren, das für die verzöger
te Übertragung sehr großer binärer Daten-Objekte in bestimmten
Ausführungsbeispielen der Erfindung verwendet wird.
Fig. 9 veranschaulicht ein Verfahrensablaufdiagramm einer
Datenobjektanforderung, die in einem Ausführungsbeispiel der
Erfindung verwendet wird.
Fig. 10 veranschaulicht die Bestimmung eines Transport-Qua
lifizierers, der zum Übertragen der Daten großer Objekte in ei
nem Ausführungsbeispiel der Erfindung verwendet wird.
Fig. 11 veranschaulicht ein Verfahrensablaufdiagramm eines
Prozesses, der zum Bestimmen der Notwendigkeit einer partiellen
Anforderung von Daten großer Objekte in einem Ausführungsbei
spiel der Erfindung verwendet wird.
Fig. 12a bis 12c veranschaulichen verschiedene Stufen der
Vervollständigung der Übertragung von Daten sehr großer Objekte
in einem Ausführungsbeispiel der Erfindung.
Fig. 13 veranschaulicht die Architektur eines Hintergrund-
Übertragungs-Managers.
Fig. 14 und 15 veranschaulichen die Verarbeitungslogik für
die Teilnehmer-Verbindungs/Trennungslogik.
Fig. 16 veranschaulicht einen Übertragungswarteschlangen
eintrag.
Fig. 17 veranschaulicht ein Beispiel des Übertragungsanfor
derungs-Umpriorisierungsprozesses.
Fig. 18 veranschaulicht ein Beispiel der Klar-zum-Senden-
Verarbeitung eines Übertragungswarteschlangeneintrags.
Fig. 19 und 20 veranschaulichen die Anforderungsverarbei
tungslogik der Erfindung.
Die Erfindung bezieht sich auf ein Verfahren und eine Ein
richtung zur Kommunikation zwischen Teilnehmern in einem elek
tronischen Konferenzsystem. Obwohl die Erfindung unter Bezug
nahme auf spezielle Signalnamen, Formate, Zeitintervalle und
andere spezielle Informationen beschrieben wird, dienen diese
nur Zwecken der Veranschaulichung und sind nicht im Sinne einer
Einschränkung der Erfindung zu verstehen. Für den Fachmann ist
es klar, daß viele Abwandlungen gemacht werden können, ohne von
dem Wesen und Umfang der Erfindung abzuweichen.
Wie in Fig. 1a gezeigt ist, kann ein Kommunikationssystem
eine Mehrzahl von Teilnehmern 11 bis 14 aufweisen, die alle an
ein Kommunikationsmedium 20 gekoppelt sind. In bestimmten Aus
führungsbeispielen der Erfindung hat jeder an das Medium 20 ge
koppelte einzelne Teilnehmer äquivalente Möglichkeiten, um die
Kommunikation zwischen den Teilnehmern zu ermöglichen. Das im
plementierte Konferenzsystem verwendet eine verteilte Lösung,
bei der jeder Teilnehmer (11 bis 14) lokale Kopien der Konfe
renzstruktur ("Treffen" genannt) aufrecht hält, wobei die
Kopien miteinander übereinstimmen sollen. Darüber hinaus dient
in einem Ausführungsbeispiel der Erfindung einer der Teilnehmer
13 als Entscheider, der Anforderungen zum Hinzufügen von Objekten
zu unterschiedlichen Strukturen innerhalb jedes Teilnehmers
gestattet, um die Konsistenz unter den auf den Systemen jedes
Teilnehmers angezeigten Objekten aufrechtzuerhalten. Das in den
verschiedenen Ausführungsbeispielen der Erfindung verwendete
System benutzt eine verteilte Architektur, bei der jeder Teil
nehmer (11 bis 14) lokale Kopien sämtlicher in der elektroni
schen Konferenz verwendeter Objekte aufrecht hält. Somit werden
Displays, Texte, Graphik und andere auf den Displays der Teil
nehmer des Computersystems angezeigte Informationen in Daten
strukturen dargestellt, die in lokalen Speichern jedes der
Systeme und/oder in mit den Systemen gekoppelten Medien-Geräten
gehalten werden. Folglich stellt das vorliegende System eine
Hybride der Client/Server-Architektur dar, bei der anstelle der
Aufrechterhaltung zentraler Kopien sämtlicher Objekte in dem
elektronischen Konferenzsystem jeder Teilnehmer eine lokale
Kopie der Daten hält, so daß Änderungen der Daten mehr oder we
niger sofort erfolgen. Die Struktur eines Teilnehmers, der mit
dem Kommunikationsmedium 20 gemäß Fig. 1a gekoppelt sein kann,
ist in Fig. 1b veranschaulicht.
Im folgenden wird auf Fig. 1b Bezug genommen, in der ein
System 100 gezeigt ist, das bei einem Ausführungsbeispiel eines
erfindungsgemäßen Teilnehmers (z. B. 11 gemäß Fig. 1a) implemen
tiert ist. System 100 weist einen Bus 101 oder eine andere
Kommunikationseinrichtung zum Austauschen von Informationen und
eine mit dem Bus 101 gekoppelte Verarbeitungseinrichtung 102
zum Verarbeiten von Informationen auf. System 100 weist ferner
einen mit dem Bus 101 gekoppelten Speicher mit wahlfreiem
Zugriff 104 (RAM) oder eine andere flüchtige Speichereinrich
tung (im folgenden als Hauptspeicher bezeichnet) zum Speichern
von Informationen und durch den Prozessor 102 auszuführenden
Instruktionen auf. Der Hauptspeicher 104 kann außerdem während
der Ausführung von Instruktionen durch den Prozessor 102 zum
Speichern temporärer Variablen oder anderer Zwischeninforma
tionen verwendet werden. Das System 100 weist darüber hinaus
einen mit dem Bus 101 gekoppelten Nur-Lese-Speicher 106 (ROM)
und/oder eine andere statische Speichereinrichtung zum Spei
chern statischer Informationen und von Instruktionen für den
Prozessor 102 und eine Datenspeichereinrichtung 107, wie
beispielsweise eine magnetische oder optische Platte und das
ihr zugeordnete Plattenlaufwerk, auf. Die Datenspeichereinrich
tung 107 ist mit dem Bus 101 zum Speichern von Informationen
und Instruktionen gekoppelt. Das System 100 kann ferner mit
einer Anzeigeeinrichtung 121, wie beispielsweise einer Katho
denstrahlröhre (CRT) oder einer Flüssigkristallanzeige (LCD)
verbunden sein, die zum Anzeigen von Informationen mit dem Bus
101 gekoppelt ist. Ein alphanumerisches Eingabegerät 121,
welches alphanumerische und andere Tasten einschließt, kann
außerdem mit dem Bus 101 zum Übermitteln von Informationen und
Befehlsselektionen an den Prozessor 102 gekoppelt sein. Ein
zusätzliches Benutzereingabegerät ist die Cursor-Steuereinrich
tung 123, beispielsweise eine Maus, ein Trackball, ein Stift
oder die Cursor-Tasten auf einer Tastatur, die mit dem Bus 101
gekoppelt ist zum Senden von Richtungsinformationen und Be
fehlsselektionen an den Prozessor 102 und zum Steuern der
Cursor-Bewegung auf dem Display 121. Eine andere Einrichtung,
welche mit dem Bus 101 gekoppelt sein kann, ist eine Hard-Copy-
Einrichtung 124, welche zum Drucken von Instruktionen, Daten
oder anderen Informationen auf einem Medium, wie beispielsweise
Papier, einen Film oder eine ähnliche Medienart, verwendet
werden kann. Bei dem beschriebenen Ausführungsbeispiel ist
ferner eine Kommunikationseinrichtung 125 mit dem Bus 101
gekoppelt, welche zum Kommunizieren mit anderen Teilnehmern
verwendet wird. Diese Kommunikationseinrichtung kann eine
beliebige Anzahl kommerziell verfügbarer Peripherieeinrichtun
gen für Netzwerke enthalten, wie beispielsweise solche, die zum
Koppeln an ein Ethernet- oder Token-Ring-Kommunikationsmedium
verwendet werden. Zu beachten ist, daß sämtliche oder ein Teil
der Komponenten des Systems 100 und der zugeordneten Hardware
in verschiedenen Ausführungsbeispielen verwendet werden können.
Bei einem Ausführungsbeispiel ist das System 100 ein IBM-
kompatibler Personalcomputer. Der Prozessor 102 kann ein 80×86-
kompatibler Mikroprozessor, wie beispielsweise der 80386, der
80486 oder der Pentium-Mikroprozessor, sein, der von der Intel
Corporation, Inc., in Santa Clara, Kalifornien, hergestellt
wird.
Zu beachten ist, daß die folgende Erörterung verschiedener
Ausführungsbeispiele speziell auf eine Reihe von Routinen Bezug
nimmt, welche in einer objekt-orientierten höheren Programmier
sprache geschrieben sind (z. B. in Microsoft C/C++, erhältlich
von Microsoft Inc., Redmond, BA). Diese Serie von Routinen wird
kompiliert, verbunden und dann während der Laufzeit im Objekt
code im System 100 abgearbeitet. Für den Fachmann ist es jedoch
klar, daß die folgenden Verfahren und Einrichtungen in speziel
len Hardware-Einrichtungen, wie beispielsweisen diskreten
Logikbauelemente, hochintegrierten Schaltungen (LSI′s), anwen
dungsspezifischen integrierten Schaltungen (ASIC′s) oder ande
rer spezieller Hardware, implementiert werden können.
Während der Konferenzlaufzeit ist innerhalb jedes Teilneh
mers eine Reihe von Software-Prozeduren abarbeitbar angeordnet,
welche in einer in Fig. 2 dargestellten Weise organisiert sind.
Fig. 2 veranschaulicht ein allgemeines Blockdiagramm der Orga
nisation des Prozesses innerhalb eines einzelnen Teilnehmers
bei einem Ausführungsbeispiel der Erfindung. Die Software-
Organisation 200 innerhalb eines einzelnen Teilnehmers weist
einen Mehr-Punkt-Prozeß 240 auf, welcher für die direkte Kommu
nikation über das Kommunikationsmedium 260 verantwortlich ist,
so daß mit anderen Teilnehmern 250 kommuniziert werden kann.
Dieser Prozeß stellt sämtliche Low-Level-Kommunikationsfunk
tionen zur Verfügung, welche ein direktes Zugreifen auf das
Kommunikationsmedium 260 gestatten. In verschiedenen Ausfüh
rungsbeispielen der Erfindung kann das Kommunikationsmedium 260
eines der verschiedenen Netzwerk-Standardmedien sein, bei
spielsweise ein lokales Netzwerk (LAN) vom Ethernet-, Token-
Ring- oder von einem anderen Typ.
Das Kommunikationsmedium 260 kann außerdem ein Telefon
netzwerk mit einer Modem-Verbindung oder ein anderes Datenkom
munikationsmedium sein. Die Mehr-Punkt-Funktion 240 stellt
folglich sämtliche notwendige Funktionen, wie die Paketbildung
und die Beantwortung von über das Kommunikationsmedium 260
empfangenen Kommunikationen, zur Verfügung. Die nächsthöhere
Ebene in der Software-Organisation 200 eines einzelnen Teilneh
mers ist der Konferenzmanager 230, welcher alle erforderlichen
Ausführungsfunktionen zur Kommunikation mit den Kommunikations
funktionen 240 der unteren Ebene und den von dem Bediener
schnittstellen-Prozeß 210 und dem Objektmanager 220 zur Verfü
gung gestellten Funktionen höherer Ordnung liefert. Der Konfe
renzmanager 230 steuert den Objektmanager 220 über eine Serie
von Rückrufen zu Kommandos in dem Konferenzsystem, welche
ausgeführt werden sollen. Der Konferenzmanager 230 führt dar
über hinaus die Rückrufe in den Objektmanager 220 entsprechend
den von dem Kommunikationsprozeß 240 empfangenen Nachrichten
aus und lenkt die Erschaffung, Löschung von Objekten oder
andere Aktionen an Objekten in dem System. Wie unten näher
beschrieben werden wird, werden Objekte innerhalb des Systems,
wie beispielsweise Anmerkungen, Seiten, Kommandos, unter Ver
wendung eines objekt-orientierten Systems behandelt, wobei
Hierarchien der Objekte definiert werden.
Die Kommunikation vom Objektmanager 220 zum Konferenzmana
ger 230 erfolgt über Nachrichten, welche zu dem Mehr-Punkt-
Verbindungsmanager 240 weitergeleitet werden, um Objekte zu er
schaffen, für eine Entscheidung (Arbitration) zwischen dem
Entscheider und dem Teilnehmer und zur Kommunikation mit ande
ren Teilnehmern in der Konferenz. Darüber hinaus lenkt der
Konferenzmanager 230 den Bedienerschnittstellenprozeß 210 über
Zeiger, um verschiedene Dinge auf dem Display zur Anzeige zu
bringen. Ergebnisse aus der Anzeige der Bedienerschnittstellen
funktionen werden zurück zum Konferenzmanager 230 über Nach
richten geleitet.
Der Objektmanager 220 ist ein Prozeß, welcher während der
Laufzeit dafür verantwortlich ist, sich über die während einer
Konferenz zwischen dem Teilnehmer und anderen Teilnehmern im
System verwendeten verschiedenen Objekte auf dem laufenden zu
halten. Der Objektmanager koordiniert die Treffen zwischen den
Teilnehmern. Der Objektmanager verfolgt sämtliche Objekte, die
während des Treffens erschaffen wurden, einschließlich anderen
Teilnehmern, den verschiedenen während der Konferenz angezeig
ten Dingen und anderen Objekten. Zusätzlich wird der Objektma
nager verwendet, um den Status des Treffens aufrechtzuerhalten
und sämtliche anderen Teilnehmer mit dem aktuellen Teilnehmer
synchron zu halten. Der Inhalt eines Treffens kann gesichert
und von einem Massenspeicher (z. B. 107 gemäß Fig. 1b) zurückge
wonnen werden, wenn eine Konferenz verlassen bzw. ins die Konfe
renz eingetreten wird. Außerdem tauscht der Objektmanager
Inhalte von Treffen mit anderen Objektmanagern in anderen
Teilnehmern aus, um die Kopien der Treffen synchron zu halten.
Jeder Objektmanager 220 hält seine eigene lokale Kopie des
Treffens, welche ggf. der Bedienerschnittstelle 210 zur Verfü
gung gestellt wird. Der Objektmanager 220 informiert die Bedie
nerschnittstelle 210 über Änderungen von anderen Teilnehmern
des Treffens. Die Bedienerschnittstellen-Schicht 210 kann dann
die Anzeige in der angewiesenen Weise einstellen. Die Bediener
schnittstelle 210 informiert darüber hinaus den Objektmanager
über Änderungen, die der Benutzer bei dem aktuellen Treffen
durchzuführen wünscht. Der Objektmanager 220 synchronisiert
dann die Änderungen mit sämtlichen anderen an dem Treffen
teilnehmenden Objektmanagern. Der Objektmanager steuert die Be
dienerschnittstelle über Nachrichten; in der gleichen Weise
lenkt die Bedienerschnittstelle den Objektmanager, um bestimmte
Aktionen an Objekten entsprechend den unter Steuerung der
Bedienerschnittstelle 210 auf dem Display vorgenommenen Ein
stellungen auszuführen. Einen kurzen Überblick der Struktur von
Objekten in einem Ausführungsbeispiel der Erfindung wird in
Fig. 3 veranschaulicht.
Fig. 3 veranschaulicht eine allgemeine Klassifizierung der
Objekte höherer Ordnung, welche in einem Ausführungsbeispiel
der Erfindung verwendet werden. In diesem Ausführungsbeispiel
weist die Objektmanager-Klasse 300 die breiteste Klassifizie
rung der Objekte innerhalb des Systems auf. Grundsätzlich gibt
es innerhalb der Objektmanager-Klasse zwei allgemeine Bereiche,
die öffentlichen Treffen 310 und die privaten Treffen 320. Der
Objektmanager hält die Informationen, die der Benutzer in
seinen privaten Raum eingegeben hat, in der Objektklasse der
privaten Treffen 320, welche von der Objektklasse der öffentli
chen Treffen 310 unterschieden wird. Jede wird als separate
Struktur von Objekten innerhalb der Treffen-Klasse gehalten.
Folglich kann während eines in der Klasse 310 der öffentlichen
Treffen gespeicherten öffentlichen Treffens ein Benutzer in
ähnlicher Weise private Informationen 320 speichern, die eben
falls dem gleichen Treffen zugeordnet werden sollen.
Zusätzlich hält der Objektmanager 220 Informationen über
den Benutzer in Klassifizierung 330 und den Entscheider 340,
von welchem es nur einen während einer beliebigen elektroni
schen Konferenz gibt, und die anderen Teilnehmer des Treffens
in einer Teilnehmer-Klassifizierung 350. Alle diese Klassen
sind Mitglieder der Objektmanager-Klasse. Der Objektmanager 300
verfolgt die Teilnehmer in dem Treffen, so daß, wenn neue
Teilnehmer in das Treffen eintreten, die Treffen-Kopien der
neuen Teilnehmer in Synchronisation mit denen sämtlicher ande
rer Teilnehmer gebracht werden. Wenn Teilnehmer das Treffen
verlassen, wird sichergestellt, daß sämtliche Beiträge der
Benutzer geteilt sind, bevor der Teilnehmer das Treffen ver
läßt.
Einer der Teilnehmer des Treffens ist als Entscheider
(Arbitrator) bekannt. Dieser wir in der Entscheider-Klasse 340
repräsentiert. Der Entscheider löst Konflikte zwischen den
Benutzern, wenn Fragen der Steuerung von Eigenschaften des
Treffens auftreten. Der Entscheider bestimmt, welcher Teilneh
mer eine Anmerkung steuert, wieviele Seiten im aktuellen Tref
fen existieren usw. Er hält darüber hinaus eine Master-Kopie
des Treffens, zu der sich sämtliche anderen Teilnehmer synchro
nisieren. Die Objektmanager innerhalb jedes Teilnehmers koordi
nieren, wo der Entscheider sich befindet und weisen einen neuen
Entscheider zu, wenn der zugewiesene Entscheider das Treffen
verläßt, oder wenn es von anderen Konferenzereignissen vorgege
ben wird. Andere Konferenzereignisse sind beispielsweise das
öffnen/Verschmelzen einer Treffen-Datei, in welcher der die
Treffen-Datei öffnende/verschmelzende Teilnehmer vor dem Öff
nen/Verschmelzen der Datei der Entscheider geworden war. Bei
einer Implementierung der Erfindung wird dem Benutzer, der als
erster ein Treffen startet, die Entscheider-Funktionen zugewie
sen.
Eine sehr grobe Näherung der Arten von Objekten, welche auf
einem Teilnehmer-Display vorhanden sein können, ist in Fig. 4
veranschaulicht. Grundsätzlich hat ein Benutzer einen Treffen-
Bereich 400 auf seinem Display, in welchen verschiedene Infor
mationen eingegeben werden können. Typischerweise weist jedes
Treffen eine Serie von Seiten auf, wobei die Seiten analog
einer einzigen weißen Tafel oder gemeinsamen Display-Flächen
sind, auf welche Benutzer in einem Raum zugreifen könnten. In
analoger Weise verwendet ein Ausführungsbeispiel der Erfindung
die Notebook-Metapher, welche in Wirklichkeit ein "Notebook"
ist, das sich eine Mehrzahl von Teilnehmer des Treffens teilen,
und in welches jeder Teilnehmer Informationen eingeben kann.
Der gemeinsame oder geteilte Bereich bzw. das Notebook weist
eine Vielzahl von Seiten 410 auf, auf welchen Anmerkungen
gemacht werden können. Die Benutzer können nach Belieben Seiten
erschaffen oder löschen, die bestimmten Bedingungen unterworfen
sind. Bei einem Ausführungsbeispiel der Erfindung gibt es
zumindest vier Arten von Anmerkungen auf den Seiten. Die ersten
drei dieser Arten sind in Fig. 4 veranschaulicht. Beispielswei
se kann eine Seite 410 eine Zeichnungs-Anmerkung 411 enthalten,
welche typischerweise eine von einem einzigen Benutzer erschaf
fene objekt-orientierte Zeichnung ist. Solche objekt-orientier
ten Zeichnungen wie 411 weisen eine Beschreibung aus Punktposi
tionen und dazwischenliegenden Segmenten auf. Anmerkungen
können außerdem graphische Anmerkungen 412 sein, welche grund
sätzlich Bitmap-Darstellungen graphischer Abbildungsdaten sind.
Es können außerdem Text-Anmerkungen 413 auf eine Seite gesetzt
werden. Text-Anmerkungen können beliebig vom Benutzer ausge
wählt sein und dem Benutzer gestatten, die Schriftart, die
Punktgröße, den Fond und andere Formatinformationen auszuwäh
len, wie es typisch für bekannte Implementierungen ist. Eine
andere Anmerkung ist die OLE-Anmerkung, die ein Objekt-Verbin
dungs- und ein Einbettungs-Protokoll (OLE - object linking and
embedding) der Microsoft Corporation in Edmont, Washington,
verwendet. OLE-Anmerkungen können auf andere "Objekte" Bezug
nehmen, die von anderen Anwendungsprogrammen erschaffen
und/oder gehalten werden und welche mit Hilfe von OLE entweder
verbunden oder eingebettet werden können. Jede dieser Anmerkun
gen wird als Objekt unter einer "Anmerkungs"-Klassifikation ge
speichert, welche Objekten in der Seiten-Klassifikation zuge
ordnet ist. Fig. 5 veranschaulicht die Klassifizierung für
Objekte, die in einem Ausführungsbeispiel der Erfindung verwen
det werden.
Die Gesamtstruktur der Objektklassen ist in Fig. 5 veran
schaulicht. Fig. 5 enthält das Treffen-Objekt, Benutzer-, Ent
scheider-, Teilnehmer- und Anmerkungs-Objekte, welche anhand
der Fig. 3 und 4 oben erörtert und veranschaulicht wurden. In
Fig. 5 sind Beziehungen durch eine mit einem Punkt versehene
breite Linie veranschaulicht, wobei Vererbungs-Beziehungen
durch eine Pfeil spitze dargestellt sind, bei der die Richtung
der Vererbung der Orientierung der Pfeilspitze folgt. Zusätz
lich kann jede der in der Figur veranschaulichten Beziehungen
mehrfache Beziehungen anzeigen. Wenn eine Beziehung n : 1 ist,
heißt das, daß es n der Sub-Klassen-Objekte unter dem Elternob
jekt geben kann. Beispielsweise hat der CObjectManager 501
(Objekt-Manager), wie es anhand von Fig. 3 veranschaulicht und
erörtert wurde, zwei CCMeeting-Objektklassen (Treffen-Objekt
klassen) : das "öffentliche" Treffen und das "private" Treffen.
Zusätzlich sind der CCMeeting-Objektklasse 506 Teilnehmer-
Objekte CCParticipant 509 zugeordnet, wie sie als 350 in Fig. 3
gezeigt sind. Darüber hinaus nimmt die CCMeeting-Objektklassi
fizierung 506 Bezug auf das CCPage-Objekt 508 (Seiten-Objekt).
Die CCPage-Klassifizierung wird verwendet zum Definieren sämt
licher Seiten eines speziellen Treffens (Meeting). Unter der
CCPage-Klassifizierung 508 gibt es die Anmerkungs-Klassifi
zierungen (unter der Klasse CCAnnotation 532), welche mit ihren
verschiedenen Vererbungs-Beziehungen in dem unteren Abschnitt
der Darstellung gezeigt sind. Folglich kann die CCAnnotation-
Klassifizierung 532 Objekte enthalten, die sämtliche Beziehun
gen der Anmerkungs-Objekte erben, wobei die Anmerkungs-Objekte
für Text-Anmerkungen in Klasse CCTextAnnotation 521 enthalten
sind, für die Darstellung von Graphik oder Bitmap-Anmerkungen
(wie beispielsweise 412 in Fig. 4) in CCGraphicAnnotation 522
und für die Bezugnahme auf Zeichnungs-Anmerkungen (wie bei
spielsweise 411 in Fig. 4) in der CCDrawAnnotation-Klasse 523).
Eine andere Anmerkung, die in einem Ausführungsbeispiel der Er
findung verwendet werden kann, ist die CCOLEAnnotation-Klasse
520, welche Teil der COLEDocument-Klassifizierung 503 zum
Ausführen einer Objekt-Verbindung und -Einbettung mit Hilfe des
von Microsoft erhältlichen OLE-Protokolls ist. Anmerkungen
können somit Bezugnahmen sein auf "Objekte", die von anderen
Anwendungsprogrammen erschaffen und/oder gehalten werden und
welche mit Hilfe von OLE entweder verbunden oder eingebettet
sein können.
Es sind andere Klassifizierungen vom Objekt-Manager, Klas
sifizierung 501, erhältlich, wie beispielsweise die Klassifi
zierung CCPerson 512, welche eine Klassifizierung CCPassword
510 zum Zuordnen von Benutzer-Passworten zu Personen-Objekten
zugeordnet ist. Außerdem hat jede Person eine zugeordnete
Klasse CCAddress 513 und eine Klasse CCPhone 514 zum Definieren
von Netzwerk - Teilnehmeradressen und/oder Zugriffstelefonnum
mern.
Schließlich enthält der verbleibende Satz von in Fig. 5 ge
zeigten Objektklassen die Objekt-Klassifizierung CCCachableBLOB
515 (Cache-speicherbares großes binäres Objekt) und die Klasse
CCBLOB 516 (BLOB - binary large object - großes binäres Ob
jekt), welche eine Beziehung hat zu und Charakteristiken erbt
von der Anmerkungs-Objektklassifizierung 532 und der CCCacha
bleBLOB-Objektklassifizierung 515. Die CCBLOB 516 wird zum Dar
stellen sehr großer Objekte in verschiedenen Ausführungsbei
spielen der Erfindung verwendet. Verschiedene Ausführungsbei
spiele der Erfindung erlauben sehr große binäre Objekte, die
als Binary Large Objects oder BLOBs bekannt sind, und welche
von einem beliebigen Datentyp sein können. Diese sehr großen
binären Objekte können ebenfalls geteilt und unter den Benut
zern verteilt sein. Darüberhinaus ist bei verschiedenen Ausfüh
rungsbeispielen der Erfindung eine Übertragung solcher Objekte
nur gestattet bei Anforderung von speziellen Benutzern und/oder
wenn der Verkehr auf dem Medium es erlaubt. Auf diese Weise
wird das Kommunikationsmedium nicht mit der Aufgabe der Über
tragung dieser sehr großen binären Objekte belastet, soweit
dies nicht unbedingt erforderlich ist. Sehr große binäre Objek
te oder BLOBs können zur Darstellung eines beliebigen Informa
tionstyps verwendet werden; in bestimmten Ausführungsbeispielen
jedoch können sie nur verwendet werden zum Darstellen großer
Bitmap-Dateien oder anderer graphischer Abbildungsdaten, wie
beispielsweise komprimierter Trickfilme oder Audioinformationen
(beispielsweise dargestellt in MPED(Motion Picture Experts
Group)-Format oder im JPED(Joint Photographers Experts Group)-
Format). In alternativen Ausführungsbeispielen wird angenommen,
daß andere binäre Daten, einschließlich ausführbarer Programm
daten, mit Hilfe dieser Techniken übertragen werden können.
Wie bereits erörtert wurde, hält jeder der Konferenzteil
nehmer seine eigenen den aktuellen Zustand des Displays des ge
teilten Notebooks betreffenden Daten für sämtliche Benutzer in
der Konferenz. Auf diese Weise ist kein einzelner Teilnehmer
für die Anzeige seiner eigenen Informationen abhängig von einem
Zugriff auf einen zentralen Server. Jedoch hält ein spezieller
als "Entscheider" bekannter Teilnehmer der Konferenz eine
"offizielle" Version eines Treffens (Meetings). Alle anderen
Teilnehmer müssen ihre Versionen synchron mit der offiziellen
Kopie des Entscheiders halten. Ein zweiter Teilnehmer kann
Entscheider werden entweder, wenn er es selbst anfordert, oder,
wenn der aktuelle Entscheider die Teilnahme an der Konferenz zu
beenden wünscht. In diesem Fall werden auch sämtliche anderen
Teilnehmer über die Änderung informiert, und ein neuer Ent
scheider kann seine Funktion aufnehmen. In einem Ausführungs
beispiel der Erfindung ist der Entscheider einer Konferenz der
ursprüngliche Teilnehmer, der das Treffen begann.
Der Entscheider agiert außerdem als zentrales System, bei
welchem Anmerkungen in der offiziellen Kopie der Treffen-Struk
tur bestätigt werden. Obwohl Benutzer Änderungen an ihren eige
nen lokalen Kopien der Treffen-Struktur in Echtzeit vornehmen
können, ohne von dem Entscheider ermächtigt zu sein, muß der
Entscheider eine abschließende Entscheidung über die Position
bestimmter Anmerkungen fällen, damit das Treffen in sämtlichen
Teilnehmern übereinstimmend gehalten wird. Daß es einem einzel
nen Teilnehmer gestattet ist, seine Treffen-Struktur ohne Au
torisierung durch den Entscheider zu modifizieren, und die spä
tere Synchronisation der Treffen-Struktur mit den anderen Teil
nehmern der Konferenz wird im folgenden als aufgeschobene Syn
chronisation bezeichnet.
Jedem Seiten- und Anmerkungs-Klassenobjekt der Treffen-
Struktur ist eine Variable zugeordnet, die anzeigt, ob die
Seite oder Anmerkung mit anderen Teilnehmern der Konferenz syn
chronisiert worden ist. Diese Variable ist als "Blockiert"-Flag
bekannt, und dieses Flag wird auf "wahr" gesetzt, bis das
Seiten- oder Anmerkungs-Objekt mit anderen Teilnehmern synchro
nisiert worden ist. Zusätzlich hält und gewährt der Entscheider
Objekt-Indizes auf neue Objekte, wenn diese von einem bestimm
ten Teilnehmer geschaffen und/oder modifiziert worden sind, wo
durch das gesamte Treffen unter sämtlichen Teilnehmern synchron
gehalten wird. Der Teilnehmer, der dann die Hinzufügung
und/oder Modifikation von Objekten anfordert, empfängt Nach
richten von dem Entscheider, die einen neuen Objekt-Index an
zeigen, so daß der Teilnehmer seine lokale Treffen-Struktur ak
tualisieren kann, um den restlichen Teilnehmern des Treffens zu
entsprechen. Zusätzlich wird das Blockiert-Flag dann auf
"falsch" geändert, um anzuzeigen, daß die fraglichen Objekte
jetzt synchronisiert sind und keine weitere Kommunikation mit
dem Entscheider gegenwärtig ausgeführt zu werden braucht.
Beispielsweise kann ein Teilnehmer beschließen, eine An
merkung zu einer existierenden Seite hinzuzufügen. Der Bedie
nerschnittstellenprozeß 210 erfaßt diese Anforderung und sendet
eine Nachricht zum Objekt-Manager 220, um die Anmerkung hinzu
zufügen. Dann wird vom Objekt-Manager 220 des anfordernden
Teilnehmers eine Anforderung zum Objekt-Manager des Entschei
ders gesendet. Außerdem fügt der Objekt-Manager seiner lokalen
Treffen-Strukur ein Objekt hinzu, bei dem das Flag anzeigt, daß
die Anmerkung "blockiert" ist bzw. daß das Objekt nicht mit an
deren Teilnehmern des Treffens synchronisiert worden ist. Au
ßerdem hat der Teilnehmer bei seiner Kommunikation mit dem Ent
scheider seinen Teilnehmer-Index und eine Anforderung nach
einem Objekt-Index dem Entscheider angezeigt. Dann kann der Be
nutzer des Teilnehmers die Arbeit an der Anmerkung fortsetzen,
bis der Objekt-Index von dem Entscheider zurückgegeben wird.
Sobald der Objekt-Index empfangen worden ist, kann der Teilneh
mer seine Treffen-Struktur aktualisieren, um dem vom Entschei
der empfangenen Index zu entsprechen. Eine detailliertere Erör
terung dessen wird unter Bezugnahme auf die Fig. 6a bis 7e dis
kutiert.
Die Fig. 6a und 6b veranschaulichen detailliert einen Pro
zeß 600, welcher bei der Erfassung einer Anforderung zum Aus
führen eines eine Synchronisation mit anderen Teilnehmern eines
Treffens erfordernden Kommandos innerhalb der Ereignisschleife
des Konferenz-Managers ausgeführt wird. Folglich kann in den
Prozeß 600 eingetreten werden bei Erfassung einer Erschaffung
eines neuen Objekts, einer Modifikation eines existierenden Ob
jekts oder der Löschung eines Objekts von der Bedienerschnitt
stelle 210. Der Prozeß 600 startet am Prozeßeintrittspunkt 601.
Dann wird festgestellt, ob das Kommando ein Kommando ist,
welches eine aufgeschobene Entscheidung erfordert (Schritt
602). Wenn dies nicht der Fall ist, dann wird die aktuelle
Operation mit der normalen Kommunikation und der ggf. vorhande
nen zugeordneten Verzögerung zwischen dem aktuellen Teilnehmer
und irgendwelchen anderen Teilnehmern der Konferenz ausgeführt
(Schritt 613). Der Prozeß 600 endet am Prozeßaustrittpunkt.
Wenn jedoch das Kommando eine aufgeschobene Entscheidung
erfordert, daß heißt, die Zeitanforderungen für die Synchroni
sierung des Treffens entspannt sind und der Benutzer irgendwel
che Modifikationen an der lokalen Treffen-Struktur ohne die von
der Synchronisierung mit anderen Teilnehmern hervorgerufene
Verzögerung vornehmen kann, so wird der Prozeß am Schritt 603
fortgesetzt. Im Schritt 603 wird festgestellt, ob das aktuelle
Kommando die Änderung eines Objekts bewirken soll, welches be
reits "blockiert" ist. Ein Objekt ist nur dann als "blockiert"
gekennzeichnet, wenn festgestellt worden ist, daß das Objekt
zuvor modifiziert, gelöscht oder hinzugefügt und noch nicht mit
anderen Teilnehmern der Konferenz synchronisiert worden ist.
Dieses Flag wird, wie bereits erörtert wurde, nur bei Erfassung
einer Änderung, aber vor der Zuweisung eines Objekt-Index durch
den Entscheider gesetzt. Wenn das Objekt nicht blockiert ist
(zum Beispiel wenn dies eine anfängliche Aktion an dem Objekt
ist), dann wird im Schritt 604 festgestellt, ob die Anforderung
sich auf ein Löschen des Objekts richtet. Die Löschung
erfordert eine spezielle Serie von Schritten, da der Besitz von
sämtlichen Objekten, die gelöscht werden sollen, vor
irgendeiner Löschung erlangt werden muß. Dieser Prozeß erfor
dert außerdem die Kommunikation mit anderen Teilnehmern in der
Konferenz, wie es in Fig. 6b gezeigt ist. Zunächst wird im
Schritt 614 festgestellt, ob der Besitz des Objekts erlangt
worden ist. Dies schließt den Besitz sämtlicher Objekte und Un
ter-Objekte ein. Wenn dies nicht der Fall ist, dann wird ein
solcher Besitz von den jeweiligen Besitzern der Objekte im
Schritt 615 angefordert. Wenn der Besitz gewährt worden ist,
wie dies im Schritt 616 erfaßt worden ist, oder der Besitz des
Objekts bereits erlangt worden ist, wie es im Schritt 614
erfaßt worden ist, dann kann der Prozeß zurückkehren zum
Schritt 605, der in Fig. 6a veranschaulicht ist. Wenn der
Besitz nicht gewährt wird, dann mißlingt die Löschung, wie es
im Schritt 617 angezeigt ist, und der Prozeß kehrt zum Prozeß
austrittspunkt 620 zurück.
Am Schritt 605 wurde nun festgestellt, daß das Objekt nicht
zuvor "blockiert" worden ist, daß heißt zuvor synchronisiert
worden ist, und daß jetzt einige Arten von Änderungen an dem
Objekt auftreten. Wenn dies auftritt, muß eine Anforderung zum
Anfordern eines Objekt-Index für das Objekt gesendet werden,
damit der Teilnehmer mit sämtlichen anderen Teilnehmern syn
chronisiert werden kann. Jedoch kann der Benutzer selbst vor
dem Empfang des Objekt-Index von dem Entscheider fortfahren,
Änderungen und andere Operationen auszuführen. Die Änderungen
sind folglich nur lokal bis zur späteren Synchronisation der
Treffen-Struktur des anfordernden Teilnehmers mit anderen
Teilnehmern. Im Schritt 606 werden die von dem Benutzer ange
forderten Änderungen nur lokal ausgeführt, wobei alle Änderun
gen an der Treffen-Struktur ausgeführt werden, welche zulässig
sind, und in Schritt 607 werden die Änderungen als blockiert
angezeigt. Dann kann dieser Sub-Prozeß innerhalb der Ereignis
schleife am Prozeßaustrittspunkt 620 verlassen werden.
Für blockierte Objekte, für welche Kommandos empfangen
worden sind, wird der Prozeß 600 durch die anfänglichen Schrit
te 601, 602 und 603 fortgesetzt. Wenn das Objekt als
"blockiert" erfaßt worden ist, dann ist eine Anforderung nach
einem Objekt-Index an den Entscheider gesendet worden; wenn je
doch noch keine Antwort empfangen worden ist, fährt der Prozeß
am Schritt 609 fort. Schritt 609 erfaßt, ob die den Objekt-
Index enthaltende Antwort von dem Entscheider empfangen worden
ist. Wenn dies nicht der Fall ist, wird der Prozeß mit den
Schritten 606, 607 und 620 fortgesetzt, wie es bereits erörtert
wurde. Das heißt, die Änderungen werden weiterhin lokal ausge
führt und irgendwelche Änderungen als blockiert angezeigt, bis
die Synchronisation mit dem Entscheider und somit mit den
anderen Teilnehmern eingetreten ist.
Wenn jedoch eine Antwort von dem Entscheider empfangen wor
den ist, dann wird am Schritt 610 der Objekt-Index empfangen.
Dann kann der Teilnehmer seine lokale Treffen-Struktur im
Schritt 611 aktualisieren, um den Teilnehmer synchron mit dem
Entscheider (und somit mit den anderen Teilnehmern des Tref
fens) zu machen. Darüber hinaus wird die Bedienerschnittstel
len-Schicht 210 (Human Interface (HI) Layer) über dieses Ereig
nis informiert, damit der Teilnehmer sein Display aktualisieren
kann. Wenn beispielsweise eine Seite von dem Teilnehmer
hinzugefügt worden ist, welcher der lokale Teilnehmer Seite 4
zugewiesen hat, aber der Entscheider nun Seite 5 zuweist, so
erfaßt die Bedienerschnittstellenschicht 210 diese Änderung und
aktualisiert die Anzeige entsprechend, um die Seite visuell auf
Seite 5 zu bringen. Beispielsweise kann in der auf der Anzeige
gezeigten Notebook-Metapher ein neuer Seiten-"Anhänger" (page
tap) für die Seite mit Hilfe bekannter Benutzerschnittstellen-
Kommandos erstellt werden, um einen neuen mit "Seite 5" gekenn
zeichneten Seiten-Anhänger der lokal erschaffenen Seite zuzu
ordnen. Nachdem dann seine eigene lokale Treffen-Struktur und
Anzeige im Schritt 611 modifiziert worden sind, sendet der
Teilnehmer die gegebenenfalls vorhandenen blockierten Änderun
gen, d. h. geänderte Seiten oder Anmerkungen, zu den anderen
Teilnehmern der Konferenz aus (Schritt 612), wie sie von den
Teilnehmern angefordert werden. Folglich ist keiner der anderen
Teilnehmer mit dem aktuellen Teilnehmer bis zu diesem Zeitpunkt
synchron. Sobald dies ausgeführt ist, können die anderen Teil
nehmer der Konferenz ebenfalls ihre eigenen lokalen Treffen-
Strukturen und zugeordneten Anzeigen mit den geeigneten Seiten
und Anmerkungen aktualisieren, um synchron mit dem die Änderun
gen ausführenden Teilnehmer zu sein. Schließlich kann die
aktuelle Operation mit normaler Kommunikation im Schritt 613
ausgeführt werden, womit sämtliche Teilnehmer der Konferenz
synchron gemacht werden. Der Prozeß endet am Prozeßaustritts
punkt 620.
Eine einfache Veranschaulichung einer lokalen Treffen-
Struktur und einer Treffen-Struktur eines Entscheiders läßt
sich anhand der Fig. 7a bis 7e vornehmen, die die Hinzufügung
eines Objekts während verschiedener Schritte des in den Fig. 6a
und 6b veranschaulichten Prozesses 600 zeigen. Beispielsweise
kann zum in Fig. 7a dargestellten Zeitpunkt t₁ ein einzelner
Teilnehmer drei Elemente 701 bis 703 in seiner Treffen-Struktur
haben, die in einer hierarchischen Weise miteinander verbunden
sind (z. B. eine Liste von Anmerkungen oder eine Liste von
Seiten). In gleicher Weise kann ein Entscheider-Teilnehmer
ebenfalls drei Objekte 711 bis 713 in seiner Treffen-Struktur
haben, wobei sämtliche Objekte in beiden Teilnehmern nicht
blockiert sind. Zu einem zweiten in Fig. 7b dargestellten
Zeitpunkt t₂ kann der Teilnehmer ein zusätzliches Objekt O₄
704, wie beispielsweise eine Seite oder Anmerkung, erschaffen,
um es zu seiner lokalen Treffen-Struktur hinzuzufügen. Gleich
zeitig kann der Entscheider eine Anforderung von einem zweiten
Teilnehmer zum Hinzufügen eines Objekts O′₄ 714 zu seiner
Treffen-Struktur infolge eines Anforderung-zum-Hinzufügen-
Kommandos empfangen. Dann haben nachfolgend zum Zeitpunkt t₃
der Entscheider und der Teilnehmer jeweils innerhalb ihrer
lokalen Treffen-Strukturen ein unterschiedliches Objekt, das
den gleichen Objekt-Index 4 hat. Beispielsweise hat der Teil
nehmer das Objekt 704 als viertes Objekt in seiner Treffen-
Struktur und der Entscheider hat das Objekt 714 als viertes Ob
jekt in seiner Treffen-Struktur. Dann sendet zu einem nachfol
genden Zeitpunkt t₄ der Teilnehmer eine Anforderung an den
Entscheider, die das Hinzufügen eines zusätzlichen Objekts zu
der von dem Entscheider gehaltenen "offiziellen" Objekt-Struk
tur anfordert. Dies ist als Block 715 in Fig. 7b dargestellt.
Weil sämtliche Anforderungen von jedem der Teilnehmer der
Konferenz bei dem Entscheider aneinandergereiht werden, ist die
Anforderung zum Hinzufügen des Objekts 715 von dem ersten
Teilnehmer später angekommen als die Anforderung für das Objekt
714. Somit wird diesem Objekt ein Objekt-Index 5 zugewiesen.
Der Entscheider sendet dann den Index 5 zu dem anfordernden
Teilnehmer zurück, damit dieser dort dem Objekt zugeordnet
wird. Der Entscheider sendet dann eine Antwort zurück, die
anzeigt, daß dem Objekt 704 anstelle der 4 der Objekt-Index 5
zugewiesen werden soll. Ein anderer Teilnehmer sendet dann ein
neues Objekt O′₄ 705 zurück, das in die Objektliste des lokalen
Teilnehmers eingefügt werden soll. Somit können zu einem nach
folgenden in Fig. 7e dargestellten Zeitpunkt t₅ sowohl die
Treffen-Struktur des Entscheiders als auch die Treffen-Struktur
des Original-Teilnehmers vollständig miteinander und anderen
Teilnehmern in der Konferenz synchronisiert werden. D.h.,
sämtliche Objekte in der Treffen-Struktur des Teilnehmers und
der Treffen-Struktur des Entscheiders sind gleich und in der
gleichen Reihenfolge.
Folglich bringt die aufgeschobene Synchronisation von Ob
jekten für Teilnehmer in einer elektronischen Konferenz sub
stantielle Vorteile gegenüber dem bekannten Client-Server-
Modell, weil zeitliche Anforderungen zwischen Client und Server
gemindert werden. Weil die vollständige Konsistenz zwischen den
Teilnehmern aufgeschoben wird, können die lokalen Teilnehmer
solche CPU-intensiven Operationen, wie die Modifikation und Er
zeugung von Anmerkungen in Echtzeit, ohne die Verzögerung
aufgrund der Koordination solcher Operationen mit dem Server
ausführen. Ein weiterer Vorteil der aufgeschobenen Synchronisa
tion von Objekten gegenüber dem bekannten Client-Server-Modell
ist der, daß die Synchronisation von Objekten für sämtliche
Teilnehmer ohne die Verwendung einer zentralen Datenverwahrung,
wie sie bei dem Client-Server-Modell üblich ist, erfolgt. Dies
ist ein wesentlicher Vorteil, weil das Computerkonferenzsystem
zwischen Personalcomputern verwendet werden kann, wo ein Netz
werk-Client-Server-Modell nicht verfügbar oder praktikabel ist.
Der lokale Teilnehmer führt sämtliche dieser Änderungen auf
seinem lokalen Display und in seiner Treffen-Struktur aus, und
Aktualisierungen werden nur bei Empfang einer Antwort von dem
einen Objekt-Index zuweisenden Entscheider koordiniert. Folg
lich hat die Erfindung wesentliche Vorteile gegenüber bekannten
Systemen, welche eine vollständige Synchronisation zu sämtli
chen Zeitpunkten zwischen sämtlichen Teilnehmern der Konferenz
erfordern und somit eine wesentliche Verzögerung für eine
Synchronisation und eine Antwortverzögerung in der Benutzer
schnittstelle zu dem System auf sich laden.
Eine Objektdatenart, welche zwischen Teilnehmern in einer
elektronischen Konferenz übertragen werden kann, ist als großes
binäres Objekt oder "BLOB" (Binary Large Object) bekannt. Ein
BLOB ist ein Objekt, welches normalerweise nicht während eines
vollständigen Leer-Zyklus des Teilnehmers und des Transportme
diums übertragen werden kann. Folglich muß ein solches Objekt
in kleinere Abschnitte oder Pakete zerteilt und in verschiede
nen Leer-Zyklen von einer Hintergrund-Task übertragen werden.
BLOBs weisen typischerweise Elemente, wie beispielsweise sehr
große Graphiken, OLE-Anmerkungen oder zu übertragene Dateien
auf. In anderen Ausführungsbeispielen der Erfindung können
solche BLOBs Voll-Bewegungs-Videoobjekte, wie beispielsweise
MTEG- oder JPEG-Dateien, und/oder Audiodaten enthalten. Mit
Hilfe der beschriebenen Verfahren und Einrichtungen werden die
BLOB-Daten in Paketen übertragen, wobei die Größe jedes dieser
Pakete dynamisch der Fähigkeit und Kapazität des Transportmedi
ums angepaßt wird, welche sich dynamisch in dem Maße ändert,
wie sich die Verbindung zwischen den Teilnehmern ändert. Wenn
sich folglich die Geschwindigkeit des Transportmediums der
Verbindung zwischen zwei Teilnehmern ändert, wird die Größe der
übertragenen Pakete von dem Sender geändert. Dies erfolgt
dynamisch während der Übertragungszeit, um die effektivste
Verwendung des Transportmediums während der Übertragung von
BLOBs zu ermöglichen. Zusätzlich werden BLOB-Übertragungsanfor
derungen in Warteschlangen eingereiht, so daß BLOBs höherer
Priorität vor BLOBs geringerer Priorität übertragen werden
können. Auf diese Weise wird, wenn ein Teilnehmer, der eine er
ste Seite mit BLOB-Daten gesehen hat, umschaltet auf eine
zweite ebenfalls BLOB-Daten enthaltende Seite, die zweite
Seite, welche zu der aktuell zu sehenden Seite wird, innerhalb
des Senders umpriorisiert, damit das BLOB vor dem BLOB der
ersten Seite übertragen werden. Dies erfolgt mit Hilfe einer
Umpriorisierungsanforderung von dem Anforderer. Dann wird die
Warteschlange der hinausgehenden Übertragung von dem Sender um
arrangiert, um die gewünschte Änderung der Übertragungspriori
tät zu bewirken. Die Details dieses Mechanismus werden im
folgenden erörtert.
Zunächst müssen während einer typischen elektronischen Kon
ferenz BLOB-Daten nicht notwendigerweise bei ihrer Erschaffung
innerhalb eines lokalen Teilnehmers zu anderen Teilnehmern
übertragen werden. Mit anderen Worten, die Übertragung von
Daten für ein BLOB kann aufgeschoben werden bis zu einem späte
ren Zeitpunkt, zu welchem das Transportmedium frei ist und der
lokale Teilnehmer etwas freie Verarbeitungszeit hat. Folglich
können während der Erschaffung eines BLOB ferne Teilnehmer
darüber informiert werden, daß die BLOB-Daten nicht innerhalb
des zu erschaffenden BLOBs enthalten sind, und daß die fernen
Teilnehmer nur das Objekt ohne irgendwelche Daten in ihren
lokalen Treffen-Strukturen erschaffen. Während späterer Leer-
Perioden entweder des lokalen Teilnehmers und/oder der fernen
Teilnehmer können die BLOB-Daten selbst, die in dem BLOB-Objekt
der Treffen-Struktur der fernen Teilnehmer enthalten sein
sollen, hinzugefügt werden. Ein typischer Ablauf von Aktionen,
welche während einer BLOB-Erschaffung und Übertragung ausge
führt werden, wird anhand von Fig. 8 erläutert.
Fig. 8 veranschaulicht die Reihenfolge der von einem loka
len und einem fernen Teilnehmer einer Konferenz unternommenen
Schritte. Beispielsweise kann in einem ersten Schritt 801 ein
lokaler Teilnehmer ein ein BLOB-enthaltendes Objekt zu seiner
lokalen Treffen-Struktur hinzufügen. Der in dem lokalen Teil
nehmer enthaltende Objekt-Manager 230 benachrichtigt dann
sämtliche fernen Teilnehmer, daß sie ebenfalls ein Objekt für
ein BLOB in ihren lokalen Treffen-Strukturen schaffen sollen
(Schritt 802). Dies wird selbstverständlich nach der erforder
lichen, oben anhand des aufgeschobenen Synchronisationsprozes
ses beschriebenen Synchronisation einschließlich der Bestimmung
des Objekt-Index und anderer relevanter Informationen für ein
Objekt ausgeführt. Dann legt jeder der fernen Teilnehmer indi
viduell asynchrone Anforderungen nach BLOB-Daten an den lokalen
Teilnehmer an (Schritt 803). Der lokale Teilnehmer verarbeitet
dann in Schritt 805 die Anforderungen nach BLOB-Daten, indem er
die Anforderungen in eine BLOB-Anforderungswarteschlange
einreiht und später die Daten während freier Zeiten zur
Verfügung stellt. Im Anschluß an die asynchronen Anforderungen
von verschiedenen Teilnehmern nach BLOB-Daten in Schritt 803
können die fernen Teilnehmer darüber hinaus Umpriorisierungen
früherer Anforderungen nach BLOB-Daten anlegen (Schritt 804).
Mit anderen Worten, wenn ein ferner Teilnehmer zunächst BLOB1
angefordert hat und dann später nachfolgend BLOB2 anfordert,
können die beiden Anforderungen so umpriorisiert werden, daß
BLOB2 eine höhere Priorität für den fernen Teilnehmer einnimmt
als BLOB1. Wenn der ferne Teilnehmer von einer das erste BLOB1
enthaltenden Seite zu einer das zweite BLOB2 enthaltenden Seite
umschaltet, wird der lokale Teilnehmer auf diese Weise dann die
BLOB-Anforderungen für den speziellen Teilnehmer umordnen.
Wie bereits erörtert, verarbeitet der lokale Teilnehmer die
Anforderungen nach den BLOB-Daten im Schritt 805. Dies wird de
taillierter anhand von Fig. 9 erörtert. Der lokale Teilnehmer
sendet dann zu jedem der entfernten Teilnehmer die angeforder
ten BLOB-Datenpakete (Schritt 806). Wie unten näher erörtert
werden wird, werden die BLOB-Datenpakete entsprechend dem
Transportmedium zwischen den zwei Teilnehmern gesendet. Wenn
der ferne Teilnehmer mit einem Transportmedium hoher Kapazität
und hoher Geschwindigkeit, wie beispielsweise einem Ethernet,
verbunden ist, dann wird die Größe der Datenpakete wesentlich
größer gewählt, als wenn der Teilnehmer über ein Modem und eine
Telefonleitung verbunden ist. Wenn der lokale Teilnehmer die
BLOB-Datenpakete im Schritt 806 sendet, empfängt jeder der
fernen Teilnehmer die BLOB-Daten und fügt die BLOB-Datenpakete
der existierenden BLOB-Datenstruktur hinzu. Nach Abschluß der
Übertragung sämtlicher BLOB-Datenpakete der angeforderten BLOB
entfernen die lokalen Teilnehmer die BLOB-Anforderung aus der
Anforderungs-Warteschlange im Schritt 807. Der Bedienerschnitt
stellenprozeß des fernen Teilnehmers wird informiert, um die
Anzeige des zuvor unvollständigen ein BLOB enthaltenen Objekts
zu aktualisieren. Im folgenden werden einige der Prozeßschritte
näher erläutert.
Prozeß 900 gemäß Fig. 9 enthält eine Reihe von Schritten,
welche von einem lokalen Teilnehmer bei Empfang einer von einem
fernen Teilnehmer übertragenen Anforderung nach BLOB-Daten
ausgeführt werden. Im Schritt 901 wird in einen Prozeßein
trittspunkt eingetreten. D.h., mehrere neue Anforderungen und
Umpriorisierungsanforderungen können von mehreren Teilnehmern
asynchron empfangen werden. Dann wird im Schritt 902 der Trans
portqualifizierer für die neue Anforderung oder für eine Um
priorisierungsanforderung bestimmt. D.h., es wird festgestellt,
ob das Transportmedium für den fernen Teilnehmer entweder ein
Hochgeschwindigkeitstransportmedium oder ein Transportmedium
niedriger Geschwindigkeit ist. Die Bestimmung der Fähigkeit des
Mediums (hohe oder niedrige Geschwindigkeit) wird bei der
Betrachtung der Kombination von Anforderungen von mehreren
Teilnehmern als eine Qualifikation verwendet. Wie unten näher
erörtert werden wird, wird während der Übertragung eines BLOB
für jedes BLOB in der Übertragungswarteschlange eine Größe
(SIZE) und ein Offset (OFFSET) für jeden Übertragungswarte
schlangeneintrag gehalten, so daß auf das letzte Datum in dem
BLOB, welches übertragen wurde, Bezug genommen werden kann.
Mehrere Anforderungen können in einem Warteschlangeneintrag
kombiniert werden, und in gleicher Weise mehrere einfach Warte
schlangeneinträge umpriorisierende Umpriorisierungsanforderun
gen. Folglich ist bei einer anfänglichen Anforderung nach BLOB-
Daten das Offset gleich Null, d. h. auf den Anfang des BLOB
gesetzt, und die Größe ist gleich der vollen Länge des BLOB ge
setzt. Detailliertere Schritte zum Bestimmen des Transportqua
lifizierers werden unter Bezugnahme auf den Proßez 1000 gemäß
Fig. 10 beschrieben. Ein Beispiel des Umpriorisierungsprozesses
wird in Verbindung mit Fig. 17 beschrieben.
Sobald der Transportqualifizierer bestimmt worden ist, wird
im Schritt 903 festgestellt, ob eine existierende Anforderung
nach anhängigen Daten den Empfang einer Umpriorisierungsanfor
derung von einer ursprünglichen Anforderung nach BLOB-Daten an
zeigt. Wenn es eine Anforderung nach anhängigen Daten ist, dann
wird im Schritt 904 festgestellt, ob eine partielle Anforderung
erforderlich ist, d. h., wenn andere ferne Teilnehmer die glei
chen BLOB-Daten anfordern, welche bereits angefordert worden
sind und deren Übertragung bereits begonnen wurde, so können
die neuen anfordernden Teilnehmer die BLOB-Daten von dem Zeit
punkt an, zu welchem die Anforderung ausgeführt wurde, empfan
gen, aber sie fordern außerdem die Daten an, welche bis zu
diesem Zeitpunkt übertragen wurden. Somit werden redundante
Übertragungen von Daten eliminiert, indem nahezu gleichzeitige
Anforderungen von mehreren fernen Teilnehmern kombiniert wer
den. In Fällen, in denen eine einer ursprünglichen Anforderung
zugeordnete Übertragung noch nicht gestartet wurde, werden die
nachfolgend anfordernden Teilnehmer mehr oder weniger zu der
Verteilungsliste des ursprünglichen Übertragungswarteschlange
neintrags hinzugefügt. Andernfalls, wenn die Übertragung
begonnen hat, wird zusätzlich zu dem obigen ein weiterer Über
tragungswarteschlangeneintrag hinzugefügt, um die bereits
übertragenen Daten zu berücksichtigen. Wenn jedoch keine anhän
gigen Anforderungen nach den aktuellen BLOB-Daten existieren,
dann wird ein neuer Übertragungswarteschlangeneintrag in die
Übertragungswarteschlange des Teilnehmers im Schritt 905 einge
geben, um die BLOB-Übertragung auf dem laufenden zu halten. Wie
zuvor erörtert wurde, hält der Warteschlangeneintrag ein OFFSET
und ein SIZE (Größe), um die Übertragung für einzelne
Anforderungen zu verfolgen. Bei Abschluß entweder des Schritts
904 oder des Schritts 905 wird die Datenanforderungsverarbei
tung im Schritt 906 abgeschlossen, wonach eine tatsächliche
Daten-BLOB-Übertragung im Hintergrund auftritt (d. h. während
freier Verarbeitungszeit), und der Prozeß 900 kehrt zu der
normalen Ereignisschleife der Ausführungsroutine des lokalen
Teilnehmers zurück.
Eine detailliertere Beschreibung der im Schritt 902 gemäß
Fig. 9 vorgenommenen Prozeßschritte wird anhand von Fig. 10 ge
geben. Prozeß 1000 dient zum Bestimmen des Transportqualifizie
rers. Der Transportqualifizierer wird verwendet bei der Handha
bung der Kombination mehrerer Anforderungen. D. h., Anforderun
gen von über ein Hochgeschwindigkeitsmedium miteinander verbun
denen Empfängern werden nicht kombiniert mit Anforderungen von
über ein Medium geringer Geschwindigkeit verbundenen Empfängern
und umgekehrt. Dies wird dynamisch bei jeder Anforderung nach
einer Übertragung eines BLOB-Pakets während freier Verarbei
tungszeit ausgeführt. Somit wird der Transportqualifizierer für
einen bestimmten Teilnehmer verwendet, um dem Transportmedium
höherer oder geringerer Kapazität zu gestatten, angepaßt zu
werden. Zu beachten ist, daß der Transportqualifizierer irgend
eine Anzahl von Niveaus des Transportdurchsatzes spezifizieren
kann. Die Erfindung ist nicht nur auf ein hohes und ein niedri
ges Niveau begrenzt. Beispielsweise können die Transportniveaus
so spezifiziert werden, daß eine Einteilung in 4800-baud-Mo
dems, 9600-baud-Modems, ISDN-Verbindungen, schnelle und langsa
me Netzwerkverbindungen usw. entsteht.
Der Prozeß 1000 startet an einem typischen Prozeßeintritts
punkt 1001. Dann wird im Schritt 1002 festgestellt, ob eine
Hochgeschwindigkeitstransportmöglichkeit zwischen dem lokalen
und dem anfordernden Teilnehmer verfügbar ist. Wenn dies der
Fall ist, dann wird im Schritt 1003 der Hochgeschwindigkeits
qualifizierer verwendet. Wenn jedoch der ferne und der lokale
Teilnehmer über ein Transportmedium geringer Geschwindigkeit
miteinander gekoppelt sind, wie dies im Schritt 1002 festge
stellt wird, dann wird im Schritt 1004 ein Niedriggeschwindig
keitstransportqualifizierer verwendet. Im Schritt 1005 ist die
Bestimmung des Transportqualifizierers beendet und der beglei
tende Prozeß kann fortgesetzt werden.
Der Prozeß der aufgeschobenen Übertragung, welcher unter
Bezugnahme auf Schritt 904 gemäß Fig. 9 erörtert wurde, wird im
folgenden unter Bezugnahme auf den Prozeß 1100 gemäß Fig. 11
diskutiert. Beispielsweise wurde im Schritt 1101, einem typi
schen Prozeßeintrittspunkt von einer Ereignisschleife eines
ausführenden Prozesses, bereits festgestellt, daß eine existie
rende Anforderung für die speziellen BLOB-Daten anhängig ist.
Wenn eine Anforderung für den aktuellen Teilnehmer 1102 bereits
anhangig ist, dann wird diese als Umpriorisierungsanforderung
für den gegebenen Teilnehmer angesehen, und die existierende
BLOB-Anforderung in der Übertragungswarteschlange wird im
Schritt 1107 umpriorisiert. Folglich wird jede andere BLOB-
Anforderung für den bestimmten Teilnehmer umpriorisiert. Dann
ist der Prozeß im Schritt 1106 abgeschlossen und der Prozeß
1100 kehrt vom Prozeßaustrittspunkt zurück.
Wenn jedoch für diesen speziellen Teilnehmer keine Anforde
rung anhängig war, wie dies unter Bezugnahme auf den Teilneh
mer-Index für den anfordernden Teilnehmer, welcher dem Element
in der Übertragungswarteschlange zugeordnet ist, erfaßt wurde,
dann wird im Schritt 1103 der anfordernde Teilnehmer zu der
Verteilungsliste für den existierenden Übertragungswarteschlan
geneintrag hinzugefügt. Folglich kann der Teilnehmer-Index zu
dem existierenden Übertragungswarteschlangeneintrag hinzugefügt
werden. Es kann ein entsprechender Eintrag für eine partielle
Anforderung für jeden Teilnehmer in der Verteilungsliste exi
stieren, aber dies ist nicht erforderlich. Anforderungen von
mehreren Teilnehmern können vor Beginn der zugeordneten Daten
übertragung empfangen worden sein, und so existiert nur der
einzige Übertragungswarteschlangeneintrag. Sobald die Daten
übertragung beginnt, bewirken zusätzliche Anforderungen von
neuen Teilnehmern ein Kombinieren mit dem existierenden Eintrag
und das Hinzufügen eines partiellen Eintrags für den zu diesem
Zeitpunkt abgeschlossenen Teil der Datenübertragung. Wenn
folglich die Datenübertragung bereits für das spezielle BLOB,
wie es in seinem Übertragungswarteschlangeneintrag spezifiziert
ist, begonnen hat, was im Schritt 1104 festgestellt wird, dann
muß eine partielle Anforderung für den verbleibenden Teil des
BLOB in den Übertragungswarteschlangeneintrag hinzugefügt
werden. Dies wird im Schritt 1105 ausgeführt. D. h., sämtliche
dem BLOB zugeordnete und zuvor zu den anderen fernen Teilneh
mern übertragene Daten müssen für den aktuellen anfordernden
Teilnehmer nach Abschluß der gegenwärtigen Übertragung übertra
gen werden. Dies ist so, damit dieser Teilnehmer auch sein BLOB
in Übereinstimmung mit den anderen Teilnehmern der Konferenz
bringen kann. Wenn jedoch die Datenübertragung für diesen
Eintrag noch nicht begonnen hat, werden die anfordernden Teil
nehmer zu dem existierenden Übertragungswarteschlangeneintrag
in den Schritten 1103 und 1104 hinzugefügt; dann wird am
Schritt 1106, dem Prozeßaustrittspunkt fortgefahren. Im Schritt
1105 wird eine zusätzliche partielle Anforderung nach dem
Abschnitt eines existierenden zuvor übertragenen Übertragungs
eintrags der Übertragungswarteschlange hinzugefügt. Die zusätz
liche partielle Anforderung wird unter Bezugnahme auf Fig. 12
näher erläutert.
Die Vorbereitung partieller Anforderungen werden unter Be
zugnahme auf die Fig. 12a bis 12c beschrieben. Beispielsweise
können zwei Teilnehmer B und C die Übertragung eines BLOB von
38000 Bytes von einem lokalen Teilnehmer anfordern. In diesem
Fall wird das OFFSET anfänglich für die zwei Teilnehmer auf
Null gesetzt und die Größe der verbleibenden Übertragung ist
gleich 38.000. Eine gewisse Zeitdauer später, z. B. zum Zeit
punkt t₁ gemäß Fig. 12a (zu einem Zeitpunkt, zu dem die Daten
übertragung begonnen hat) ist das Übertragungs-OFFSET gleich
2000 und die verbleibende Übertragungsgröße gleich 36 000, was
anzeigt, daß 2000 Bytes Daten übertragen worden sind. Dies ist
durch die Abschnitte 1201 und 1202 der grafischen Darstellung
des BLOB′s 1200 gezeigt. Zu diesem Zeitpunkt fordert ein drit
ter Teilnehmer D, die Übertragung der gleichen BLOB-Daten von
dem lokalen Teilnehmer an. In diesem Fall wird der Teilnehmer D
zu der Verteilungsliste (des existierenden BLOB-Warteschlan
geneintrags mit dem OFFSET 2000 und der Größe (SIZE) 36.000)
hinzugefügt, und ein nachfolgendes partielles (Anforderungs-)
Übertragungswarteschlangen-Element wird zur Übertragungswarte
schlange an einer Position nach dem aktuellen Übertragungswar
teschlangeneintrag (für OFFSET Null und SIZE 2000) hinzugefügt.
Somit wird zu einem nachfolgenden Zeitpunkt t₂ (dargestellt in
Fig. 12b) der Teilnehmer D zu der existierenden Übertragungs
eintrag-Verteilungsliste hinzugefügt und die Übertragung von
dem Übertragungs-OFFSET 2000 und mit der verbleibenden Übertra
gungsgröße 36.000, die in dem BLOB-Übertragungswarteschlangen
eintrag angezeigt ist, fortgesetzt. Dies ist grafisch in Fig.
12b durch den aktuellen Abschnitt der Übertragung 1211 und den
verbleibenden Abschnitt 1212 dargestellt. Schließlich wird bei
Abschluß der Übertragung des in Fig. 12b dargestellten Elements
ein anderer Warteschlangeneintrag referenziert zum Übertragen
nur eines Abschnitts des BLOB′s, da die Anforderung des Teil
nehmers D mitten in der anfänglichen Übertragung zu den Teil
nehmern B und C empfangen wurde. An dieser Stelle hat der
nächste Übertragungseintrag zum Zeitpunkt t₃ (veranschaulicht
in Fig. 12c) ein Übertragungs-OFFSET von Null (was den Beginn
der Datei anzeigt) und eine verbleibende Übertragungsgröße von
2000 (was anzeigt, daß die ersten 2000 Bytes des BLOB für eine
Übertragung zum Teilnehmer D angefordert wurden). Dies wird
grafisch veranschaulicht durch das vollständige BLOB 1220 und
den Abschnitt 1221, welcher von diesem Warteschlangeneintragung
zur Übertragung zum Teilnehmer D angefordert wird. Sobald diese
partielle Übertragung abgeschlossen ist, haben alle Teilnehmer
B, C und D das vollständige BLOB empfangen, wobei redundante
Übertragungen der durch 1202 und 1212 dargestellten Datenab
schnitte vermieden wurde. Folglich empfängt der Teilnehmer D
nur den Abschnitt, welcher bis zu dem Zeitpunkt übertragen
worden ist, zu welchen dessen eigene Anforderung ausgeführt
wurde; d. h. den durch den Bereich 1221 gemäß Fig. 12c darge
stellten Abschnitt. Die Übertragung der Daten für den in Fig.
12c dargestellten partiellen Abschnitt erfolgt vom Ende des
partiellen Abschnitte zu dessen Anfang, so daß das BLOB in dem
Speicher des anfordernden Teilnehmers zusammenhängend gehalten
werden kann. Bei Abschluß des Empfangs des partiellen Ab
schnitts benachrichtigt der Teilnehmer D dann seine Bediener
schnittstelle, damit diese die Anzeige der Anmerkung, die das
zuvor unvollständige BLOB-Objekt enthält, aktualisieren kann.
Somit ist bei Abschluß der durch den in Fig. 12c gezeigten
Übertragungseintrag angezeigten Übertragung die Übertragung des
BLOB zu sämtlichen Teilnehmern B, C und D vollständig. Die
Übertragung zu den Teilnehmern B und C ist vollständig nach
Abschluß der dem ursprünglichen Warteschlangeneintrag zugeord
neten Übertragung. Die Übertragung zum Teilnehmer D ist zu
einem späteren Zeitpunkt vollständig, wenn der der partiellen
Anforderung zugeordnete Warteschlangeneintrag vollständig ist.
Während der Übertragungen solcher BLOB-Daten können der
entfernte Teilnehmer und der lokale Teilnehmer über solche
Operationen mit Hilfe eines fortschreitenden Balkens oder eines
anderen Benutzerschnittstellenmerkmals unter Steuerung durch
die Bedienerschnittstelle 210 des Teilnehmers während der
Leerzeiten des Teilnehmers informiert werden. Somit kann der
Benutzer über die zwischenzeitlichen Übertragungen von Daten
zum Zwecke einer geeigneten Systemrückkopplung informiert
werden.
Zu beachten ist, daß der BLOB-Datenübertragungsmechanismus
ein Klar-zum-Senden- oder CTS-Protokoll (CTS - Clear-To-Send)
verwendet, wobei dann, wenn die Übertragung von einem speziel
len Übertragungswarteschlangeneintrag zugeordneten Daten nicht
fortgesetzt werden kann, weil ein Empfänger nicht bereit-zum-
Senden ist, nachfolgende Übertragungswarteschlangeneinträge,
die keinen Empfänger enthalten, der nicht Klar-zum-Senden ist,
für eine Übertragung in Betracht gezogen werden. Dies wird
ausgeführt, um das volle Potential des Transportmediums während
Leerzeiten der einzelnen Teilnehmern zu maximieren. Das Klar-
zum-Senden-Protokoll der Erfindung wird detaillierter anhand
von Fig. 18 beschrieben.
Im folgenden wird auf Fig. 13 Bezug genommen, in der ein
Architekturdiagramm die Komponenten des Hintergrund-Übertra
gungs-Managers (BTM - Background Transfer Manager) der Erfin
dung veranschaulicht. Die Übertragung großer Daten-Objekte wird
durch den BTM gesteuert. Der BTM besteht aus sechs Hauptab
schnitten: 1) Teilnehmer-Verbindungs/Trennungs-Steuerlogik
1312, 2) Anforderungs-Verarbeitungslogik 1314, 3) Datenübertra
gungsverarbeitungslogik 1316, 4) eine Klar-zum-Senden-Liste
1318, 5) eine Liste 1320 der hinausgehenden Übertragungen und
6) eine Liste 1322 der hereinkommenden Übertragungen. Die
Logikkomponente 1312 wird anhand der Fig. 14 und 15 beschrie
ben. Die Logikkomponenten 1314 und 1316 werden in Verbindung
mit den Fig. 16 bis 20 beschrieben. Die Klar-zum-Senden-Liste
1318 wird verwendet, um den Klar-zum-Senden-Status der Anforde
rungen zu halten. Dieses Protokoll wird in Verbindung mit Fig.
18 beschrieben. Die Liste 1322 der hereinkommenden Übertragun
gen wird verwendet, um solche Einträge aufzuzeichnen, für
welche BLOB-Datenanforderungen an ferne Benutzer angelegt
worden sind. Der BTM verwendet diese Liste, wenn der Prozeß
fordert festzustellen, ob eine neue Anforderung oder eine
Umpriorisierungsanforderung gesendet werden soll. Die Liste
1320 der hinausgehenden Übertragungen wird verwendet, die
Prioritäten der hinausgehenden BLOB-Datenübertragungen zu
halten. Die Teilnehmer-Verbindungs/Verarbeitungslogik 1312
betrifft die Reinitialisierung einer Teilnehmerverbindung und
ein Löschen (flushing) von teilnehmerspezifischen Informationen
bei der Meldung einer Abkopplung eines Teilnehmers. Im folgen
den wird auf die Fig. 14 und 15 Bezug genommen, in denen Ab
laufdiagramme diese Verarbeitung der Verbindung und Trennung
dargestellt sind.
In Fig. 14 wird die Meldung einer Teilnehmerverbindung am
Block 1410 empfangen. Der neu verbundene Teilnehmer wird zu der
Klar-zum-Senden-Liste 1318 hinzugefügt (Block 1420). In Abhän
gigkeit von der Charakteristik des Tranportmediums wird der
Teilnehmer qualifiziert für eine Hochgeschwindigkeitsübertra
gung mit einer entsprechenden optimalen Paketgröße (Blöcke 1428
und 1430) oder qualifiziert für eine Übertragung geringerer Ge
schwindigkeit mit einer entsprechenden optimalen Paketgröße
(Blöcke 1434 und 1436).
In Fig. 15 wird im Block 1510 die Meldung einer Teilnehmer-
Abkopplung oder -Trennung empfangen. Die optimale Pakektgröße
wird erneut berechnet im Block 1520. Der Teilnehmer wird aus
der Klar-zum-Senden-Liste entfernt (Block 1522). Der Teilnehmer
wird aus sämtlichen Verteilungslisten für sämtliche Übertra
gungswarteschlangeneinträge entfernt (Block 1524). Übertra
gungswarteschlangeneinträge, für welche der Teilnehmer der
einzige Empfänger war, werden im Block 1526 entfernt.
Zum Zeitpunkt der Verbindung/Abkopplung eines Teilnehmers
werden optimale Übertragungsgrößen bestimmt für jede benutzte
Ebene des Transportdurchsatzes (hohe oder niedrige Geschwindig
keit). Diese Größen bleiben zwischen den Teilnehmer-Verbin
dungs- und -Trennungs-Ereignissen konstant. Anders gesagt, nur
Teilnehmer-Verbindungs- und -Trennungs-Ereignisse beeinflussen
die optimale Übertragungsgröße. Zu beachten ist, daß die opti
male Übertragungsgröße nicht eine maximale übertragbare Pa
ketgröße ist. Sie ist die optimale Größe, die gehandhabt werden
kann, um eine Partitionierung des Paketes zu verhindern. Unter
Verwendung dieser Paketgröße oder einer geringeren nehmen die
Pakete den schnellsten Pfad durch die Verarbeitungslogik sowohl
am sendenden als auch am empfangenden Ende.
Im folgenden wird wieder auf Fig. 13 Bezug genommen. Die
Anforderungs-Verarbeitungslogik 1314 wird sowohl in sendenden
als auch in empfangenden Systemen verwendet. Sowohl die Anfor
derungs-Verarbeitungslogik 1314 als auch die Datenübertragungs
logik 1316 verwenden eine Übertragungswarteschlange zum Verfol
gen des Status der BLOB-Anforderungen und BLOB-Daten. In Fig.
16 veranschaulicht ein Architekturdiagramm die Struktur eines
einzelnen Hintergrund-Übertragungs-Manager-Übertragungswarte
schlangeneintrags 1610. Der Übertragswarteschlangeneintrag 1610
weist eine Referenz zu einem einzelnen BLOB-Objekts 1612 auf,
die das von dem Übertragungswarteschlangeneintrag verfolgte
BLOB-Objekt repräsentiert. Ein Nächste-Übertragung-OFFSET 1614
und eine verbleibende Übertragungsgröße 1616 werden verwendet,
um das Voranschreiten der Übertragung von BLOB-Daten zu verfol
gen. Die Empfängerliste 1618 ist eine Liste von Teilnehmern,
die das spezielle durch die Referenz 1612 identifizierte BLOB
empfangen sollen. Der vorhergehende Übertragungswarteschlangen
eintrag 1620 und der nächste Übertragungswarteschlangeneintrag
1622 werden verwendet, um BLOB-Anforderungen miteinander in der
Übertragungswarteschlange zu verbinden.
In Fig. 19 ist die Anforderungsverarbeitungslogik 1110 für
einen anfordernden Teilnehmer veranschaulicht. Fig. 20 veran
schaulicht die Anforderungsverarbeitungslogik 2010 für einen
BLOB-Urheber. Ein BLOB-Urheber von BLOB-Daten sendet eine BLOB-
Objekt-Struktur ohne ihre entsprechenden Daten zu anderen
Teilnehmern. Diese anderen Teilnehmer werden als "Anforderer"
in bezug auf diese BLOB-Daten bezeichnet. Wie in Fig. 19 ge
zeigt ist, überprüft ein Anforderer von BLOB-Daten zunächst die
Liste 1322 der hereinkommenden Übertragungen, um festzustellen,
ob ein spezielles BLOB bereits in der Liste 1322 ist
(Entscheidungsblock 1312). Wenn dies der Fall ist, wird eine
Umpriorisierungsanforderung an den BLOB-Urheber gesendet,
wodurch die Priorität der existierenden Anforderung nach BLOB-
Daten erhöht wird (Verarbeitungsblock 1922). Wenn das BLOB
nicht bereits in der Liste 1322 der hereinkommenden Übertragun
gen ist, fügt der BLOB-Anforderer einen Übertragungswarte
schlangeneintrag der Liste 1322 der hereinkommenden Übertragun
gen hinzu (Verarbeitungsblock 1918) und sendet eine neue Anfor
derung nach BLOB-Daten an den BLOB-Urheber (Verarbeitungsblock
1920). Die Anforderungsverarbeitungslogik für einen BLOB-Anfor
derer endet dann an dem Rückkehrpunkt 1924.
Wie in Fig. 20 gezeigt ist, verarbeitet der BLOB-Urheber
dann diese Anforderung und fügt entweder einen neuen hinausge
henden Übertragungswarteschlangeneintrag hinzu
(Verarbeitungsblock 2018), umpriorisiert einen existierenden
Warteschlangeneintrag (Verarbeitungsblock 2026) oder kombiniert
die Anforderung mit einem existierenden Eintrag
(Verarbeitungsblock 1434), um die Übertragung der BLOB-Daten zu
verfolgen. Es tritt keine BLOB-Datenübertragung im Ergebnis
dieser Verarbeitung auf.
Fig. 17 veranschaulicht ein Beispiel einer Übertragungswar
teschlangenumpriorisierung. Wie dort gezeigt ist, werden BLOB-
Anforderungen zu der Übertragungswarteschlange in der empfange
nen Reihenfolge hinzugefügt (Schritte 1720 und 1730), bis eine
Umpriorisierungsanforderung empfangen wird (Schritt 1740). Am
Schritt 1740 wird die Anforderung 1 vor die Anforderung 2
bewegt. Nachfolgende Anforderungen werden zu der Übertragungs
warteschlange hinzugefügt (Schritt 1750), bis eine andere
Umpriorisierungsanforderung empfangen wird (Schritt 1760). In
diesem Fall wird die Anforderung 3 vor sowohl die Anforderung 1
als auch die Anforderung 2 bewegt. Wenn eine andere Umpriori
sierungsanforderung empfangen wird, wird die betroffene Anfor
derung (Anforderung 1 im Schritt 1770) vor die anderen Anforde
rungen in der Übertragungswarteschlange bewegt.
Es wird wieder auf Fig. 13 Bezug genommen. Die Übertra
gungsverarbeitungslogik 1316 wird während der Verarbeitungs
leerzeit verwendet. Zu diesem Zeitpunkt überprüft der BTM die
Warteschlange der aktuellen hinausgehenden Übertragungen nach
Einträgen, die eine Datenübertragung erfordern. Für diese
Einträge überprüft der BTM wiederholt, ob der Transport klar-
zum-Senden eines Pakets von optimaler Größe (wie zuvor be
stimmt) zu den Empfängern, die in dem Übertragungswarteschlan
geneintrag aufgelistet sind, ist und sendet die Pakete, wenn
klar-zum-Senden. Die Klar-zum-Senden-Liste 1318 wird verwendet,
um den Klar-zum-Senden-Status von Paketen von BLOB-Daten zu
verfolgen. Wenn sie nicht klar-zum-Senden ist, werden die
Empfänger als nicht klar-zum-Senden (NCTS) markiert, und der
BTM fährt mit dem nächsten Übertragungswarteschlangeneintrag
fort, dessen Empfängerliste keinen Empfänger enthält, der nicht
klar-zum-Senden ist, und wiederholt den Paketsendungsprozeß.
Dieser Prozeß wird fortgesetzt, bis entweder sämtliche BTM-
Einträge verarbeitet worden sind oder sämtliche Teilnehmer als
Nicht klar-zum-Senden markiert sind. An diesem Punkt wird der
Nicht-klar-zum-Senden-Status sämtlicher Teilnehmer gelöscht, um
die nächste Leerzeit-Verarbeitung vorzubereiten.
Fig. 18 veranschaulicht ein Beispiel der Klar-zum-Senden-
Verarbeitung nach der Erfindung. Bei diesem Beispiel repräsen
tiert jede Zelle bzw. jeder Kasten einen Übertragungswarte
schlangeneintrag. Die Nummern in den jeweiligen Zellen reprä
sentieren eine Eintragsnummer, die allein für Identifizierungs
zwecke verwendet wird. Die Buchstaben in jeder Zelle repräsen
tieren die Empfänger, die dem Übertragungs-Warteschlangenein
trag entsprechen. Im Anfangszustand dieses Beispiels (Schritt
1810) wird jeder Übertragungswarteschlangeneintrag (Zelle)
initialisiert und jeder Empfänger ist anfänglich klar-zum-
Senden (A-OK, B-OK und C-OK). Im Schritt 1820 werden Pakete zum
Eintrag 1 gesendet, bis der Empfänger B nicht mehr länger klar
zum-Senden ist (d. h. Nicht-klar-zum-Senden - NCTS). In diesem
Fall verschiebt die Datenübertragungsverarbeitungslogik 1316
die Datenübertragungsoperation zum Eintrag 2 (Schritt 1830). Im
Schritt 1830 werden die Pakete vom Eintrag 2 gesendet, bis der
Empfänger B nicht mehr länger klar-zum-Senden ist. Im Schritt
1840 wird der Eintrag 3 übersprungen, weil Teilnehmer B, wel
cher ein Empfänger des Eintrags 3 ist, nicht klar-zum-Senden
ist. Im Schritt 1850 werden Pakete vom Eintrag 4 gesendet, bis
Empfänger A nicht mehr länger klar-zum-Senden ist. Weil sämtli
che Einträge in der Übertragungswarteschlange im Schritt 1860
nicht klar-zum-Senden sind, endet die Datenübertragungsverar
beitung und die Verarbeitung kehrt zur Hauptschleife zurück.
Dieser Prozeß wird während jeder Leerzeit wiederholt.
Somit wurden schließlich ein verbessertes Verfahren zur
Übertragung sehr großer Daten-Objekte und die aufgeschobene
Synchronisation von Teilnehmern während einer Konferenz be
schrieben.
Claims (10)
1. Verfahren zum Übertragen von Datenblöcken großer Objekte
zwischen einer Mehrzahl von Teilnehmern in einem elektronischen
Konferenzsystem, wobei sich die Teilnehmer während einer
elektronischen Konferenz Daten teilen,
dadurch gekennzeichnet, daß
- a) eine asynchrone Anforderung nach Daten eines großen Ob jekts empfangen wird;
- b) die Anforderung in eine Anforderungswarteschlange eingereiht wird;
- c) eine asynchrone Anforderung zur Umpriorisierung der An forderungswarteschlange empfangen wird;
- d) die Fähigkeit eines Transportmediums bestimmt wird;
- e) die Daten des großen Objekts in Datenblöcke partitio niert werden, wobei die Größe der Datenblöcke variabel ist und der Fähigkeit des Transportmediums angepaßt wird;
- f) die angeforderten Daten des großen Objekts zu jedem der Teilnehmer über das Transportmedium übertragen werden;
- g) die Anforderung aus der Anforderungswarteschlange bei Abschluß der Übertragung der angeforderten Daten des großen Ob jekts entfernt wird.
2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, daß
das große Objekt ein binäres großes Objekt (BLOB - Binary Large
Object) ist.
3. Verfahren nach Anspruch 2, dadurch gekennzeichnet, daß
beim Einreihen der Anforderung in die Anforderungswarteschlange
eine Übertragungswarteschlange mit einem Eintrag für jede
Anforderung für eine Übertragung von einem oder mehreren BLOBs
aufrechterhalten wird.
4. Verfahren nach Anspruch 2 oder 3, dadurch gekennzeich
net, daß ein BLOB von einem Teilnehmer zu einem anderen Teil
nehmer nur dann übertragen wird, wenn ein Übertragungsstatus
ein Klar-zum-Senden (CTS) anzeigt.
5. Verfahren nach Anspruch 3, dadurch gekennzeichnet, daß
die Übertragungswarteschlange umpriorisiert wird, wenn eine An
forderung zur Umpriorisierung von einem Teilnehmer empfangen
wird.
6. Einrichtung zum Übertragen von Datenblöcken großer Ob
jekte zwischen mehreren Teilnehmern in einem elektronischen
Konferenzsystem, wobei sich die Teilnehmer während einer
elektronischen Konferenzsystem Daten teilen,
gekennzeichnet durch:
- a) Einrichtungen zum Empfangen einer asynchronen Anforde rung nach Daten eines großen Objekts;
- b) Einrichtungen zum Einreihen der Anforderung in eine An forderungswarteschlange;
- c) Einrichtungen zum Empfangen einer asynchronen Anforde rung zur Umpriorisierung der Anforderungswarteschlange;
- d) Einrichtungen zum Bestimmen der Fähigkeit eines Trans portmediums;
- e) Einrichtungen zum Partitionieren der Daten des großen Objekts in Datenblöcke, deren Größe variabel ist und der Fähig keit des Transportmediums entspricht;
- f) Einrichtungen zum Übertragen der angeforderten Daten der großen Objekte zu jedem der Teilnehmer über das Transportmedi um; und
- g) Einrichtungen zum Entfernen der Anforderung aus der An forderungswarteschlange bei Abschluß der Übertragung der ange forderten Daten des großen Objekts.
7. Einrichtung nach Anspruch 6, dadurch gekennzeichnet, daß
das große Objekt ein binäres großes Objekt (BLOB - Binary Large
Object) ist.
8. Einrichtung nach Anspruch 7, dadurch gekennzeichnet, daß
die Einrichtungen zum Einreihen der Anforderung in die Anfor
derungswarteschlange Einrichtungen zum Aufrechterhalten einer
Übertragungswarteschlange mit einem Eintrag für jede Anforde
rung nach der Übertragung eines oder mehrerer BLOBs aufweisen.
9. Einrichtung nach Anspruch 7, dadurch gekennzeichnet, daß
die Einrichtungen zum Übertragen eines BLOB von einem Teilneh
mer zu einem anderen Teilnehmer von einem ein Klar-zum-Senden
anzeigenden Übertragungsstatus abhängig sind.
10. Einrichtung nach Anspruch 8, dadurch gekennzeichnet,
daß die Einrichtungen zum Umpriorisieren die Übertragungswarte
schlange dann umpriorisieren, wenn eine Anforderung zur Umprio
risierung von einem Teilnehmer empfangen worden ist.
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US08/137,319 US5452299A (en) | 1993-10-14 | 1993-10-14 | Optimized transfer of large object data blocks in a teleconferencing system |
US137319 | 1993-10-14 |
Publications (2)
Publication Number | Publication Date |
---|---|
DE4436677A1 true DE4436677A1 (de) | 1995-05-18 |
DE4436677B4 DE4436677B4 (de) | 2005-05-04 |
Family
ID=22476838
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
DE4436677A Expired - Fee Related DE4436677B4 (de) | 1993-10-14 | 1994-10-13 | Verfahren und Einrichtung zum Übertragen von Datenblöcken großer Objekte in einem Telekonferenzsystem |
Country Status (3)
Country | Link |
---|---|
US (1) | US5452299A (de) |
DE (1) | DE4436677B4 (de) |
FR (1) | FR2711260B1 (de) |
Families Citing this family (63)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5608872A (en) * | 1993-03-19 | 1997-03-04 | Ncr Corporation | System for allowing all remote computers to perform annotation on an image and replicating the annotated image on the respective displays of other comuters |
US5583993A (en) * | 1994-01-31 | 1996-12-10 | Apple Computer, Inc. | Method and apparatus for synchronously sharing data among computer |
GB2288041A (en) * | 1994-03-23 | 1995-10-04 | Ibm | Object linking and embedding over a computer network. |
US6651050B2 (en) | 1994-05-02 | 2003-11-18 | International Business Machines Corporation | Co-presence data retrieval system which indicates observers of data |
US6243714B1 (en) | 1997-04-11 | 2001-06-05 | Ubique Ltd. | Co-presence data retrieval system |
GB2289149B (en) * | 1994-05-02 | 1998-11-18 | Ubique Ltd | A co-presence data retrieval system |
US5884028A (en) * | 1994-07-29 | 1999-03-16 | International Business Machines Corporation | System for the management of multiple time-critical data streams |
US6205464B1 (en) * | 1994-09-16 | 2001-03-20 | International Businesss Machines Corporation | System for building optimal commit trees in a distributed transaction processing system |
US6502126B1 (en) * | 1995-04-28 | 2002-12-31 | Intel Corporation | Method and apparatus for running customized data and/or video conferencing applications employing prepackaged conference control objects utilizing a runtime synchronizer |
US6785709B1 (en) * | 1995-04-28 | 2004-08-31 | Intel Corporation | Method and apparatus for building customized data and/or video conferencing applications utilizing prepackaged conference control objects |
JPH0934843A (ja) * | 1995-07-18 | 1997-02-07 | Canon Inc | 処理システム及び処理装置 |
AU6501496A (en) | 1995-07-19 | 1997-02-18 | Ascom Nexion Inc. | Point-to-multipoint transmission using subqueues |
US5559875A (en) * | 1995-07-31 | 1996-09-24 | Latitude Communications | Method and apparatus for recording and retrieval of audio conferences |
JPH11512583A (ja) | 1995-09-14 | 1999-10-26 | フジツウ ネットワーク コミュニケーションズ,インコーポレイテッド | 広域atm網内のバッファ割付用送信側制御式フロー制御 |
US5764902A (en) * | 1995-09-29 | 1998-06-09 | Intel Corporation | Conditional insert or merge in a data conference |
US5748618A (en) * | 1995-09-29 | 1998-05-05 | Intel Corporation | Multilevel arbitration in a data conference |
US5774117A (en) * | 1995-09-29 | 1998-06-30 | Intel Corporation | Method and apparatus for exchanging electronic business cards in a point-to-point or a multi-point personal computer conference |
US5671365A (en) * | 1995-10-20 | 1997-09-23 | Symbios Logic Inc. | I/O system for reducing main processor overhead in initiating I/O requests and servicing I/O completion events |
US5754776A (en) * | 1995-12-28 | 1998-05-19 | Intel Corporation | Re-prioritizing background data transfers in multipoint conferencing |
US5802282A (en) * | 1995-12-28 | 1998-09-01 | Intel Corporation | Recovering missing data during background data transfer in multipoint conferencing |
US5925105A (en) * | 1995-12-28 | 1999-07-20 | Intel Corporation | Preventing processor domination during background data transfer in multipoint conferencing |
US6678812B1 (en) * | 1996-01-16 | 2004-01-13 | Intel Corporation | Method and apparatus for optimizing hard drive performance |
US5956491A (en) | 1996-04-01 | 1999-09-21 | Marks; Daniel L. | Group communications multiplexing system |
US5933597A (en) * | 1996-04-04 | 1999-08-03 | Vtel Corporation | Method and system for sharing objects between local and remote terminals |
CA2256417A1 (en) * | 1996-05-24 | 1997-11-27 | Gregory T. White | Computer method and apparatus for object streaming |
US6199116B1 (en) * | 1996-05-24 | 2001-03-06 | Microsoft Corporation | Method and system for managing data while sharing application programs |
JPH1040197A (ja) * | 1996-07-19 | 1998-02-13 | Fujitsu Ltd | 通信管理装置 |
US6182151B1 (en) * | 1996-07-29 | 2001-01-30 | International Business Machines Corporation | Method and apparatus for batch storage of objects in a client-server storage management system |
US5946467A (en) * | 1996-09-20 | 1999-08-31 | Novell, Inc. | Application-level, persistent packeting apparatus and method |
JP3610718B2 (ja) * | 1997-01-31 | 2005-01-19 | 富士通株式会社 | 電子会議システム |
AU8938598A (en) | 1997-03-27 | 1999-04-23 | Medtronic, Inc. | Implantable Medical Device Remote Expert Communications System For Coordina ted Implant And Follow-Up |
US6699187B2 (en) | 1997-03-27 | 2004-03-02 | Medtronic, Inc. | System and method for providing remote expert communications and video capabilities for use during a medical procedure |
US6253228B1 (en) * | 1997-03-31 | 2001-06-26 | Apple Computer, Inc. | Method and apparatus for updating and synchronizing information between a client and a server |
GB2324175B (en) * | 1997-04-10 | 2002-07-31 | Ibm | Personal conferencing system |
US6085253A (en) * | 1997-08-01 | 2000-07-04 | United Video Properties, Inc. | System and method for transmitting and receiving data |
US5999966A (en) * | 1997-10-07 | 1999-12-07 | Mcdougall; Floyd | Control network-directed video conferencing switching system and method |
US6477143B1 (en) | 1998-01-25 | 2002-11-05 | Dror Ginossar | Method and apparatus for packet network congestion avoidance and control |
CA2332057C (en) * | 1998-05-07 | 2007-05-29 | Ubique Ltd. | A co-presence data retrieval system which indicates observers of data |
US6343286B1 (en) | 1998-09-24 | 2002-01-29 | International Business Machines Corporation | Efficient technique to defer large object access with intermediate results |
US6363389B1 (en) | 1998-09-24 | 2002-03-26 | International Business Machines Corporation | Technique for creating a unique quasi-random row identifier |
US6606617B1 (en) | 1998-09-24 | 2003-08-12 | International Business Machines Corporation | Optimized technique for prefetching LOB table space pages |
US6343293B1 (en) | 1998-09-24 | 2002-01-29 | International Business Machines Corporation | Storing the uncompressed data length in a LOB map to speed substring access within a LOB value |
US6694340B1 (en) | 1998-09-24 | 2004-02-17 | International Business Machines Corporation | Technique for determining the age of the oldest reading transaction with a database object |
US6366902B1 (en) | 1998-09-24 | 2002-04-02 | International Business Machines Corp. | Using an epoch number to optimize access with rowid columns and direct row access |
US6470359B1 (en) | 1998-09-24 | 2002-10-22 | International Business Machines Corporation | Fast technique for recovering an index on an auxiliary table |
US6144970A (en) * | 1998-09-24 | 2000-11-07 | International Business Machines Corporation | Technique for inplace reorganization of a LOB table space |
US7170500B2 (en) * | 2000-08-29 | 2007-01-30 | Palm, Inc. | Flip-style user interface |
US6853382B1 (en) | 2000-10-13 | 2005-02-08 | Nvidia Corporation | Controller for a memory system having multiple partitions |
JP2002222157A (ja) * | 2001-01-29 | 2002-08-09 | Toshiba Corp | 電子会議システム |
US9361593B2 (en) * | 2001-03-30 | 2016-06-07 | Oracle America, Inc. | System and method for using business services |
US7420568B1 (en) | 2003-12-17 | 2008-09-02 | Nvidia Corporation | System and method for packing data in different formats in a tiled graphics memory |
US7286134B1 (en) | 2003-12-17 | 2007-10-23 | Nvidia Corporation | System and method for packing data in a tiled graphics memory |
US6999088B1 (en) | 2003-12-23 | 2006-02-14 | Nvidia Corporation | Memory system having multiple subpartitions |
US7227548B2 (en) * | 2004-05-07 | 2007-06-05 | Valve Corporation | Method and system for determining illumination of models using an ambient cube |
US7516239B2 (en) * | 2004-12-30 | 2009-04-07 | Sap, Aktiengesellschaft | Tool for optimizing system performance and methods relating to same |
US20080120164A1 (en) * | 2006-11-17 | 2008-05-22 | Avaya Technology Llc | Contact center agent work awareness algorithm |
US20080120383A1 (en) * | 2006-11-22 | 2008-05-22 | Shruti Kumar | Method and system for preventing thread insertion or removal |
US8330766B1 (en) | 2008-12-19 | 2012-12-11 | Nvidia Corporation | Zero-bandwidth clears |
US8319783B1 (en) | 2008-12-19 | 2012-11-27 | Nvidia Corporation | Index-based zero-bandwidth clears |
CN101877862A (zh) * | 2009-04-30 | 2010-11-03 | 中兴通讯股份有限公司 | 大对象传输方法、服务器 |
US20120036366A1 (en) * | 2010-08-09 | 2012-02-09 | Microsoft Corporation | Secure and verifiable data handling |
CN102340507A (zh) * | 2011-10-18 | 2012-02-01 | 中兴通讯股份有限公司 | 大对象传输方法及系统 |
US20210314653A1 (en) * | 2020-04-02 | 2021-10-07 | Rovi Guides, Inc. | Systems and methods for delayed pausing |
Family Cites Families (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US4479195A (en) * | 1982-09-07 | 1984-10-23 | At&T Bell Laboratories | Data conference system |
US4479211A (en) * | 1982-10-29 | 1984-10-23 | At&T Bell Laboratories | Method and apparatus for controlling ports in a digital conference arrangement |
GB2166320B (en) * | 1984-10-25 | 1988-10-12 | Stc Plc | Packet switching system |
US5212724A (en) * | 1987-08-14 | 1993-05-18 | General Electric Company | Processor-to-processor communications protocol for a public service trunking system |
US4953159A (en) * | 1989-01-03 | 1990-08-28 | American Telephone And Telegraph Company | Audiographics conferencing arrangement |
US5127001A (en) * | 1990-06-22 | 1992-06-30 | Unisys Corporation | Conference call arrangement for distributed network |
US5323445A (en) * | 1991-03-07 | 1994-06-21 | Mitsubishi Denki Kabushiki Kaisha | Multi-location television conference system |
-
1993
- 1993-10-14 US US08/137,319 patent/US5452299A/en not_active Expired - Lifetime
-
1994
- 1994-10-13 DE DE4436677A patent/DE4436677B4/de not_active Expired - Fee Related
- 1994-10-13 FR FR9412219A patent/FR2711260B1/fr not_active Expired - Fee Related
Also Published As
Publication number | Publication date |
---|---|
US5452299A (en) | 1995-09-19 |
FR2711260A1 (fr) | 1995-04-21 |
DE4436677B4 (de) | 2005-05-04 |
FR2711260B1 (fr) | 1999-02-19 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
DE4436677B4 (de) | Verfahren und Einrichtung zum Übertragen von Datenblöcken großer Objekte in einem Telekonferenzsystem | |
DE602004006798T2 (de) | Nachrichtenübertragung über transiente Verbindungen in einer peer-to-peer Netzwerkumgebung | |
DE69931052T2 (de) | Middleware-basiertes echtzeit-kommunikationssystem | |
US5408470A (en) | Deferred synchronization of distributed objects | |
DE69631808T2 (de) | Konferenzsystem, Endgerätkommunikationsverfahren und Speichereinheit zur Speicherung des Verfahrens | |
DE69433643T2 (de) | Multimedien-kommunikationsnetzwerk | |
US5754776A (en) | Re-prioritizing background data transfers in multipoint conferencing | |
US5802282A (en) | Recovering missing data during background data transfer in multipoint conferencing | |
EP1589722B1 (de) | Verfahren, System und Vorrichtung zur Ermöglichung von Quasi-Echtzeitzusammenarbeit an einem elektronischen Dokument | |
DE60013477T2 (de) | Verfahren zur steurung von mehreren mehrpunktsteuerungseinheiten als eine mehrpunktsteuerungseinheit | |
DE60038705T2 (de) | Verfahren und vorrichtung für die aktivitäts-basierte zusammenarbeit eines rechnersystems, ausgestattet mit einem kommunikations-manager | |
DE60003322T2 (de) | Verfahren, vorrichtung und computerprogrammprodukt für die aktivitäts-basierte zusammenarbeit durch ein computersystem ausgestattet mit einem dynamik-manager | |
US6195091B1 (en) | Apparatus for collaborative computing | |
DE69838314T2 (de) | Verfahren und Vorrichtung zum dynamischen Laden eines Transportmechanismus in einem Mehrpunktdatenübermittlungssystem | |
DE69433042T2 (de) | Multimedia-Post in Telekonferenzsystem | |
DE69816599T2 (de) | Datenübertragungssteuerung und verteilte datenverarbeitung | |
DE69216130T2 (de) | Verfahren und Vorrichtung zur verbesserten Verteilung von elektronischen Mitteilungen | |
DE69730929T2 (de) | System zur Verwaltung der Mitanwesenheit innerhalb Gemeinschaften | |
DE69633103T2 (de) | Universeller Rufnummernauskunftsdienst | |
DE68924525T2 (de) | Gemeinschaftsobjektszustandsanzeige. | |
DE68927508T2 (de) | Zeitweilige Zustandsbewahrung für einen verteilten Dateidienst | |
DE3750941T2 (de) | Multiaufgabenteilnehmerverfahren für das Wiederauffinden von Daten. | |
DE3586430T2 (de) | Lokales netzwerk fuer numerische datenverarbeitungssysteme. | |
DE60312624T2 (de) | Verfahren und Vorrichtung zur Konsistenzunterhaltung eines geteilten Raums über mehrere Endpunkte in einem gleichrangigen kollaborativen Computersystem | |
DE68921715T2 (de) | Konferenzverbindungssystem. |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
8110 | Request for examination paragraph 44 | ||
8364 | No opposition during term of opposition | ||
R119 | Application deemed withdrawn, or ip right lapsed, due to non-payment of renewal fee |
Effective date: 20110502 |