DE4436677B4 - 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 Telekonferenzsystem Download PDF

Info

Publication number
DE4436677B4
DE4436677B4 DE4436677A DE4436677A DE4436677B4 DE 4436677 B4 DE4436677 B4 DE 4436677B4 DE 4436677 A DE4436677 A DE 4436677A DE 4436677 A DE4436677 A DE 4436677A DE 4436677 B4 DE4436677 B4 DE 4436677B4
Authority
DE
Germany
Prior art keywords
request
data
blob
participants
subscriber
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.)
Expired - Fee Related
Application number
DE4436677A
Other languages
English (en)
Other versions
DE4436677A1 (de
Inventor
Tyler R. Portland Thessin
Lewis V. Beaverton Rothrock
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Intel Corp
Original Assignee
Intel Corp
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Intel Corp filed Critical Intel Corp
Publication of DE4436677A1 publication Critical patent/DE4436677A1/de
Application granted granted Critical
Publication of DE4436677B4 publication Critical patent/DE4436677B4/de
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

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 Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (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)

Abstract

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 Objekts empfangen wird;
b) die Anforderung in eine Anforderungswarteschlange eingereiht wird;
c) eine asynchrone Anforderung zur Umpriorisierung der Anforderungswarteschlange empfangen wird;
d) die Fähigkeit eines Transportmediums bestimmt wird;
e) die Daten des großen Objekts in Datenblöcke partitioniert 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 Objekts entfernt wird.

Description

  • Die Erfindung betrifft Telekonferenzsysteme. Insbesondere bezieht sich die Erfindung auf Mechanismen zum Austauschen von Daten zwischen einer Mehrzahl von Teilnehmern in einem elektronischen 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-Line-"Treffen" zwischen einer Vielzahl von Benutzern an einem Computersystem an einer Vielzahl von Orten durchzuführen. Benutzer an unterschiedlichsten Stellen können miteinander kommunizieren, als ob sie im gleichen Raum wären. Unter Verwendung solcher 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 Informationsarten 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 gegenübersitzen und Informationen einander auf einer weißen oder schwarzen Tafel darstellen und wobei andere Teilnehmer Anmerkungen 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 Fernkonferenzen ebenfalls geteilt werden.
  • Eines der Erfordernisse eines elektronischen Konferenzsystems ist die Notwendigkeit, die gleichen Daten auf den Displays sämtlicher an der Konferenz teilnehmender Benutzer zu reproduzieren. 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 Zentralmaschine, 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 Eingabeeinrichtungen für Benutzeranforderungen dienen, an schweren Leistungsproblemen 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 Synchronität sämtlicher Teilnehmer-Displays in einem Konferenzsystem stützt sich auf ein verteiltes Client/Server-System. Bei einer verteilten Client/Server-Lösung wird eine geteilte Objekt-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ß, verschiedene Benutzer über eine Telefonleitung von Punkt zu Punkt ohne das Erfordernis eines Zugriffs auf einen zentralen gemeinsamen Server zu verbinden.
  • Bei der Client/Server-Lösung leidet darüberhinaus die Leistungsfähigkeit in hohem Maße dadurch, daß Anforderungen zum Hinzufügen oder Löschen von Objekten, wie beispielsweise Anmerkungen, graphischen Abbildungen oder anderen Informationen auf einem Teilnehmer-Display, vollständig von der Kommunikation von dem Server abhängig sind. Somit leidet die Echtzeit-Leistungsfä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 Kommunikationsmediums, der Anzahl der verbundenen Teilnehmer usw.
  • Eine weitere bekannte Lösung zur Aufrechterhaltung der Synchronizität einer Mehrzahl von Teilnehmern in einem Konferenzsystem 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, welche lokale Repräsentanten für Objekte in dem "geteilten" Objektraum 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 anderen 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ültigkeit, 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 Systemen haben können und solche unterschiedlichen Objekte möglicherweise nicht in der Lage sind, zu den restlichen Benutzern kommuniziert oder übertragen zu werden.
  • Das U.S.-Patent Nr. 4,953,159 offenbart ein Konferenzsystem, bei welchem Änderungen an einer Datei (z. B. einem Dokument), welche in einem Datenterminal eines Konferenzteilnehmers gespeichert ist und welche der Konferenzteilnehmer auf das Display des Datenterminals bringt, automatisch an sämtliche Konferenzteilnehmer zur Anzeige auf ihren jeweiligen Terminals über eine Datenbrücke verteilt wird, welche Datenpakete aus dem Terminal des Konferenzteilnehmers empfängt und die Datenpakete an die Terminals der anderen Konferenzteilnehmer sendet. Jedoch fehlt es bei dem System an einem Steuermechanismus, der sich mit gleichzeitigen Änderungen an einem Dokument durch mehrere Teilnehmer befaßt. Darüber hinaus wird bei dem bekannten System sämtlichen Änderungen einer Datei eine gleiche Priorität gewährt und es werden sämtliche Änderungen an die mit der Datenbrücke verbundenen Konferenzteilnehmerterminals übermittelt, wenn sie empfangen werden, selbst dann, wenn das System infolge anderer Verarbeitungsanforderungen über geringe Ressourcen verfügt oder wenn die Änderung eine Änderung geringer Priorität ist.
  • Das U.S.-Patent Nr. 4,707,831 offenbart ein Datenübertragungssystem, bei dem Sprachpaketen eine größere Priorität gegeben wird als Datenpaketen, so daß die Übertragung von Datenpaketen unterbrochen wird, wenn ein Sprachpaket gesendet werden soll. Jedoch lehrt das System des U.S.-Patents Nr. 4,707,831 nicht das Synchronisieren der Teilnehmer innerhalb eines Konferenzsystems.
  • 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-Modell, die Informationen von einem einzelnen Knoten zu dem Server und dann von dem Server zu den restlichen Teilnehmersystemen übertragen muß. Außerdem verbraucht die Übertragung sehr großer Datenblöcke, wie beispielsweise Dateien, und/oder Abbildungen oder andere Daten, einen großen Teil der Ressourcen in dem System und der Bandbreite des Kommunikationsmediums. Folglich leiden bekannte Konferenzsysteme an schweren Leistungseinbußen, die von der Datenmenge verursacht werden, welche innerhalb des Systems während einer Telekonferenz übertragen werden können.
    •
  • Die Erfindung bezieht sich auf ein Verfahren und eine Einrichtung zur Kommunikation zwischen Teilnehmern in einem elektronischen 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 Mehrzahl 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 Anforderungswarteschlange;
    • c) Empfangen einer asynchronen Anforderung zum Umpriorisieren 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 jedem der Teilnehmer über das Transportmedium;
    • g) Entfernen der Anforderung aus der Anforderungswarteschlange 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 Datenkonferenzsystems nicht an Leistungsproblemen infolge des Durchsatzes 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 Client/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 Konferenzanwendung 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.
  • 1a veranschaulicht eine Topologie eines Systems, in welchem verschiedene Teilnehmer in einem Konferenzsystem miteinander verbunden werden können.
  • 1b veranschaulicht ein Blockschaltbild einer in einem Teinehmer eines Konferenzsystems enthaltenen Schaltung.
  • 2 ist eine Blockdarstellung der verschiedenen Steuerprozeduren, welche in einem Teilnehmer einer Konferenz vorhanden sind.
  • 3 ist eine Blockdarstellung der in einem implementierten Ausführungsbeispiel der Erfindung verwendeten Klassen.
  • 4 veranschaulicht die Arten von Anmerkungen, welche auf einem Benutzer-Display des einzelnen Teilnehmers in verschiedenen Implementierungen des bevorzugten Ausführungsbeispiels ausgeführt werden können.
  • 5 veranschaulicht die Objekt-Hierarchie, die in bestimmten Ausführungsbeispielen der Erfindung verwendet wird.
  • 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.
  • 7a bis 7e veranschaulichen von einem Entscheider und einem Teilnehmer in einem Konferenzsystem aufrechtgehaltene Objektstrukturen zu verschiedenen Zeitpunkten, wenn ein Teilnehmer Aktionen in seinem lokalen System ausführt.
  • 8 veranschaulicht ein Verfahren, das für die verzögerte Übertragung sehr großer binärer Daten-Objekte in bestimmten Ausführungsbeispielen der Erfindung verwendet wird.
  • 9 veranschaulicht ein Verfahrensablaufdiagramm einer Datenobjektanforderung, die in einem Ausführungsbeispiel der Erfindung verwendet wird.
  • 10 veranschaulicht die Bestimmung eines Transport-Qualifizierers, der zum Übertragen der Daten großer Objekte in einem Ausführungsbeispiel der Erfindung verwendet wird.
  • 11 veranschaulicht ein Verfahrensablaufdiagramm eines Prozesses, der zum Bestimmen der Notwendigkeit einer partiellen Anforderung von Daten großer Objekte in einem Ausführungsbeispiel der Erfindung verwendet wird.
  • 12a bis 12c veranschaulichen verschiedene Stufen der Vervollständigung der Übertragung von Daten sehr großer Objekte in einem Ausführungsbeispiel der Erfindung.
  • 13 veranschaulicht die Architektur eines Hintergrund-Übertragungs-Managers.
  • 14 und 15 veranschaulichen die Verarbeitungslogik für die Teilnehmer-Verbindungs/Trennungslogik.
  • 16 veranschaulicht einen Übertragungswarteschlangeneintrag.
  • 17 veranschaulicht ein Beispiel des Übertragungsanforderungs-Umpriorisierungsprozesses.
  • 18 veranschaulicht ein Beispiel der Klar-zum-Senden-Verarbeitung eines Übertragungswarteschlangeneintrags.
  • 19 und 20 veranschaulichen die Anforderungsverarbeitungslogik der Erfindung.
  • Die Erfindung bezieht sich auf ein Verfahren und eine Einrichtung zur Kommunikation zwischen Teilnehmern in einem elektronischen Konferenzsystem. Obwohl die Erfindung unter Bezugnahme 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 1a gezeigt ist, kann ein Kommunikationssystem eine Mehrzahl von Teilnehmern 11 bis 14 aufweisen, die alle an ein Kommunikationsmedium 20 gekoppelt sind. In bestimmten Ausführunsbeispielen der Erfindung hat jeder an das Medium 20 gekoppelte einzelne Teilnehmer äquivalente Möglichkeiten, um die Kommunikation zwischen den Teilnehmern zu ermöglichen. Das implementierte Konferenzsystem verwendet eine verteilte Lösung, bei der jeder Teilnehmer (11 bis 14) lokale Kopien der Konferenzstruktur ("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 Anfordungen 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 Teilnehmer (11 bis 14) lokale Kopien sämtlicher in der elektronischen Konferenz verwendeter Objekte aufrecht hält. Somit werden Displays, Texte, Graphik und andere auf den Displays der Teilnehmer des Computersystems angezeigte Informationen in Datenstrukturen 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 weniger sofort erfolgen. Die Struktur eines Teilnehmers, der mit dem Kommunikationsmedium 20 gemäß 1a gekoppelt sein kann, ist in 1b veranschaulicht.
  • Im folgenden wird auf 1b Bezug genommen, in der ein System 100 gezeigt ist, das bei einem Ausführungsbeispiel eines erfindungsgemäßen Teilnehmers (z.B. 11 gemäß 1a) implementiert 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 Speichereinrichtung (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 Zwischeninformationen 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 Speichern 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 Datenspeichereinrichtung 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 Kathodenstrahlrö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-Steuereinrichtung 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 Befehlsselektionen 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 Peripherieeinrichtungen 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 Programmiersprache 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 Objektcode im System 100 abgearbeitet. Für den Fachmann ist es jedoch klar, daß die folgenden Verfahren und Einrichtungen in speziellen Hardware-Einrichtungen, wie beispielsweisen diskreten Logikbauelemente, hochintegrierten Schaltungen (LSI's), anwendungsspezifischen integrierten Schaltungen (ASIC's) oder anderer spezieller Hardware, implementiert werden können.
  • Software-Organisation eines Teilnehmers
  • Während der Konferenzlaufzeit ist innerhalb jedes Teilnehmers eine Reihe von Software-Prozeduren abarbeitbar angeordnet, welche in einer in 2 dargestellten Weise organisiert sind. 2 veranschaulicht ein allgemeines Blockdiagramm der Organisation 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 Kommunikation über das Kommunikationsmedium 260 verantwortlich ist, so daß mit anderen Teilnehmern 250 kommuniziert werden kann. Dieser Prozeß stellt sämtliche Low-Level-Kommunikationsfunktionen zur Verfügung, welche ein direktes Zugreifen auf das Kommunikationsmedium 260 gestatten. In verschiedenen Ausführungsbeispielen der Erfindung kann das Kommunikationsmedium 260 eines der verschiedenen Netzwerk-Standardmedien sein, beispielsweise ein lokales Netzwerk (LAN) vom Ethernet-, Token-Ring- oder von einem anderen Typ.
  • Das Kommunikationsmedium 260 kann außerdem ein Telefonnetzwerk mit einer Modem-Verbindung oder ein anderes Datenkommunikationsmedium 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 Teilnehmers ist der Konferenzmanager 230, welcher alle erforderlichen Ausführungsfunktionen zur Kommunikation mit den Kommunikationsfunktionen 240 der unteren Ebene und den von dem Bedienerschnittstellen-Prozeß 210 und dem Objektmanager 220 zur Verfügung gestellten Funktionen höherer Ordnung liefert. Der Konferenzmanager 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 Verwendung eines Objekt-orientierten Systems behandelt, wobei Hierarchien der Objekte definiert werden.
  • Die Kommunikation vom Objektmanager 220 zum Konferenzmanager 230 erfolgt über Nachrichten, welche zu dem Mehr-Punkt-Verbindungsmanager 240 weitergeleitet werden, um Objekte zu erschaffen, für eine Entscheidung (Arbitration) zwischen dem Entscheider und dem Teilnehmer und zur Kommunikation mit anderen 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 Bedienerschnittstellenfunktionen werden zurück zum Konferenzmanager 230 über Nachrichten 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 angezeigten Dingen und anderen Objekten. Zusätzlich wird der Objektmanager 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äß 1b) zurückgewonnen werden, wenn eine Konferenz verlassen bzw. in, die Konferenz 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 Bedienerschnittstelle 210 über Änderungen von anderen Teilnehmern des Treffens. Die Bedienerschnittstellen-Schicht 210 kann dann die Anzeige in der angewiesenen Weise einstellen. Die Bedienerschnittstelle 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 Bedienerschnittstelle ü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 Einstellungen auszuführen. Einen kurzen Überblick der Struktur von Objekten in einem Ausführungsbeispiel der Erfindung wird in 3 veranschaulicht.
  • Objektklassifizierungsstruktur
  • 3 veranschaulicht eine allgemene 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 Klassifizierung 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 öffentlichen 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 ebenfalls 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 elektronischen 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 anderer Teilnehmer gebracht werden. Wenn Teilnehmer das Treffen verlassen, wird sichergestellt, daß sämtliche Beiträge der Benutzer geteilt sind, bevor der Teilnehmer das Treffen verläß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 Teilnehmer eine Anmerkung steuert, wieviele Seiten im aktuellen Treffen existieren usw. Er hält darüber hinaus eine Master-Kopie des Treffens, zu der sich sämtliche anderen Teilnehmer synchronisieren. Die Objektmanager innerhalb jedes Teilnehmers koordinieren, 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 vorgegeben wird. Andere Konferenzereignisse sind beispielsweise das Öffnen/Verschmelzen einer Treffen-Datei, in welcher der die Treffen-Datei öffnende/verschmelzende Teilnehmer vor dem Öffnen/Verschmelzen der Datei der Entscheider geworden war. Bei einer Implementierung der Erfindung wird dem Benutzer, der als erster ein Treffen startet, die Entscheider-Funktionen zugewiesen.
  • Eine sehr grobe Näherung der Arten von Objekten, welche auf einem Teilnehmer-Display vorhanden sein können, ist in 4 veranschaulicht. Grundsätzlich hat ein Benutzer einen Treffen-Bereich 400 auf seinem Display, in welchen verschiedene Informationen 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 4 veranschaulicht. Beispielsweise kann eine Seite 410 eine Zeichnungs-Anmerkung 411 enthalten, welche typischerweise eine von einem einzigen Benutzer erschaffene objekt-orientierte Zeichnung ist. Solche objektorientierten Zeichnungen wie 411 weisen eine Beschreibung aus Punktpositionen und dazwischenliegenden Segmenten auf. Anmerkungen können außerdem graphische Anmerkungen 412 sein, welche grundsä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 ausgewählt sein und dem Benutzer gestatten, die Schriftart, die Punktgröße, den Fond und andere Formatinformationen auszuwählen, wie es typisch für bekannte Implementierungen ist. Eine andere Anmerkung ist die OLE-Anmerkung, die ein Objekt-Verbindungs- 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 Anmerkungen wird als Objekt unter einer "Anmerkungs"-Klassifikation gespeichert, welche Objekten in der Seiten-Klassifikation zugeordnet ist. 5 veranschaulicht die Klassifizierung für Objekte, die in einem Ausführungsbeispiel der Erfindung verwendet werden.
  • Die Gesamtstruktur der Objektklassen ist in 5 veranschaulicht. 5 enthält das Treffen-Objekt, Benutzer-, Entscheider-, Teilnehmer- und Anmerkungs-Objekte, welche anhand der 3 und 4 oben erörtert und veranschaulicht wurden. In
  • 5 sind Beziehungen durch eine mit einem Punkt versehene breite Linie veranschaulicht, wobei Vererbungs-Beziehungen durch eine Pfeilspitze dargestellt sind, bei der die Richtung der Vererbung der Orientierung der Pfeilspitze folgt. Zusätzlich 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 Elternobjekt geben kann. Beispielsweise hat der CObjectManager 501 (Objekt-Manager), wie es anhand von 3 veranschaulicht und erörtert wurde, zwei CCMeeting-Objektklassen (Treffen-Objektklassen): das "öffentliche" Treffen und das "private" Treffen. Zusätzlich sind der CCMeeting-Objektklasse 506 Teilnehmer-. Objekte CCParticipant 509 zugeordnet, wie sie als 350 in 3 gezeigt sind. Darüber hinaus nimmt die CCMeeting-Objektklassifizierung 506 Bezug auf das CCPage-Objekt 508 (Seiten-Objekt). Die CCPage-Klassifizierung wird verwendet zum Definieren sämtlicher Seiten eines speziellen Treffens (Meeting). Unter der CCPage-Klassifizierung 508 gibt es die Anmerkungs-Klassifizierungen (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 Beziehungen 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 4) in CCGraphicAnnotation 522 und für die Bezugnahme auf Zeichnungs-Anmerkungen (wie beispielsweise 411 in 4) in der CCDrawAnnotation-Klasse 523). Eine andere Anmerkung, die in einem Ausführungsbeispiel der Erfindung 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, Klassifizierung 501, erhältlich, wie beispielsweise die Klassifizierung 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 Zugriffstelefonnummern.
  • Schließlich enthält der verbleibende Satz von in 5 gezeigten 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 Objekt), welche eine Beziehung hat zu und Charakteristiken erbt von der Anmerkungs-Objektklassifizierung 532 und der CCCachableBLOB-Objektklassifizierung 515. Die CCBLOB 516 wird zum Darstellen sehr großer Objekte in verschiedenen Ausführungsbeispielen der Erfindung verwendet. Verschiedene Ausführungsbeispiele 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 Benutzern verteilt sein. Darüberhinaus ist bei verschiedenen Ausführungsbeispielen 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 Übertragung dieser sehr großen binären Objekte belastet, soweit dies nicht unbedingt erforderlich ist. Sehr große binäre Objekte oder BLOBs können zur Darstellung eines beliebigen Informationstyps 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ührunsbeispielen wird angenommen, daß andere binäre Daten, einschließlich ausführbarer Programmdaten, mit Hilfe dieser Techniken übertragen werden können.
  • Überblick über die Arbeitsweise der aufgeschobenen Synchronisation
  • Wie bereits erörtert wurde, hält jeder der Konferenzteilnehmer seine eigenen den aktuellen Zustand des Displays des geteilten 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 Entscheider kann seine Funktion aufnehmen. In einem Ausführungsbeispiel 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-Struktur bestätigt werden. Obwohl Benutzer Änderungen an ihren eigenen 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 einzelnen Teilnehmer gestattet ist, seine Treffen-Struktur ohne Autorisierung durch den Entscheider zu modifizieren, und die spätere Synchronisation der Treffen-Struktur mit den anderen Teilnehmern der Konferenz wird im folgenden als aufgeschobene Synchronisation 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 synchronisiert 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 synchonisiert worden ist. Zusätzlich hält und gewährt der Entscheider Objekt-Indizes auf neue Objekte, wenn diese von einem bestimmten Teilnehmer geschaffen und/oder modifiziert worden sind, wodurch 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 Nachrichten von dem Entscheider, die einen neuen Objekt-Index anzeigen, so daß der Teilnehmer seine lokale Treffen-Struktur aktualisieren 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 Anmerkung zu einer existierenden Seite hinzuzufügen. Der Bedienerschnittstellenprozeß 210 erfaßt diese Anforderung und sendet eine Nachricht zum Objekt-Manager 220, um die Anmerkung hinzuzufügen. Dann wird vom Objekt-Manager 220 des anfordernden Teilnehmers eine Anforderung zum Objekt-Manager des Entscheiders 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 anderen Teilnehmern des Treffens synchonisiert worden ist. Außerdem hat der Teilnehmer bei seiner Kommunikation mit dem Entscheider seinen Teilnehmer-Index und eine Anforderung nach einem Objekt-Index dem Entscheider angezeigt. Dann kann der Benutzer 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 Teilnehmer seine Treffen-Struktur aktualisieren, um dem vom Entscheiden empfangenen Index zu entsprechen. Eine detailliertere Erörterung dessen wird unter Bezugnahme auf die 6a bis 7e diskutiert.
  • Details des Prozesses der aufgeschobenen Synchronisation
  • Die 6a und 6b veranschaulichen detailliert einen Prozeß 600, welcher bei der Erfassung einer Anforderung zum Ausfü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 Objekts oder der Löschung eines Objekts von der Bedienerschnittstelle 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. vorhandenen 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 Synchonisierung des Treffens entspannt sind und der Benutzer irgendwel che Modifikationen an der lokalen Treffen-Struktur ohne die von der Synchonisierung mit anderen Teilnehmern hervorgerufene Verzögerung vornehmen kann, so wird der Prozeß am Schritt 603 forgesetzt. Im Schritt 603 wird festgestellt, ob das aktuelle Kommando die Änderung eines Objekts bewirken soll, welches bereits "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 synchonisiert 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ß erfordert außerdem die Kommunikation mit anderen Teilnehmern in der Konferenz, wie es in 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 Unter-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 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 synchonisiert 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 synchronisiert 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 angeforderten Änderungen nur lokal ausgeführt, wobei alle Änderungen 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 Ereignisschleife 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 Schritte 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 jedoch 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 ausgefü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 worden 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 Bedienerschnittstellen-Schicht 210 (Human Interface (HI) Layer) über dieses Ereignis 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" gekennzeichneten Seiten-Anhänger der lokal erschaffenen Seite zuzuordnen. Nachdem dann seine eigene lokale Treffen-Struktur und Anzeige im Schritt 611 modifiziert worden sind, sendet der Teilnehmer die gegebenenfalls vorhandenen blockierten Änderungen, 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 Teilnehmer der Konferenz ebenfalls ihre eigenen lokalen Treffen-Strukturen und zugeordneten Anzeigen mit den geeigneten Seiten und Anmerkungen aktualisieren, um synchron mit dem die Änderungen 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ßaustrittspunkt 620.
  • Eine einfache Veranschaulichung einer lokalen Treffen-Struktur und einer Treffen-Struktur eines Entscheiders läßt sich anhand der 7a bis 7e vornehmen, die die Hinzufügung eines Objekts während verschiedener Schritte des in den 6a und 6b veranschaulichten Prozesses 600 zeigen. Beispielsweise kann zum in 7a dargestellten Zeitpunkt t1 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 7b dargestellten Zeitpunkt t2 kann der Teilnehmer ein zusätzliches Objekt O4 704, wie beispielsweise eine Seite oder Anmerkung, erschaffen, um es zu seiner lokalen Treffen-Struktur hinzuzufügen. Gleichzeitig kann der Entscheider eine Anforderung von einem zweiten Teilnehmer zum Hinzufügen eines Objekts O'4 714 zu seiner Treffen-Struktur infolge eines Anforderung-zum-Hinzufügen-Kommandos empfangen. Dann haben nachfolgend zum Zeitpunkt t3 der Entscheider und der Teilnehmer jeweils innerhalb ihrer lokalen Treffen-Strukturen ein unterschiedliches Objekt, das den gleichen Objekt-Index 4 hat. Beispielsweise hat der Teilnehmer das Objekt 704 als viertes Objekt in seiner Treffen-Struktur und der Entscheider hat das Objekt 714 als viertes Objekt in seiner Treffen-Struktur. Dann sendet zu einem nachfolgenden Zeitpunkt t4 der Teilnehmer eine Anforderung an den Entscheider, die das Hinzufügen eines zusätzlichen Objekts zu der von dem Entscheider gehaltenen "offiziellen" Objekt-Struktur anfordert. Dies ist als Block 715 in 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'4 705 zurück, das in die Objektliste des lokalen Teilnehmers eingefügt werden soll. Somit können zu einem nachfolgenden in 7e dargestellten Zeitpunkt t5 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 Objekten für Teilnehmer in einer elektronischen Konferenz substantielle 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 Erzeugung von Anmerkungen in Echtzeit, ohne die Verzögerung aufgrund der Koordination solcher Operationen mit dem Server ausführen. Ein weiterer Vorteil der aufgeschobenen Synchronisation 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 Netzwerk-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. Folglich hat die Erfindung wesentliche Vorteile gegenüber bekannten Systemen, welche eine vollständige Synchronisation zu sämtlichen Zeitpunkten zwischen sämtlichen Teilnehmern der Konferenz erfordern und somit eine wesentliche Verzögerung für eine Synchronisation und eine Antwortverzögerung in der Benutzerschnittstelle zu dem System auf sich laden.
  • Übertragung von Daten großer Objekte
  • 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 Transportmediums übertragen werden kann. Folglich muß ein solches Objekt in kleinere Abschnitte oder Pakete zerteilt und in verschiedenen 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 Transportmediums 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-Übertragungsanforderungen 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 erste 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 umarrangiert, um die gewünschte Änderung der Übertragungspriorität zu bewirken. Die Details dieses Mechanismus werden im folgenden erörtert.
  • Zunächst müssen während einer typischen elektronischen Konferenz 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äteren 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 ausgeführt werden, wird anhand von 8 erläutert.
  • 8 veranschaulicht die Reihenfolge der von einem lokalen 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 Teilnehmer 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 erforderlichen, oben anhand des aufgeschobenen Synchronisationsprozesses 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 individuell 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 detaillierter anhand von 9 erörtert. Der lokale Teilnehmer sendet dann zu jedem der entfernten Teilnehmer die angeforderten 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 Bedienerschnittstellenprozeß 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äß 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ßeintrittspunkt eingetreten. D.h., mehrere neue Anforderungen und Umpriorisierungsanforderungen können von mehreren Teilnehmern asynchron empfangen werden. Dann wird im Schritt 902 der Transportqualifizierer für die neue Anforderung oder für eine Umpriorisierungsanforderung 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 mehrerern 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 Übertragungswarteschlangeneintrag 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 Warteschlangeneinträge umpriorisierende Umpriorisierungsanforderungen. 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 gesetzt. Detailliertere Schritte zum Bestimmen des Transportqualifizierers werden unter Bezugnahme auf den Proßez 1000 gemäß 10 beschrieben. Ein Beispiel des Umpriorisierungsprozesses wird in Verbindung mit 17 beschrieben.
  • Sobald der Transportqualifizierer bestimmt worden ist, wird im Schritt 903 festgestellt, ob eine existierende Anforderung nach anhängigen Daten den Empfang einer Umpriorisierungsanforderung von einer ursprünglichen Anforderung nach BLOB-Daten anzeigt. 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 gleichen 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 Zeitpunkt an, zu welchem die Anforderung ausgeführt wurde, empfangen, 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 werden. 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 Übertragungswarteschlangeneintrags hinzugefügt. Andernfalls, wenn die Übertragung begonnen hat, wird zusätzlich zu dem obigen ein weiterer Übertragungswarteschlangeneintrag hinzugefügt, um die bereits übertragenen Daten zu berücksichtigen. Wenn jedoch keine anhängigen Anforderungen nach den aktuellen BLOB-Daten existieren, dann wird ein neuer Übertragungswarteschlangeneintrag in die Übertragungswarteschlange des Teilnehmers im Schritt 905 eingegeben, 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 Datenanforderungsverarbeitung 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äß 9 vorgenommenen Prozeßschritte wird anhand von 10 gegeben. Prozeß 1000 dient zum Bestimmen des Transportqualifizierers. Der Transportqualifizierer wird verwendet bei der Handhabung der Kombination mehrerer Anforderungen. D. h., Anforderungen von über ein Hochgeschwindigkeitsmedium miteinander verbundenen 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 Verarbeitungszeit 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 irgendeine Anzahl von Niveaus des Transportdurchsatzes spezifizieren kann. Die Erfindung ist nicht nur auf ein hohes und ein niedriges Niveau begrenzt. Beispielsweise können die Transportniveaus so spezifiziert werden, daß eine Einteilung in 4800-baud-Modems, 9600-baud-Modems, ISDN-Verbindungen, schnelle und langsame Netzwerkverbindungen usw. entsteht.
  • Der Prozeß 1000 startet an einem typischen Prozeßeintrittspunkt 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 Hochgeschwindigkeitsqualifizierer verwendet. Wenn jedoch der ferne und der lokale Teilnehmer über ein Transportmedium geringer Geschwindigkeit miteinander gekoppelt sind, wie dies im Schritt 1002 festgestellt wird, dann wird im Schritt 1004 ein Niedriggeschwindigkeitstransportqualifizierer verwendet. Im Schritt 1005 ist die Bestimmung des Transportqualifizierers beendet und der begleitende Prozeß kann fortgesetzt werden.
  • Der Prozeß der aufgeschobenen Übertragung, welcher unter Bezugnahme auf Schritt 904 gemäß 9 erörtert wurde, wird im folgenden unter Bezugnahme auf den Prozeß 1100 gemäß 11 diskutiert. Beispielsweise wurde im Schritt 1101, einem typischen Prozeßeintrittspunkt von einer Ereignisschleife eines ausführenden Prozesses, bereits festgestellt, daß eine existierende Anforderung für die speziellen BLOB-Daten anhängig ist. Wenn eine Anforderung für den aktuellen Teilnehmer 1102 bereits anhängig 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 Anforderung anhängig war, wie dies unter Bezugnahme auf den Teilnehmer-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 Übertragungswarteschlangeneintrag 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 existieren, 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 Teilnehmern übertragene Daten müssen für den aktuellen anfordernden Teilnehmer nach Abschluß der gegenwärtigen Übertragung übertragen 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 Teilnehmer 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 Übertragungseintrags der Übertragungswarteschlange hinzugefügt. Die zusätzliche partielle Anforderung wird unter Bezugnahme auf 12 näher erläutert.
  • Die Vorbereitung partieller Anforderungen werden unter Bezugnahme auf die 12a bis 12c beschrieben. Beispielsweise können zwei Teilnehmer B und C die Übertragung eines BLOB von 38.000 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 Zeitpunkt t1 gemäß 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 dritter 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-Warteschlangeneintrags mit dem OFFSET 2000 und der Größe (SIZE) 36.000) hinzugefügt, und ein nachfolgendes partielles (Anforderungs-) Übertragungswarteschlangen-Element wird zur Übertragungswarteschlange an einer Position nach dem aktuellen Übertragungswarteschlangeneintrag (für OFFSET Null und SIZE 2000) hinzugefügt. Somit wird zu einem nachfolgenden Zeitpunkt t2 (dargestellt in 12b) der Teilnehmer D zu der existierenden Übertragungseintrag-Verteilungsliste hinzugefügt und die Übertragung von dem Übertragungs-OFFSET 2000 und mit der verbleibenden Übertragungsgröße 36.000, die in dem BLOB-Übertragungswarteschlangeneintrag angezeigt ist, fortgesetzt. Dies ist grafisch in 12b durch den aktuellen Abschnitt der Übertragung 1211 und den verbleibenden Abschnitt 1212 dargestellt. Schließlich wird bei Abschluß der Übertragung des in 12b dargestellten Elements ein anderer Warteschlangeneintrag referenziert zum Übertragen nur eines Abschnitts des BLOB's, da die Anforderung des Teilnehmers D mitten in der anfänglichen Übertragung zu den Teilnehmern B und C empfangen wurde. An dieser Stelle hat der nächste Übertragungseintrag zum Zeitpunkt t3 (veranschaulicht in 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 Datenabschnitte 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äß 12c dargestellten Abschnitt. Die Übertragung der Daten für den in 12c dargestellten partiellen Abschnitt erfolgt vom Ende des partiellen Abschnitts zu dessen Anfang, so daß das BLOB in dem Speicher des anfordernden Teilnehmers zusammenhängend gehalten werden kann. Bei Abschluß des Empfangs des partiellen Abschnitts benachrichtigt der Teilnehmer D dann seine Bedienerschnittstelle, damit diese die Anzeige der Anmerkung, die das zuvor unvollständie BLOB-Objekt enthält, aktualisieren kann. Somit ist bei Abschluß der durch den in 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 zugeordneten Ü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 speziellen Ü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 18 beschrieben.
  • Im folgenden wird auf 13 Bezug genommen, in der ein Architekturdiagramm die Komponenten des Hintergrund-Übertragungs-Managers (BTM – Background Transfer Manager) der Erfindung veranschaulicht. Die Übertragung großer Daten-Objekte wird durch den BTM gesteuert. Der BTM besteht aus sechs Hauptabschnitten: 1) Teilnehmer-Verbindungs/Trennungs-Steuerlogik 1312, 2) Anforderungs-Verarbeitungslogik 1314, 3) Datenübertragungsverarbeitungslogik 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 14 und 15 beschrieben. Die Logikkomponenten 1314 und 1316 werden in Verbindung mit den 16 bis 20 beschrieben. Die Klar-zum-Senden-Liste 1318 wird verwendet, um den Klar-zum-Senden-Status der Anforderungen zu halten. Dieses Protokoll wird in Verbindung mit 18 beschrieben. Die Liste 1322 der hereinkommenden Übertragungen 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 folgenden wird auf die 14 und 15 Bezug genommen, in denen Ablaufdiagramme diese Verarbeitung der Verbindung und Trennung dargestellt sind.
  • In 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ängigkeit von der Charakteristik des Tranportmediums wird der Teilnehmer qualifiziert für eine Hochgeschwindigkeitsübertragung mit einer entsprechenden optimalen Paketgröße (Blöcke 1428 und 1430) oder qualifiziert für eine Übertragung geringerer Geschwindigkeit mit einer entsprechenden optimalen Paketgröße (Blöcke 1434 und 1436).
  • In 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 Übertragungswarteschlangeneinträge entfernt (Block 1524). Übertragungswarteschlangeneinträ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 Geschwindigkeit). Diese Größen bleiben zwischen den Teilnehmer-Verbindungs- und -Trennungs-Ereignissen konstant. Anders gesagt, nur Teilnehmer-Verbindungs- und -Trennungs-Ereignisse beeinflussen die optimale Übertragungsgröße. Zu beachten ist, daß die optimale Übertragungsgröße nicht eine maximale übertragbare Paketgröße ist. Sie ist die optmiale 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 13 Bezug genommen. Die Anforderungs-Verarbeitungslogik 1314 wird sowohl in sendenden als auch in empfangenden Systemen verwendet. Sowohl die Anforderungs-Verarbeitungslogik 1314 als auch die Datenübertragungslogik 1316 verwenden eine Übertragungswarteschlange zum Verfolgen des Status der BLOB-Anforderungen und BLOB-Daten. In 16 veranschaulicht ein Architekturdiagramm die Struktur eines einzelnen Hintergrund-Übertragungs-Manager-Übertragungswarteschlangeneintrags 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 verfolgen. Die Empfängerliste 1618 ist eine Liste von Teilnehmern, die das spezielle durch die Referenz 1612 identifizierte BLOB empfangen sollen. Der vorhergehende Übertragungswarteschlangeneintrag 1620 und der nächste Übertragungswarteschlangeneintrag 1622 werden verwendet, um BLOB-Anforderungen miteinander in der Übertragungswarteschlange zu verbinden.
  • In 19 ist die Anforderungsverarbeitungslogik 1110 für einen anfordernden Teilnehmer veranschaulicht. 20 veranschaulicht 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 19 gezeigt 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 Übertragungen ist, fügt der BLOB-Anforderer einen Übertragungswarteschlangeneintrag der Liste 1322 der hereinkommenden Übertragungen hinzu (Verarbeitungsblock 1918) und sendet eine neue Anforderung nach BLOB-Daten an den BLOB-Urheber (Verarbeitungsblock 1920). Die Anforderungsverarbeitungslogik für einen BLOB-Anforderer endet dann an dem Rückkehrpunkt 1924.
  • Wie in 20 gezeigt ist, verarbeitet der BLOB-Urheber dann diese Anforderung und fügt entweder einen neuen hinausgehenden Ü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.
  • 17 veranschaulicht ein Beispiel einer Übertragungswarteschlangenumpriorisierung. Wie dort gezeigt ist, werden BLOB-Anforderungen zu der Übertragungswarteschlange in der empfangenen 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 Übertragungswarteschlange 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 Umpriorisierungsanforderung empfangen wird, wird die betroffene Anforderung (Anforderung 1 im Schritt 1770) vor die anderen Anforderungen in der Übertragungswarteschlange bewegt.
  • Es wird wieder auf 13 Bezug genommen. Die Übertragungsverarbeitungslogik 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 bestimmt) zu den Empfängern, die in dem Übertragungswarteschlangeneintrag 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.
  • 18 veranschaulicht ein Beispiel der Klar-zum-Senden-Verarbeitung nach der Erfindung. Bei diesem Beispiel repräsentiert jede Zelle bzw. jeder Kasten einen Übertragungswarteschlangeneintrag. Die Nummern in den jeweiligen Zellen repräsentieren eine Eintragsnummer, die allein für Identifizierungszwecke verwendet wird. Die Buchstaben in jeder Zelle repräsentieren die Empfänger, die dem Übertragungs-Warteschlangeneintrag 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, welcher 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ämtliche Einträge in der Übertragungswarteschlange im Schritt 1860 nicht klar-zum-Senden sind, endet die Datenübertragungsverarbeitung 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 beschrieben.

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 Objekts empfangen wird; b) die Anforderung in eine Anforderungswarteschlange eingereiht wird; c) eine asynchrone Anforderung zur Umpriorisierung der Anforderungswarteschlange empfangen wird; d) die Fähigkeit eines Transportmediums bestimmt wird; e) die Daten des großen Objekts in Datenblöcke partitioniert 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 Objekts 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 gekennzeichnet, daß ein BLOB von einem Teilnehmer zu einem anderen Teilnehmer 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 Anforderung zur Umpriorisierung von einem Teilnehmer empfangen wird.
  6. Einrichtung zum Übertragen von Datenblöcken großer Objekte 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 Anforderung nach Daten eines großen Objekts; b) Einrichtungen zum Einreihen der Anforderung in eine Anforderungswarteschlange; c) Einrichtungen zum Empfangen einer asynchronen Anforderung zur Umpriorisierung der Anforderungswarteschlange; d) Einrichtungen zum Bestimmen der Fähigkeit eines Transportmediums; e) Einrichtungen zum Partitionieren der Daten des großen Objekts in Datenblöcke, deren Größe variabel ist und der Fähigkeit des Transportmediums entspricht; f) Einrichtungen zum Übertragen der angeforderten Daten der großen Objekte zu jedem der Teilnehmer über das Transportmedium; und g) Einrichtungen zum Entfernen der Anforderung aus der Anforderungswarteschlange bei Abschluß der Übertragung der angeforderten 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 Anforderungswarteschlange Einrichtungen zum Aufrechterhalten einer Übertragungswarteschlange mit einem Eintrag für jede Anforderung nach der Übertragung eines oder mehrerer BLOBs aufweisen.
  9. Einrichtung nach Anspruch 7, dadurch gekennzeichnet, daß die Einrichtungen zum Übertragen eines BLOB von einem Teilnehmer 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 Übertragungswarteschlange dann umpriorisieren, wenn eine Anforderung zur Umpriorisierung von einem Teilnehmer empfangen worden ist.
DE4436677A 1993-10-14 1994-10-13 Verfahren und Einrichtung zum Übertragen von Datenblöcken großer Objekte in einem Telekonferenzsystem Expired - Fee Related DE4436677B4 (de)

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 2002-05-03

Publications (2)

Publication Number Publication Date
DE4436677A1 DE4436677A1 (de) 1995-05-18
DE4436677B4 true 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)

* Cited by examiner, † Cited by third party
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
GB2289149B (en) * 1994-05-02 1998-11-18 Ubique Ltd A co-presence data retrieval system
US6243714B1 (en) 1997-04-11 2001-06-05 Ubique Ltd. 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 処理システム及び処理装置
US5872769A (en) 1995-07-19 1999-02-16 Fujitsu Network Communications, Inc. Linked list structures for multiple levels of control in an ATM switch
US5559875A (en) * 1995-07-31 1996-09-24 Latitude Communications Method and apparatus for recording and retrieval of audio conferences
EP0873611A1 (de) 1995-09-14 1998-10-28 Fujitsu Network Communications, Inc. Sender-gesteuerte flusssteuerung zur pufferspeicherzuordnung in atm-wan
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
US6199116B1 (en) * 1996-05-24 2001-03-06 Microsoft Corporation Method and system for managing data while sharing application programs
AU3137897A (en) * 1996-05-24 1997-12-09 Narrative Communications Corp. Computer method and apparatus for object streaming
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 富士通株式会社 電子会議システム
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
US6325756B1 (en) 1997-03-27 2001-12-04 Medtronic, Inc. Concepts to implement medconnect
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
DE69941705D1 (de) * 1998-05-07 2010-01-07 Ibm Ein co-präsentes datenrückholsystem welches beobachterdaten anzeigt
US6363389B1 (en) 1998-09-24 2002-03-26 International Business Machines Corporation Technique for creating a unique quasi-random row identifier
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
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
US6606617B1 (en) 1998-09-24 2003-08-12 International Business Machines Corporation Optimized technique for prefetching LOB table space pages
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
US6343286B1 (en) 1998-09-24 2002-01-29 International Business Machines Corporation Efficient technique to defer large object access with intermediate results
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
US7286134B1 (en) 2003-12-17 2007-10-23 Nvidia Corporation System and method for packing data in a tiled graphics memory
US7420568B1 (en) 2003-12-17 2008-09-02 Nvidia Corporation System and method for packing data in different formats 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

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4707831A (en) * 1984-10-25 1987-11-17 Stc Plc Packet switching system
US4953159A (en) * 1989-01-03 1990-08-28 American Telephone And Telegraph Company Audiographics conferencing arrangement

Family Cites Families (5)

* Cited by examiner, † Cited by third party
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
US5212724A (en) * 1987-08-14 1993-05-18 General Electric Company Processor-to-processor communications protocol for a public service trunking system
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

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4707831A (en) * 1984-10-25 1987-11-17 Stc Plc Packet switching system
US4953159A (en) * 1989-01-03 1990-08-28 American Telephone And Telegraph Company Audiographics conferencing arrangement

Also Published As

Publication number Publication date
FR2711260B1 (fr) 1999-02-19
US5452299A (en) 1995-09-19
FR2711260A1 (fr) 1995-04-21
DE4436677A1 (de) 1995-05-18

Similar Documents

Publication Publication Date Title
DE4436677B4 (de) Verfahren und Einrichtung zum Übertragen von Datenblöcken großer Objekte in einem Telekonferenzsystem
DE69631808T2 (de) Konferenzsystem, Endgerätkommunikationsverfahren und Speichereinheit zur Speicherung des Verfahrens
DE69634950T2 (de) Identifizierung von anwendungsfähigkeiten für telekonferenzverbindungen
DE69931052T2 (de) Middleware-basiertes echtzeit-kommunikationssystem
DE69433643T2 (de) Multimedien-kommunikationsnetzwerk
US5408470A (en) Deferred synchronization of distributed objects
DE602004006798T2 (de) Nachrichtenübertragung über transiente Verbindungen in einer peer-to-peer Netzwerkumgebung
DE69816599T2 (de) Datenübertragungssteuerung und verteilte datenverarbeitung
DE60013477T2 (de) Verfahren zur steurung von mehreren mehrpunktsteuerungseinheiten als eine mehrpunktsteuerungseinheit
US5938723A (en) Re-prioritizing background data transfers in multipoint conferencing
DE60038705T2 (de) Verfahren und vorrichtung für die aktivitäts-basierte zusammenarbeit eines rechnersystems, ausgestattet mit einem kommunikations-manager
US5802282A (en) Recovering missing data during background data transfer in multipoint conferencing
DE60003322T2 (de) Verfahren, vorrichtung und computerprogrammprodukt für die aktivitäts-basierte zusammenarbeit durch ein computersystem ausgestattet mit einem dynamik-manager
EP1589722B1 (de) Verfahren, System und Vorrichtung zur Ermöglichung von Quasi-Echtzeitzusammenarbeit an einem elektronischen Dokument
DE69838314T2 (de) Verfahren und Vorrichtung zum dynamischen Laden eines Transportmechanismus in einem Mehrpunktdatenübermittlungssystem
DE3887572T2 (de) Verfahren zur Instandhaltung einer Netzstruktur-Datenbank.
DE69432803T2 (de) Anrufdetektion und Anrufbearbeitung in einem Multimedia Kollaborationssystem
DE3586430T2 (de) Lokales netzwerk fuer numerische datenverarbeitungssysteme.
DE68921715T2 (de) Konferenzverbindungssystem.
DE60217907T2 (de) Lokale cache-speicherung von bildern für online-konferenzprogramme
DE69816294T2 (de) Dynamische selektion von mediaströmen für ihre darstellung
DE69736422T2 (de) Verfahren und Vorrichtung für eine hybride Serverkommunikationsstruktur zwischen gleichen Schichten
DE602005004721T2 (de) Verfahren zur Verwaltung von verdoppelten Nachrichtenmeldungen in multimedialen Benachrichtigungsdiensten
DE3608173A1 (de) Datenverarbeitungssystem und verfahren zur uebertragung von daten ueber ein datenuebertragungsmedium zwischen mehreren datenverarbeitungsgeraeten
DE3608126A1 (de) Einrichtung und verfahren zum zuordnen einer speziellen adresse zu einem mit einem datenuebertragungsmedium gekoppelten datenverarbeitungsgeraet

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