DE60317453T2 - Verfahren zur Datenströmung zwischen einem Server und einem Client - Google Patents

Verfahren zur Datenströmung zwischen einem Server und einem Client Download PDF

Info

Publication number
DE60317453T2
DE60317453T2 DE60317453T DE60317453T DE60317453T2 DE 60317453 T2 DE60317453 T2 DE 60317453T2 DE 60317453 T DE60317453 T DE 60317453T DE 60317453 T DE60317453 T DE 60317453T DE 60317453 T2 DE60317453 T2 DE 60317453T2
Authority
DE
Germany
Prior art keywords
mail
data
request
message
component
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 - Lifetime
Application number
DE60317453T
Other languages
English (en)
Other versions
DE60317453D1 (de
Inventor
Joseph R. Renton Warren
Min Kirkland Zhong
Karl Shoreline Froelich
Nicole A. Redmond Bonilla
Robert R. Redmond Novitskey
Alec Redmond Dun
Ronald Eric Redmond Gray
Aaron Duvall Hartwell
Steven F. Seattle Goddard
Brendan Seattle Power
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.)
Microsoft Corp
Original Assignee
Microsoft 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 Microsoft Corp filed Critical Microsoft Corp
Publication of DE60317453D1 publication Critical patent/DE60317453D1/de
Application granted granted Critical
Publication of DE60317453T2 publication Critical patent/DE60317453T2/de
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L51/00—User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail
    • H04L51/21—Monitoring or handling of messages
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L51/00—User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail
    • H04L51/21—Monitoring or handling of messages
    • H04L51/234—Monitoring or handling of messages for tracking messages
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/08—Protocols for interworking; Protocol conversion
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L51/00—User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L51/00—User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail
    • H04L51/06—Message adaptation to terminal or network requirements
    • H04L51/066—Format adaptation, e.g. format conversion or compression

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Information Transfer Between Computers (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Computer And Data Communications (AREA)
  • Communication Control (AREA)

Description

  • Gebiet der Erfindung
  • Die Erfindung betrifft allgemein Computernetzwerke und insbesondere Verfahren zum Kommunizieren zwischen Client- und Serveranwendungen, so beispielsweise E-Mail-Anwendungen.
  • Hintergrund der Erfindung
  • E-Mails sind zu einem wichtigen Verfahren der Kommunikation geworden. E-Mail-Systeme enthalten üblicherweise eine Server-Komponente (beispielsweise Exchange Server von Microsoft) und eine Client-Komponente (beispielsweise Gutlook oder Outlook Express von Microsoft). Diese Komponenten sind üblicherweise Softwareanwendungen, die derart konfiguriert sind, dass sie auf Computervorrichtungen (beispielsweise Servern, PCs, Laptops und PDAs) laufen.
  • Um Kommunikationsvorgänge zu vereinfachen, verwenden ein Client und ein Server, so beispielsweise eine Client-Komponente und eine Server-Komponente eines E-Mail-Systems, oftmals ein gemeinsames Kommunikationsprotokoll. Das Protokoll legt Regeln fest, die das erwartete Verhalten jeder Seite während der Kommunikation, so beispielsweise die erwartete Abfolge von Anforderungen und Antworten, definieren. Hochentwickelte Protokolle verfügen über Regeln für den Umgang mit unerwartetem Verhalten.
  • Werden Client- und Server-Komponenten verbessert, so werden die verbesserten Versionen an Endanwender verteilt. Wenn neue Komponentenmerkmale und Netzwerkmerkmale vorteilhaft eingesetzt werden sollen, tritt oftmals der Fall auf, dass ein neues Kommunikationsprotokoll entwickelt wird. Ist die installierte Basis von Server-Komponenten von Bedeutung, so kann eine Client-Komponente die Fähigkeit aufweisen, über eine Gruppe von Protokollen mit Server-Komponenten ausgewählter älterer Versionen zu kommunizieren.
  • Bisweilen tritt der Fall auf, dass neuere Protokolle auf früheren Protokollen aufbauen, anstatt dass sie diese in Gänze ersetzen. In einem derartigen Fall kann ein neueres Protokoll aus Protokollelementen aufgebaut werden, die aktiviert oder deaktiviert werden können, um die früheren Protokolle zu simulieren. Ist die installierte Basis von Client-Komponenten von Bedeutung, so kann eine Server-Komponente die Fähigkeit aufweisen, über ein Protokoll mit Client-Komponenten ausgewählter älterer Versionen zu kommunizieren.
  • Der Beitrag „Internet Message Access Protocol – Version 4rev1" von M. Crispin, veröffentlicht bei Internet Engineering Task Force, Request for Comments 2060, Dezember 1996, offenbart ein Internetnachrichtenzugriffsprotokoll, das einen Client in die Lage versetzt, auf elektronische E-Mail-Nachrichten auf einem Server zuzugreifen und diese zu verändern. IMAP4rev1 ermöglicht eine Veränderung von entfernt befindlichen Nachrichtenordern, die „Mailboxen" genannt werden, auf eine Weise, die zu den lokalen Mailboxen funktionell gleichwertig ist. IMAP4rev1 verfügt darüber hinaus über die Fähigkeit, dass sich ein offline befindlicher Client mit dem Server resynchronisiert.
  • IMAP4rev1 verfügt über Operationen zum Erstellen, Löschen und Umbenennen von Mailboxen; zum Suchen nach neuen Nachrichten; zum endgültigen Entfernen von Nachrichten; zum Setzen und Löschen von Flags; sowie zum Parsen, Suchen und selektiven Abrufen von Nachrichteneigenschaften, Texten und Teilen hiervon. Auf Nachrichten wird mit IMAP4rev1 unter Verwendung von Nummern zugegriffen. Diese Nummern sind entweder Nachrichtensequenznummern oder eindeutige Kennungen.
  • Die Aufgabe der vorliegenden Erfindung besteht darin, eine Rückmeldung an den E-Mail-Client hinsichtlich des Fortschrittes bei der Übertragung von E-Mail-Datenobjekten von dem E-Mail-Server an den E-Mail-Client zu geben.
  • Die Aufgabe wird durch den Gegenstand der unabhängigen Ansprüche gelöst. Bevorzugte Ausführungsbeispiele sind Gegenstand der abhängigen Ansprüche.
  • Die vorliegende Erfindung stellt ein System und ein Verfahren für eine verbesserte Client-Server-Kommunikation bereit. Insbesondere betrifft die vorliegende Erfindung ein verbessertes Protokoll, das für die Kommunikation zwischen einem Client und einem Server eingesetzt werden kann. Die Erfindung ist in einer E-Mail-Server-Umgebung von besonderer Bedeutung, wobei die hier beschriebenen Merkmale jedoch auch in anderen Client-Server-Netzwerken zum Einsatz kommen können.
  • Entsprechend einem Aspekt der vorliegenden Erfindung kann eine E-Mail-Server-Komponente Fehlerinformationen für ein Datenobjekt mit einem Fehler vorlegen, anstatt dass eine ganze Gruppe von Antworten aufgrund eines Fehlers in einem Datenobjekt ausgesondert wird. Die E-Mail-Server-Komponente kann von einer E-Mail-Client-Komponente eine Anforderung einer Vielzahl von E-Mail-Datenobjekten und eine Anzeige darüber erhalten, dass die E-Mail-Client-Komponente in der Lage ist, die E-Mail-Datenobjekte mit einem Fehler zu verarbeiten. Als Antwort auf die Anforderung und den Hinweis kann die E-Mail-Server-Komponente die Vielzahl von E-Mail-Datenobjekten abrufen und für jedes der E-Mail-Datenobjekte für den Fall, dass kein Fehler beim Öffnen des E-Mail-Datenobjektes auftritt, das E-Mail-Datenobjekt an die E-Mail-Client-Komponente senden. Tritt jedoch ein Fehler beim Öffnen des E-Mail-Datenobjektes auf, so sendet die E-Mail-Server-Komponente eine Fehlernachricht an die E-Mail-Client Komponente.
  • Entsprechend einem weiteren Aspekt der vorliegenden Erfindung kann eine E-Mail-Server-Komponente Fortschrittsdaten für eine E-Mail-Client-Komponente derart bereitstellen, dass die E-Mail-Client-Komponente den Fortschritt beim Herunterladen (Downloaden) von der E-Mail-Server-Komponente mitverfolgen kann. Die E-Mail-Client-Komponente sendet eine Anforderung einer Vielzahl von E-Mail-Datenobjekten und einen Hinweis darüber, dass die E-Mail-Client-Komponente in der Lage ist, Fortschrittsmodusdaten zu verarbeiten. Als Antwort auf die Anforderung und den Hinweis ruft die E-Mail-Server-Komponente die Vielzahl von E-Mail-Datenobjekten ab und stellt Fortschrittsmodusdaten für die E-Mail-Client-Komponente zusammen mit der Vielzahl von Datenobjekten bereit. Enthalten können die Fortschrittsmodusdaten die Größe der Vielzahl von E-Mail-Datenobjekten, die Größe jedes der Objekte, die Anzahl der Objekte sowie Informationen darüber, ob die Objekte Ordnerverknüpfungsinformationen, zusätzliche Informationen oder eine beliebige Kombination hieraus sind.
  • Entsprechend einem weiteren Aspekt der vorliegenden Erfindung kann eine von einer E-Mail-Client-Komponente gesendete Anforderung keine Beschränkung hinsichtlich der Größe einer Antwort auf die Anforderung anzeigen, was die E-Mail-Server-Komponente in die Lage versetzt, gegebenenfalls einen Puffer zu füllen. Die E-Mail-Client-Komponente sendet eine Vielzahl von Unteranforderungen innerhalb einer Anforderung, wobei jede Unteranforderung eine Operation in der E-Mail-Server-Komponente anfordert und Größeninformationen beinhaltet. Als Antwort auf jede Unteranforderung beschränkt, wenn die Größeninformationen eine Größenbeschränkung innerhalb eines von der E-Mail-Server-Komponente erwarteten Bereiches beinhaltet, die E-Mail-Server-Komponente eine Antwort auf die Größenbeschränkung. Beinhalten die Größeninformationen eine Größenbeschränkung außerhalb eines von der E-Mail-Server-Komponente erwarteten Bereiches, so sucht die E-Mail-Server-Komponente nach einer neuen Größenbeschränkung in den Größeninformationen. Die neue Größenbeschränkung kann willkürlich sein, so beispielsweise „den verfügbaren Puffer füllen".
  • Kurzbeschreibung der Zeichnung
  • 1 ist ein schematisches Diagramm von Computern, die über ein Netzwerk verbunden sind.
  • 2 ist ein schematisches Diagramm, das ein als Beispiel angegebenes Computersystem darstellt, das zur Implementierung eines Ausführungsbeispieles der Erfindung verwendet werden kann.
  • 3 ist ein schematisches Diagramm, das eine Umgebung mit mehreren Versionen sowohl von E-Mail-Client-Komponenten wie auch von E-Mail-Server-Komponenten darstellt.
  • 4 ist ein Protokolldiagramm, das ein Beispiel für eine Protokollverhandlungsprozedur zwischen einer E-Mail-Client-Komponente und einer E-Mail-Server-Komponente darstellt.
  • 5 ist ein schematisches Diagramm, das ein Beispiel für ein E-Mail-Netzwerk darstellt, in dem E-Mail-Client-Komponenten und E-Mail-Server-Komponenten Kommunikationspuffer mit fester Größe aufweisen.
  • 6A ist ein Protokolldiagramm, das ein als Beispiel angegebenes Protokoll zeigt, das zwei Anforderungs-Antwort-Zyklen zur Fertigstellung einer Schnellübertragungsoperation benötigt.
  • 6B ist ein Protokolldiagramm, das ein als Beispiel angegebenes Protokoll zeigt, das einen einzigen Anforderungs-Antwort-Zyklus zur Fertigstellung einer Schnellübertragungsoperation benötigt.
  • 7A ist ein Flussdiagramm, das eine als Beispiel angegebene Prozedur zum Senden eines E-Mail-Nachrichten-Körperbereiches an eine E-Mail-Client-Komponente zeigt.
  • 7B ist ein Flussdiagramm, das eine Prozedur zum Senden eines E-Mail-Nachrichten-Körperbereiches an eine E-Mail-Client-Komponente entsprechend einem Aspekt der vorliegenden Erfindung zeigt.
  • 8A ist ein Sequenzdiagramm, das einen Vollelementübertragungsmodus zeigt.
  • 8B ist ein Sequenzdiagramm, das einen ersten Kopfbereichsübertragungsmodus zeigt.
  • 8C ist ein Sequenzdiagramm, das einen Kopfbereichsnurübertragungsmodus zeigt.
  • 8D ist ein Sequenzdiagramm, das eine Ausnahme bei einem ersten Kopfbereichsübertragungsmodus und einem Kopfbereichsnurübertragungsmodus zeigt.
  • 9 ist ein schematisches Diagramm, das die mit der Zeit erfolgende Änderung einer Heim-E-Mail-Server-Komponente einer E-Mail-Client-Komponente zeigt.
  • 10 ist ein Protokolldiagramm, das ein als Beispiel angegebenes Protokoll zur Synchronisierung von E-Mail-Ordnern zwischen einer E-Mail-Client-Komponente und einer E-Mail-Server-Komponente zeigt.
  • 11A ist ein Flussdiagramm, das eine als Beispiel angegebene Prozedur zum Optimieren eines Teils eines Stateblob zeigt.
  • 11B ist ein Flussdiagramm, das eine Prozedur zum Optimieren eines Teils eines Stateblob entsprechend der vorliegenden Erfindung zeigt.
  • 12 ist ein schematisches Diagramm, das eine E-Mail-Ordner-Hierarchie darstellt.
  • 13 ist ein Protokolldiagramm, das ein als Beispiel angegebenes Protokoll zum Synchronisieren und Aufrechterhalten einer Synchronisierung eines E-Mail-Nachrichten-Speichers entsprechend einem Aspekt der vorliegenden Erfindung zeigt.
  • 14A ist ein Protokolldiagramm, das ein als Beispiel angegebenes Protokoll zum Kommunizieren von Fehlerinformationen auf Fernoperationsniveau zeigt.
  • 14B ist ein Protokolldiagramm, das ein als Beispiel angegebenes Protokoll zum Kommunizieren von Fehlerinformationen auf einer Pro-Nachricht-Grundlage entsprechend einem Aspekt der vorliegenden Erfindung zeigt.
  • 15A ist ein Flussdiagramm, das eine Prozedur zum Erzeugen von Fehlerinformationen auf Fernoperationsniveau zeigt.
  • 15B ist ein Flussdiagramm, das eine Prozedur zum Erzeugen von Fehlerinformationen auf einer Pro-Nachricht-Grundlage entsprechend einem Aspekt der vorliegenden Erfindung zeigt.
  • 16A ist ein Protokolldiagramm, das ein als Beispiel angegebenes Protokoll zum Ausführen einer Schnellübertragungsoperation zeigt.
  • 16B ist ein Protokolldiagramm, das ein als Beispiel angegebenes Protokoll zum Bereitstellen von Fortschrittsinformationen bei gleichzeitiger Ausführung einer Schnellübertragungsoperation entsprechend einem Aspekt der vorliegenden Erfindung zeigt.
  • 17A ist ein Flussdiagramm, das eine Prozedur zum Aussenden einer Gruppe von Nachrichten zeigt.
  • 17B ist ein Flussdiagramm, das eine Prozedur zum Aussenden einer Gruppe von Nachrichten zusammen mit Fortschrittsinformationen entsprechend einem Aspekt der vorliegenden Erfindung zeigt.
  • 18 ist ein schematisches Diagramm von mehreren E-Mail-Client-Komponenten, die als Ergebnis einer Änderung an demselben Datenobjekt in einer E-Mail-Server-Komponente benachrichtigt werden.
  • 19A ist ein Flussdiagramm, das eine Prozedur zum Benachrichtigen mehrerer Teilnehmer darstellt.
  • 19B ist ein Flussdiagramm, das eine Prozedur zum Benachrichtigen mehrerer Teilnehmer entsprechend einem Aspekt der vorliegenden Erfindung zeigt.
  • 20 ist ein Flussdiagramm, das eine Prozedur zum Bereitstellen einer E-Mail-Nachricht, die sich einer gewünschten Codeseite bedient, entsprechend einem Aspekt der vorliegenden Erfindung zeigt.
  • Detailbeschreibung der Erfindung
  • Vor einer Beschreibung der verschiedenen Ausführungsbeispiele der Erfindung erfolgt zunächst eine Beschreibung der Computer- und Netzwerkumgebung, in der die verschiedenen Ausführungsbeispiele der Erfindung in die Praxis umgesetzt werden können. Obwohl nicht erforderlich, kann die vorliegende Erfindung durch Programme implementiert werden, die von einem Computer ausgeführt werden. Im Allgemeinen enthalten Programme Routinen, Objekte, Komponenten, Datenstrukturen und dergleichen, die bestimmte Aufgaben ausführen oder bestimmte abstrakte Datentypen implementieren. Der Begriff „Programm" bezeichnet im Sinne der vorliegenden Beschreibung ein einzelnes Programmmodul oder mehrere Programmmodule, die zusammenarbeiten. Der Begriff „Computer" beinhaltet im Sinne der vorliegenden Beschreibung eine beliebige Vorrichtung, die ein oder mehrere Programme elektronisch ausführt, so beispielsweise Personalcomputer (PCs), handbasierte Vorrichtungen, Multiprozessorsysteme, mikroprozessorbasierte programmierbare Geräte der Unterhaltungselektronik, Netzwerk-PCs, Minicomputer, Flach-PCs, Mainframecomputer, Geräte der Unterhaltungselektronik mit einem Mikroprozessor oder Mikrokontroller, Router, Gateways, Knotenpunkte und dergleichen mehr. Die Erfindung kann auch in verteilten Computerumgebungen eingesetzt werden, wo Aufgaben von entfernt befindlichen Verarbeitungsvorrichtungen ausgeführt werden, die über ein Kommunikationsnetzwerk verbunden sind. In einer verteilten Computerumgebung können sich Programme sowohl in lokalen wie auch in entfernt befindlichen Speicherablagevorrichtungen befinden.
  • Ein Beispiel für eine Netzwerkumgebung, in der die Erfindung verwendet werden kann, wird nachstehend unter Bezugnahme auf 1 beschrieben. Das als Beispiel angegebene Netzwerk beinhaltet mehrere Computer 10, die miteinander über ein Netzwerk 11, das durch eine Wolke dargestellt ist, kommunizieren. Das Netzwerk 11 kann viele bekannte Komponenten beinhalten, so beispielsweise Router, Gateways, Knotenpunkte und dergleichen mehr, und versetzt die Computer 10 in die Lage, über drahtgebundene und/oder drahtlose Medien miteinander zu kommunizieren. Bei einem wechselseitigen Austausch über das Netzwerk 11 kann ein oder können mehrere der Computer als Clients, Server oder Peers für die anderen Computer dienen. Entsprechend können die verschiedenen Ausführungsbeispiele der Erfindung auf Clients, Servern, Peers oder Kombinationen hieraus ausgeführt werden, obwohl spezifische hier dargestellte Beispiele nicht alle der genannten Arten von Computern betreffen.
  • In 2 ist ein Beispiel für eine grundlegende Konfiguration eines Computers gezeigt, in der die gesamte Erfindung oder Teile derselben gemäß vorliegender Beschreibung implementiert werden können. In der grundlegendsten Konfiguration beinhaltet der Computer 10 üblicherweise wenigstens eine Verarbeitungseinheit 14 und einen Speicher 16. Die Verarbeitungseinheit 14 führt entsprechend verschiedenen Ausführungsbeispielen der Erfindung Befehle aus, damit Aufgaben ausgeführt werden können. Beim Ausführen derartiger Aufgaben kann die Verarbeitungseinheit 14 elektronische Signale an andere Teile des Computers 10 und an Vorrichtungen außerhalb des Computers 10 senden, um ein bestimmtes Ergebnis hervorzurufen. In Abhängigkeit von der genauen Konfiguration und der Art des Computers 10 kann der Speicher 16 flüchtig (so beispielsweise bei einem RAM), nichtflüchtig (so beispielsweise bei einem ROM oder Flash-Speicher) oder eine Kombination aus beidem sein. Diese grundlegendste Konfiguration ist in 2 mit der gestrichelten Linie 18 bezeichnet. Darüber hinaus kann der Computer auch zusätzliche Merkmale beziehungsweise eine zusätzliche Funktionalität aufweisen. So kann der Computer 10 beispielsweise einen zusätzlichen Speicher (entfernbar 201 und/oder nichtentfernbar 202) umfassen, darunter, jedoch nicht hierauf beschränkt, magnetische oder optische Platten oder Bänder. Zu den Computerspeichermedien zählen flüchtige und nichtflüchtige, entfernbare und nichtentfernbare Medien, die durch ein beliebiges Verfahren oder eine beliebige Technologie zum Speichern von Informationen implementiert sind, darunter durch Computer ausführbare Befehle, Datenstrukturen, Programmmodule oder andere Daten. Zu den Computerspeichermedien zählen unter anderem RAM, ROM, EEPROM, Flash-Speicher, CD-ROM, DVD (Digitale Versstile Disc DVD, vielseitig einsetzbare Platte) oder andere optische Speicher, magnetische Kassetten, magnetische Bänder, magnetische Plattenspeicher oder andere magnetische Speichervorrichtungen oder ein beliebiges anderes Medium, das zur Speicherung der gewünschten Informationen verwendet werden kann und auf das von dem Computer 10 zugegriffen werden kann. Ein beliebiges derartiges Computerspeichermedium kann Teil des Computers 10 sein.
  • Der Computer 10 enthält zudem vorzugsweise Kommunikationsverbindungen 205, die die Vorrichtung in die Lage versetzen, mit anderen Vorrichtungen zu kommunizieren. Eine Kommunikationsverbindung ist ein Beispiel für ein Kommunikationsmedium. Die Kommunikationsmedien verkörpern üblicherweise von Computern lesbare Befehle, Datenstrukturen, Programmmodule und andere Daten in einem modulierten Datensignal, so beispielsweise einer Trägerwelle oder einem anderen Transportmechanismus, und beinhalten beliebige Informationsverteilungsmedien. Als Beispiel hierfür, jedoch nicht im Sinne einer Beschränkung, beinhaltet der Begriff „Kommunikationsmedien" drahtgebundene Medien, so beispielsweise ein drahtgebundenes Netzwerk oder eine direkt drahtgebundene Verbindung, und drahtlose Medien, so beispielsweise akustische, funkfrequenzbasierte, infrarotbasierte und andere drahtlose Medien. Der Begriff „computerlesbares Medium" beinhaltet im Sinne der vorliegenden Beschreibung sowohl Computerspeichermedien wie auch Kommunikationsmedien.
  • Der Computer 10 kann zudem über Eingabevorrichtungen 204 verfügen, so beispielsweise über eine Tastatur, eine Maus, einen Stift, eine Spracheingabevorrichtung, eine berührungsempfindliche Eingabevorrichtung und dergleichen mehr. Ausgabevorrichtungen 203, so beispielsweise eine Anzeige 20, Lautsprecher, ein Drucker und dergleichen, können ebenfalls beinhaltet sein. All diese Vorrichtungen sind aus dem Stand der Technik bekannt und werden daher nicht ausführlich erläutert.
  • Die vorliegende Erfindung betrifft ein System und ein Verfahren für verbesserte Kommunikation zwischen Clients und Servern und insbesondere ein verbessertes Protokoll, das für die Kommunikation zwischen einem Client und einem Server eingesetzt werden kann. Die Erfindung ist für eine E-Mail-Server-Umgebung besonders relevant, wobei jedoch Merkmale aus der vorliegenden Beschreibung auch in anderen Client- und Server-Netzwerken verwendet werden können. Um die Beschreibung zu vereinfachen, wird die Erfindung gleichwohl anhand einer Client-Server-Umgebung beschrieben.
  • Die vorliegende Erfindung kann in einer Client-Server-Umgebung mit zwei oder mehr Versionen von Client-Anwendungen oder -komponenten und/oder zwei oder mehr Versionen von Server-Anwendungen oder -komponenten implementiert werden. Hierzu zeigt 3 ein Blockdiagramm, das mehrere Versionen sowohl von Client- wie auch von Server-Komponenten in einer Netzwerk-E-Mail-Umgebung zeigt. Im Allgemeinen sind die Client- und Server-Komponenten derart konfiguriert, dass sie rückwärtskompatibel sind. Dies bedeutet, dass eine Client-Komponente in der Lage ist, mit aktuellen und älteren Versionen von Server-Komponenten zu kommunizieren, und umgekehrt. Eine Gruppe von Protokollen wird für die Kommunikation zwischen den verschiedenen Versionen eingerichtet. Die Gruppe von Protokollen kann mehrere verschiedene Protokolle bilden, von denen jedes für sich allein steht. Alternativ kann eine Gruppe von Protokollkomponenten verfügbar sein, wobei bestimmte Komponenten zur Konfiguration bestimmter Protokolle innerhalb der Protokollgruppe verwendet werden.
  • In jedem Fall kommuniziert in der in 3 gezeigten Netzwerk-E-Mail-Umgebung eine E-Mail-Client-Komponente 303 einer aktuellen Version am besten mit einer E-Mail-Server-Komponente 306 einer aktuellen Version über ein Protokoll 307. Die aktuelle E-Mail-Server-Komponente 306 ist jedoch auch in der Lage, mit ausgewählten E-Mail-Client-Komponenten einer älteren Version, so beispielsweise die E-Mail-Client-Komponente 302 und die E-Mail-Server-Komponente 301, über andere Protokolle (beispielsweise die Protokolle 308 und 309 in 3) in einer Protokollgruppe zu kommunizieren. Die E-Mail-Client-Komponente 303 ist zudem in der Lage, mit ausgewählten E-Mail-Server-Komponenten einer älteren Version, beispielsweise die E-Mail-Server-Komponente 305 und die E-Mail-Server-Komponente 304, unter Verwendung von Protokollen, so beispielsweise der Protokolle 310 und 311, zu kommunizieren.
  • Zum Zwecke der Beschreibung des Protokolls der vorliegenden Erfindung ist eine „aktuelle" E-Mail-Server-Komponente oder E-Mail-Client-Komponente oder eine aktuelle Version einer E-Mail-Server-Komponente oder einer E-Mail-Client-Komponente eine Serveroder Client-Komponente, die Kenntnis von dem neuen Merkmal oder den neuen Merkmalen der Beschreibung besitzt und diese Merkmale verwenden, implementieren und/oder darauf einwirken kann. Obwohl die Begriffe in der vorliegenden Druckschrift zur Beschreibung von Client- und Server-Komponenten verwendet werden, die Kenntnis von verschiedenen Aspekten des Protokolls der vorliegenden Erfindung besitzen, beinhalten die Begriffe ebenfalls Komponenten, die Kenntnis lediglich von einem bestimmten beschriebenen Aspekt oder von mehr als einem beschriebenen Aspekt besitzen. Auf gleiche Weise ist eine „ältere" E-Mail-Komponente oder eine ältere Version einer E-Mail-Komponente eine Komponente, die keine Kenntnis von den Aspekten des Protokolls der vorliegenden Erfindung besitzt und hierauf nicht einwirken kann.
  • Eine Protokollverhandlungsprozedur wird oftmals zum Erstellen eines Protokolls zwischen einem Client und einem Server verwendet (beispielsweise die E-Mail-Server-Komponente 306 der aktuellen Version und die E-Mail-Client-Komponente 303 der aktuellen Version). Obwohl derartige Protokollverhandlungen bekannt sind, erfolgt zur Unterstützung des Lesers eine kurze Beschreibung einer Protokollverhandlungsprozedur zwischen einer E-Mail-Client-Komponente 401 (4) und einer E-Mail-Server-Komponente 402 (ebenfalls 4). Gleich zu Beginn einer Kommunikationssitzung zwischen der E-Mail-Client-Komponente 401 und der E-Mail-Senner-Komponente 402 sendet die E-Mail-Client-Komponente 401 an die E-Mail-Server-Komponente 402 eine Nachricht 403, die Informationen über die Client-Version, beispielsweise in Form eines Versionsstempels der Client-Komponente, beinhaltet. Die E-Mail-Server-Komponente 402 antwortet auf die Nachricht 403 mit einer Nachricht 404, die Server-Versionsinformationen beispielsweise in Form eines Versionsstempels der Server-Komponente beinhaltet.
  • Die Client- und Server-Versionsinformationen können auf vielerlei Arten bei dem Versuch verwendet werden, eine Kommunikation zwischen der E-Mail-Client-Komponente 401 und der E-Mail-Server-Komponente 402 aufzubauen. Die Versionsinformationen können beispielsweise zur Auswahl eines geeigneten Protokolls für eine fortwährende Kommunikation oder für eine Bestimmung dahingehend verwendet werden, ob sogar weitere Kommunikationsvorgänge möglich sind. Beim Erstellen eines Protokolls können Versionsinformationen verwendet werden, um beispielsweise nur bestimmte verfügbare Protokollaspekte oder -komponenten zu aktivieren und/oder zu deaktivieren.
  • Eine E-Mail-Server-Komponente kann Anforderungen von mehreren E-Mail-Client-Komponenten parallel empfangen und verarbeiten. Ist nur ein einzelner Client gezeigt, so dient dies, außer es ist explizit anders dargestellt, nur dem Zweck, die Figuren und die zugehörige Erklärung zu vereinfachen.
  • Das E-Mail-Netzwerk der vorliegenden Erfindung verwendet Anforderungs- und Antwort-Austauschvorgänge, um Anfragen und Daten zwischen Client- und Server-Komponenten in dem Netzwerk weiterzuleiten. In der Praxis beruht das Leistungsvermögen eines Protokolls auf dem darunterliegenden Kommunikationsnetzwerktransportmechanismus, der zur Implementierung von Kommunikationsvorgängen zwischen Clients und Servern in einem E-Mail-Netzwerk implementiert ist. In einem E-Mail-Netzwerk, bei dem Fernprozedurabrufe (remote procedure calls RPCs) als zugrundeliegender Kommunikationsnetzwerktransportmechanismus zum Einsatz kommen, kann es beispielsweise sehr viel effi zienter sein, einen einzelnen Fernprozedurabruf höherer Größe (beispielsweise 32 KB) als mehrere Fernprozedurabrufe geringerer Größe (beispielsweise 2 KB) zu tätigen. Eine zur Verbesserung des Leistungsvermögens in einem derartigen E-Mail-Netzwerk bekannte Vorgehensweise besteht in der Pufferung mehrerer Anforderungen und/oder Antworten zur Sendung in einem einzelnen Fernprozeduranruf.
  • 5 zeigt als ein Beispiel einen Anforderungs- und Antwort-Austauschvorgang zwischen einer E-Mail-Client-Komponente 501 und einer E-Mail-Server-Komponente 502. Die E-Mail-Client-Komponente 501 und die E-Mail-Server-Komponente 502 weisen jeweils Kommunikationspuffer 503, 504, 505 und 506 fester Größe auf. Die Puffer 503, 504, 505 und 506 sind reservierte Speicherbereiche zum vorübergehenden Vorhalten von Daten. Die E-Mail-Client-Komponente 501 beginnt mit einem Anforderungs-Antwort-Zyklus durch Füllen des Puffers 503 mit einer oder mehreren Unteranforderungen oder Fernoperationen (remote operations ROPs) vor dem Senden der Inhalte des Puffers 503 an den Puffer 504.
  • Nach dem Empfang in dem Puffer 504 wird jede Fernoperation von der E-Mail-Server-Komponente 502 verarbeitet und das entsprechende Ergebnis in den Puffer 505 geschrieben. Jede Fernoperation ROP erzeugt das gleiche Ergebnis. Das Ergebnis kann Daten aus der Anforderung durch die E-Mail-Client-Komponente 501 beinhalten, so beispielsweise eine bestimmte Gruppe von E-Mail-Nachrichten. Die E-Mail-Server-Komponente 502 überwacht den Puffer 505, wobei die E-Mail-Server-Komponente 502, wenn der Puffer 505 beinahe voll ist (wenn beispielsweise weniger als 8 KB verbleiben) alle unverarbeiteten Fernoperationen ROP an das Ende des Puffers 505 schreibt und den Puffer 505 an den Puffer 506 sendet. Die E-Mail-Client-Komponente 501 beginnt dann mit einem neuen Anforderungs-Antwort-Zyklus durch Schreiben der unverarbeiteten Fernoperationen ROPs in den Puffer 503 zur Wiedervorlage bei der E-Mail-Server Komponente 502, wenn der Puffer 503 wieder voll ist.
  • Die Größe einer Antwort ist im Durchschnitt üblicherweise größer als die Größe einer Anforderung. Aus diesem Grunde ist die Größe der Antwortpuffer 506, 505 üblicherweise derart konfiguriert, dass sie größer als die Größe der Anforderungspuffer 503 und 504 ist. Bei einem Ausführungsbeispiel der Erfindung wurde bestimmt, dass die optimale Größe der Antwortpuffer 505 und 506 gleich 96 KB für ein Größe der Anforderungspuffer 503 und 504 von 32 KB ist, was einem Verhältnis von 3:1 entspricht. Bei einem Ausfüh rungsbeispiel ist die E-Mail-Client-Komponente in der Lage, die Größe eines beliebigen der Puffer 503, 504, 505 und 506 zu konfigurieren.
  • Einige E-Mail-Netzwerke, bei denen Puffer zum Einsatz kommen, so beispielsweise das in 5 gezeigte E-Mail-Netzwerk, können sich eines Schnellübertragungsmodus zwischen einer E-Mail-Client-Komponente und einer E-Mail-Server-Komponente bedienen. Der Schnellübertragungsmodus beinhaltet Anforderungen, so beispielsweise Fernoperationen ROPs, von einem Client, die in wenigstens zwei Arten unterteilt werden, nämlich Anforderungen, die zu einer Initialisierung einer Schnellübertragungsdatenquelle an dem Server führen, und Anforderungen, die zu einer effizienteren Datenübertragung von der Schnellübertragungsdatenquelle an den Client führen. Die Schnellübertragungsdatenquelle kann beispielsweise eine Datenbanktabelle sein. Die Schnellübertragungsdatenquelle dient als bereitstehender vorübergehender Datenspeicher, durch den ermöglicht wird, dass die Bearbeitung von späteren Datenanforderungen mit einer geringeren Verzögerung erfolgt, als dies anderweitig der Fall wäre. Bisweilen erreicht die zweite Art von Schnellübertragungsmodusanforderung tendenziell eine effiziente Datenübertragung durch explizites Spezifizieren der Größe der Antwort. So kann die Größe der Antwort beispielsweise auf die Größe des gesamten Client-Empfangspuffers eingestellt werden.
  • 6A zeigt eine Schnellübertragungsoperation mit wenigstens zwei Anforderungs-Antwort-Zyklen. In einer ersten Anforderung 601 initialisiert eine Fernoperation ROP (beispielsweise FXPrepare) eine Schnellübertragungsdatenquelle an einem Server 502. An dem Server wird nur FXPrepare verarbeitet (das heißt, die Schnellübertragungsdatenquelle wird initialisiert), und das Ergebnis wird in einer ersten Antwort 602 ausgegeben. In einer zweiten Anforderung 603 fordert eine Fernoperation ROP (beispielsweise FXGetBuffer) den Server auf, den Puffer 505 aus der Schnelldatenquelle zu füllen. Der Server leert die Schnelldatenquelle in den Puffer und gibt das Ergebnis in einer zweiten Antwort 604 aus. Füllt sich der Ausgabepuffer 505 der E-Mail-Server-Komponente, bevor die Schnelldatenquelle geleert ist, so können zusätzliche Fernoperationen FXGetBuffer erforderlich sein.
  • 6B zeigt eine Schnellübertragungsoperation mit nur einem einzigen Anforderungs-Antwort-Zyklus. In einer ersten Anforderung 605 werden sowohl FXPrepare wie auch FXGetBuffer von der E-Mail-Server-Komponente 502 verarbeitet, woraufhin die Ergebnisse der beiden Operationen in einer ersten Antwort 606 ausgegeben werden. Das Ergebnis von FXPrepare ist für FXGetBuffer in der E-Mail-Server-Komponente 502 verfüg bar, da ein Teil jedes Puffers 503, 504, 505 und 506 explizit in einer gemeinsam genutzten Datentabelle definiert ist. Es ist wünschenswert, die Anzahl der Anforderungs-Antwort-Zyklen zu verringern, da dies zu einer effizienteren Übertragung der Daten führt. Eine Schnellübertragungsoperation mit mehr als nur einem einzigen Anforderungs-Antwort-Zyklus kann auftreten, wenn der Puffer 505 zu voll ist, als dass er das Ergebnis der Fernoperation FXGetBuffer noch vorhalten könnte.
  • Es ist einsichtig, dass die Fernoperationen gemäß 6A und 6B sowie entsprechender Figuren in der vorliegenden Beschreibung dahingehend schematisch sind, dass sie in der Praxis auch durch eine Reihe von Fernoperationen implementiert werden können, es sei denn, dies ist explizit anders angegeben.
  • Üblicherweise unterscheidet sich die Größe eines Fernoperationsergebnisses von der Größe einer Fernoperationsanforderung. Es ist nicht immer möglich, die Größe eines Fernoperationsergebnisses vorauszusagen. Werden Datenkompressionstechniken zur Verringerung der Größe eines Fernoperationsergebnisses eingesetzt, wird es sogar noch schwieriger, die Größe eines Fernoperationsergebnisses vorherzusagen. Der Umstand, dass man nicht in der Lage ist, die Größe eines Fernoperationsergebnisses vorauszusagen, kann ein manuelles Nachbearbeiten eines Protokolls zum Zwecke der Minimierung der Anzahl der Anforderungs-Antwort-Zyklen verhindern, die zur Vervollständigung bestimmter Client-Operationen notwendig sind, so beispielsweise zur Sicherstellung, dass alle neuen Nachrichten bei einem Client in einem einzigen Anforderungs-Antwort-Zyklus heruntergeladen werden. Ein manuelles Nachbearbeiten eines Protokolls beinhaltet das manuelle Konfigurieren der Abfolge und/oder Größe der Protokollanforderungen, -antworten und/oder der Fernoperationen.
  • Entsprechend einem Aspekt der vorliegenden Erfindung wird die Anzahl der Anforderungs-Antwort-Zyklen automatisch durch eine Spezifizierung dahingehend minimiert, dass Schlüsselfernoperationen (beispielsweise FXGetBuffer) nicht der Bedingung unterliegen, dass die Größe ihres Ergebnisses vorhergesagt werden muss. Anstelle dessen werden derartige Fernoperationen von der E-Mail-Server-Komponente 502 verarbeitet, bis die Beschränkung des Puffers 505 (die dieselbe wie diejenige des Puffers 506 ist) erreicht wird.
  • Als ein Beispiel sei angeführt, dass in einer Umgebung, die mehrere Versionen von E-Mail-Server-Komponenten beinhaltet, gesonderte Fernoperationen für Server-Kompo nenten einer älteren Version und Server-Komponenten einer aktuellen Version definiert sein können. Die älteren Versionen unterliegen nicht der Bedingung, dass die Größe ihres Ergebnisses vorhergesagt werden muss. Die Eigenschaften dieser Fernoperationen sind in der nachfolgenden Tabelle dargestellt.
    Fernoperation, die von einem Protokoll zur Kommunikation mit Servern einer älteren Version verwendet werden kann Fernoperation, die von einem Protokoll zur Kommunikation mit Servern einer aktuellen Version verwendet werden kann
    Kennung (ID) der Fernoperation (ROP) FXGetBuffer FXGetBuffer
    Parameter, die in mehreren Modi verwendet werden Erforderliche Größe: Größe, die der Server in seinem Ausgabepuffer reservieren muss Erforderliche Größe: wird auf eine Größe jenseits des von der älteren Version erwarteten Maximums eingestellt, so beispielsweise auf einen Wert von mehr als 32 KB. Hierdurch wird dem Server signalisiert, nach dem neuen Größenbeschränkungsparameter zu suchen.
    Neue Parameter n/a Größenbeschränkung: informiert den Server über die Schranke, bis zu der der Server seinen Ausgabepuffer füllen kann
  • Die Fernoperationen für Server-Komponenten einer älteren Version sind dem Aufbau nach zu den bestehenden aus dem Stand der Technik bekannten Fernoperationen ähnlich. Dies bedeutet, dass die Fernoperationen die Größe in dem Ausgabepuffer (beispielsweise dem Sendepuffer 505), der zum Vorhalten einer Antwort reserviert bleiben muss, vorhersagen und vorgeben. Demgegenüber wird die vorgegebene Größe für den Ausgabepuffer bei einer aktuellen Version einer Server-Komponente nicht vorhergesagt, sondern es wird anstelle dessen ein Wert jenseits des von den Server-Komponenten einer älteren Version erwarteten Maximums eingestellt, so beispielsweise ein Wert, der größer als 32 KB ist. Der Umstand, dass die Größe des Ausgabepuffers jenseits eines von der Server-Komponente erwarteten Wertes liegt, signalisiert der Server-Komponente, nach einem neuen Größenbeschränkungsparameter zu suchen, der beispielsweise eine Füllung des Ausgabepuffers für die Server-Komponente sein kann. Diese Eigenschaften minimieren automatisch die Anzahl der Anforderungs-Antwort-Zyklen, wobei nur eine kleine Zunahme der Komplexität der E-Mail-Server-Komponente, die die Fernoperationen verarbeitet, auftritt.
  • Man beachte, dass die Reihenfolge der in der vorstehenden Tabelle und in den entsprechenden Tabellen der vorliegenden Beschreibung gezeigten Parameter nicht zwangsläufig mit der Reihenfolge korreliert, mit der beispielsweise die Parameter über das Netzwerk gesendet und oder entweder von einer E-Mail-Client-Komponente oder einer E-Mail-Server-Komponente gespeichert werden, es sei denn, es wird explizit anders gesagt. Darüber hinaus können unveränderte Parameter zum Zwecke einer einfacheren Darstellung weggelassen werden.
  • In einem E-Mail-Netzwerk besteht eine der typischen Aufgaben eines Protokolls darin, die Übertragung von Datenobjekten, so beispielsweise von E-Mail-Nachrichten, zwischen E-Mail-Client-Komponenten und E-Mail-Server-Komponenten zu bewerkstelligen. Weitere Beispiele für derartige Datenobjekte sind unter anderem E-Mail-Ordner, die E-Mail-Nachrichten und andere Datenobjekte enthalten können, und FAI-Datenobjekte (folder associated information FAI, Ordnerverknüpfungsinformation), die beispielsweise Regeln zur Verarbeitung von E-Mail-Nachrichten dahingehend enthalten oder definieren können, wie in einem Ordner enthaltene Datenobjekte angezeigt werden. Datenobjekte können für eine E-Mail-Client-Komponente blind sein, was bedeutet, dass eine E-Mail-Client-Komponente gegebenenfalls nicht über Mittel zur Deutung der Inhalte des Datenobjektes verfügt. Alternativ können Datenobjekte aus benannten Eigenschaften zusammengesetzt sein. So kann eine E-Mail-Nachricht beispielsweise Eigenschaften mit den Namen „to", „from", „subject", „importance", „body 1", „body 2", „body 3", „attachment 1", „attachment 2" und dergleichen mehr enthalten.
  • Ein Vorteil von E-Mail-Netzwerken, in denen Datenobjekte aus benannten Eigenschaften über E-Mail-Netzwerke zusammengesetzt sind, in denen Datenobjekte blind sind, ist die Möglichkeit, das Leistungsvermögen eines Protokolls aufgrund der Fähigkeit des Protokolls, nur einen Teil eines Datenobjektes zu übertragen, zu verbessern. Der Umstand, dass benannte Eigenschaften vorhanden sind, ermöglicht, dass bestimmte Eigenschaften des Datenobjektes ohne Senden des gesamten Datenobjektes gesendet werden.
  • So kann eine E-Mail-Nachricht beispielsweise aus einer Gruppe von Kopfbereichseigenschaften (header properties) und einer Gruppe von Körperbereichseigenschaften (body properties) zusammengesetzt sein. Für eine E-Mail-Client-Komponente kann es hierbei notwendig sein, dass ein Protokoll zuerst die Kopfbereichseigenschaften und anschließend oder überhaupt nicht die Körperbereichseigenschaften überträgt. Dieses Merkmal versetzt einen Anwender in die Lage, die Kopfbereichsinformationen von mehreren Nachrichten durchzusehen, bevor die Nachrichten allesamt heruntergeladen werden. Unter Verwendung dieses Merkmals ist eine genauere Einflussnahme auf die Bandbreitennutzung durch die Client-Komponente erreichbar, was positive Auswirkungen auf das Leistungsvermögens des Protokolls haben kann. Darüber hinaus kann sich eine Client-Komponente dieses Merkmals bedienen, um eine Nutzung einer niedrigeren Bandbreite herbeizuführen (So können beispielsweise Körperbereiche nur für ausgewählte Kopfbereiche heruntergeladen werden), was insbesondere bei Umgebungen mit niedriger Bandbreite wünschenswert ist.
  • Das Leistungsvermögen des Protokolls nimmt nicht notwendigerweise zu, wenn die Server-Komponente derart konfiguriert ist, dass Kopfbereichs- und Körperbereichseigenschaften in zwei gesonderten Anforderungs-Antwort-Zyklen (das heißt jeweils einem für den Kopfbereich und einem für den Körperbereich) gesendet werden. Ist es beispielsweise für die E-Mail-Client-Komponente notwendig, dass diese sowohl Kopfbereichs- wie auch Körperbereichseigenschaften gleichzeitig benötigt, so kann das Leistungsvermögen des Protokolls im Gegensatz zu einer Situation abnehmen, in der ein einzelner Anforderungs-Antwort-Zyklus sowohl den Kopfbereich wie auch den Körperbereich abruft. Der einfache Umstand, dass Datenobjekte aus benannten Eigenschaften zusammengesetzt sein können, ist damit per se nicht ausreichend, um automatisch zu einem verbesserten Leistungsvermögen des Protokolls zu kommen. Ein verbessertes Leistungsvermögen des Protokolls zu erreichen hängt nicht von der Wahl der Eigenschaften ab, die ein Datenobjekt darstellen, sowie davon, wie sie von einem Protokoll verwendet werden. Die Wahl kann von einer Anzahl von Faktoren abhängen, darunter einem Faktor dahingehend, was für die E-Mail-Client-Komponenten der aktuellen und der älteren Versionen von Nöten ist, sowie davon, was für die E-Mail-Server-Komponenten der aktuellen und der älteren Versionen von Nöten ist. Beispiele für das, was für eine E-Mail-Client-Komponente von Nöten ist, sind das Eingehen auf verschiedene Dringlichkeitsniveaus für die Anzeige von verschiedenen Informationen und das Eingehen auf Präferenzen, die von einem Anwender der E-Mail-Client-Komponente eingestellt worden sind. Zu den Beispielen für das, was für eine E-Mail-Server-Komponente notwendig ist, zählen effizientes Speichern und Abrufen von Daten und effizientes Verarbeiten von Protokollanforderungen.
  • Gängige E-Mail-Umgebungen aus dem Stand der Technik verwenden Datenobjekte, die aus benannten Eigenschaften zusammengesetzt sein können, so beispielsweise eine E-Mail-Nachricht, die eine Kopfbereichsgruppe und eine Körperbereichsgruppe aus benannten Eigenschaften beinhalten kann, sodass die beiden Gruppen getrennt angefordert und/oder verarbeitet werden können. Ein weiteres Beispiel aus dem Stand der Technik ist eine E-Mail-Nachricht, bei der die Körperbereichsgruppe aus benannten Eigenschaften mehrere Versionen des E-Mail-Nachrichten-Körperbereiches beinhaltet, so beispielsweise bei mehreren Formaten für E-Mail-Nachrichten wie Volltext (plain text), HTML (hypertext mark-up language HTML, Hypertextmarkiersprache), RTF (rich text formst RTF, Format mit angereichertem Text) und dergleichen mehr. In dieser Situation können die E-Mail-Server-Komponenten aus dem Stand der Technik auf eine Protokollanforderung des Körperbereiches der E-Mail-Nachricht auf mehrere Weisen antworten. Die Antwort mit der niedrigsten Komplexität kann darin bestehen, dass alle Versionen des Körperbereiches der E-Mail-Nachricht gesendet werden, wobei diese Antwort jedoch zur Nutzung einer erhöhten Bandbreite führen kann.
  • 7A zeigt einen Teil einer Prozedur, bei der sich eine E-Mail-Server-Komponente einer älteren Version (Stand der Technik) in dieser Situation einer Antwort bedient. In Schritt 701 untersucht die E-Mail-Server-Komponente das Format jedes Körperbereiches der E-Mail-Nachricht. Ist eines der Formate ein vorbestimmtes Standardformat (so beispielsweise RTF), so bewegt sich die Prozedur zu Schritt 703, und der Kopfbereich der E-Mail-Nachricht im Standardformat wird an die anfordernde E-Mail-Client-Komponente gesendet. Ist keines der Formate ein vorbestimmtes Standardformat, so geht Schritt 701 zu Schritt 702 über, wo eine der Versionen des Kopfbereiches der E-Mail-Nachricht in das Standardformat umgewandelt wird. Die in 7A dargestellte Unterprozedur kann auch dann verwendet werden, wenn nur eine einzige Version des Kopfbereiches einer E-Mail-Nachricht vorhanden ist, der Kopfbereich der E-Mail-Nachricht jedoch gegebenenfalls nicht in demjenigen Standardformat vorliegt, das von einem Protokoll benötigt wird.
  • 7B zeigt einen Teil einer Prozedur, die von einer E-Mail-Server-Komponente einer aktuellen Version entsprechend der vorliegenden Erfindung verwendet wird. In Schritt 704 wird eine Protokollanforderung, die zu dieser von einer E-Mail-Server-Komponente verwendeten Unterprozedur führt, nach einem BEST_BODY-Flag durchsucht. Das Flag in diesem Beispiel genauso wie die anderen hier verwendeten Flags für die E-Mail-Server-Komponente werden dahingehend verwendet, dass die E-Mail-Client-Komponente eine aktuelle Version ist und die Implementierung der mit dem Flag verknüpften Funktion wünscht. Andere Hinweise können verwendet werden. So kann die Funktion beispielsweise durch Standardvorgabe (default) implementiert werden, wenn eine aktuelle E-Mail-Client-Komponente erfasst wird.
  • Wird das BEST_BODY-Flag nicht gefunden, so geht Schritt 704 in jedem Fall zu Schritt 701 über, und es wird fortgefahren, wie anhand von 7A beschrieben worden ist.
  • Wird das Flag gefunden, so geht die Prozedur zu Schritt 705 über, wo der beste E-Mail-Nachrichten-Körperbereich zum Senden an die anfordernde E-Mail-Client-Komponente ausgewählt wird. Ist nur ein einziger Kopfbereich der E-Mail-Nachricht vorhanden, der mit der angeforderten E-Mail-Nachricht verknüpft ist, so ist dieser der beste. Sind mehrere Kopfbereiche von E-Mail-Nachrichten vorhanden, so beispielsweise in verschiedenen Formaten, so wählt die E-Mail-Server-Komponente die beste unter ihnen beispielsweise entsprechend einer vorbestimmtem Rangordnung der Formate des Kopfbereiches der E-Mail-Nachricht aus (beispielsweise RTF, HTML, Volltext). Der Prozess geht sodann zu Schritt 703 über, wo der ausgewählte Körperbereich der E-Mail-Nachricht an die E-Mail-Client-Komponente gesendet wird. Bei diesem Ausführungsbeispiel kann die E-Mail-Client-Komponente in der Lage sein, mehrere Formate von Körperbereichen von E-Mail-Nachrichten anzuzeigen, sodass die E-Mail-Server-Komponente nicht der Bedingung unterworfen ist, die Körperbereiche von E-Mail-Nachrichten in ein Standardformat umzuwandeln. Darüber hinaus kann die E-Mail-Client-Komponente den besten Körperbereich der E-Mail-Nachricht gegebenenfalls in ein anderes Format umwandeln.
  • Da die E-Mail-Server-Komponente von der Aufgabe befreit ist, die Körperbereiche der E-Mail-Nachrichten umzuwandeln, weist die vorliegende Erfindung ein verbessertes Leistungsvermögen auf. Darüber hinaus kann eine E-Mail-Server-Komponente einer aktuellen Version auf Protokollanforderungen von einer E-Mail-Client-Komponente einer älteren Version bei lediglich einer mäßigen Zunahme der Komplexität antworten.
  • Fernoperationen (ROPs) können verwendet werden, um die Replikation eines E-Mail-Ordners zwischen einer E-Mail-Server-Komponente und einer E-Mail-Client-Komponente zu bewerkstelligen. Eine Anforderung zur Synchronisierung eines Ordners kann beispielsweise von der Fernabfrage SynchFolder getätigt werden. Ist eine E-Mail-Client-Komponente in der Lage, Körperbereiche von E-Mail-Nachrichten in Nichtstandardformaten anzuzeigen, so kann sie das BEST_BODY-Flag in der Fernoperation SynchFolder setzen, um darauf hinzuweisen, dass die E-Mail-Server-Komponente das beste Format unter den verfügbaren Kopfbereichen von E-Mail-Nachrichten auswählen kann, anstatt dass der Server veranlasst würde, den Kopfbereich einer E-Mail-Nachricht in einem Standardformat auszugeben. Eine E-Mail-Server-Komponente kann die Fernabfragen sowohl mit als auch ohne das BEST_BODY-Flag bei lediglich einer mäßigen Zunahme der Komplexität geeignet verarbeiten. Fernabfragen zur Kommunikation zwischen Servern einer älteren Version und einer aktuellen Version können beispielsweise die in der nachfolgenden Tabelle zusammengefassten Eigenschaften enthalten.
    Fernoperation, die von einem Protokoll zur Kommunikation mit Servern einer älteren Version verwendet werden kann Fernoperation, die von einem Protokoll zur Kommunikation mit Servern einer aktuellen Version verwendet werden kann
    Kennung (ID) der Fernoperation SynchFolder SynchFolder
    Neue Parameter n/a BEST_BODY-Flag: Ist es gesetzt, so wählt die E-Mail-Server-Komponente den besten E-Mail-Nachrichten-Körperbereich zum Senden an die E-Mail-Client-Komponente. Die Umwandlung des E-Mail-Nachrichten-Körperbereiches in ein vorbestimmtes Standardformat ist nicht notwendig.
  • 8A bis 8C zeigen verschiedene bestehende Modi der Übertragung einer Gruppe von E-Mail-Nachrichten zwischen einer E-Mail-Server-Komponente und einer E-Mail-Client-Komponente. Für jeden Modus weist jede E-Mail-Nachricht benannte Eigenschaften auf, die eine Kopfbereichsgruppe und eine Körperbereichsgruppe beinhalten, wobei mehrere E-Mail-Nachrichten in einem Ordner enthalten sind. 8A zeigt einen Vollelementübertragungsmodus. Die Darstellung zeigt einen ersten übertragenen E-Mail-Nachrichten-Kopfbereich 801 und sodann einen ersten E-Mail-Nachrichten-Körperbereich 802 vor einem zweiten E-Mail-Nachrichten-Kopfbereich 803 und sodann einen zweiten E-Mail-Nachrichten-Körperbereich 804 und so weiter, bis die Gruppe von E-Mail-Nachrichten übertragen ist. 8B zeigt den den Kopfbereichen zu eigenen ersten Übertragungsmodus. In diesem Modus werden ein erster E-Mail-Nachrichten-Kopfbereich 805 und anschließend ein zweiter E-Mail-Nachrichten-Kopfbereich 806 und so weiter übertragen, bis alle E-Mail-Nachrichten-Kopfbereiche übertragen sind. Erst dann werden ein erster E-Mail-Nachrichten-Körperbereich 807 und anschließend ein zweiter E-Mail-Nachrichten-Körperbereich 808 und so weiter übertragen, bis die Gruppe von E- Mail-Nachrichten übertragen ist. 8C zeigt den den Kopfbereichen zu eigenen Nurübertragungsmodus. Wie der Name nahelegt, werden nur die E-Mail-Nachrichten-Kopfbereiche 809 als Antwort auf eine Anforderung zur Übertragung einer Gruppe von E-Mail-Nachrichten übertragen. E-Mail-Nachrichten-Körperbereiche 810 werden nur als Antwort auf eine zusätzliche explizite Anforderung übertragen. In einem beliebigen dieser Modi kann die Übertragungssequenz vorübergehend durch eine E-Mail-Client-Komponenten-Anforderung mit höherer Priorität beispielsweise eines bestimmten E-Mail-Nachrichten-Körperbereiches unterbrochen werden.
  • Ein E-Mail-Ordner ist ein Beispiel für ein Ziel einer Anforderung zur Übertragung einer Gruppe von E-Mail-Nachrichten. Ein E-Mail-Ordner kann Datenobjekte enthalten, die nicht E-Mail-Nachrichten sind. Wie vorstehend erläutert worden ist, sind Übertragungsmodi oftmals in Bezug auf die E-Mail-Nachrichten-Kopfbereiche und E-Mail-Nachrichten-Körperbereiche definiert, so beispielsweise als den Kopfbereichen zu eigene erste und den Kopfbereichen zu eigene Nurübertragungsmodi. In derartigen Übertragungsmodi kann ein Versuch der Übertragung von Datenobjekten, für die eine Kopfbereichsgruppe aus benannten Eigenschaften und/oder eine Körperbereichsgruppe aus benannten Eigenschaften nicht wohldefiniert sein können, zu einem Protokollfehler führen. Ein Aspekt der Erfindung vermeidet diese Situation, indem ermöglicht wird, dass Datenobjekte, für die eine Kopfbereichs- und/oder Körperbereichsgruppe aus benannten Eigenschaften nicht wohldefiniert ist, immer als Ganzes und nicht in Teilen übertragen werden können. Dieses Ausführungsbeispiel kann anhand des Beispieles von 8D erläutert werden. Bei diesem Beispiel kann die Übertragung zwischen einer E-Mail-Server-Komponente und einer E-Mail-Client-Komponente in dem dem Kopfbereich zu eigenen Nurmodus erfolgen. Entsprechend wird ein erster E-Mail-Nachrichten-Kopfbereich 811 übertragen, woraufhin ein Datenobjekt 812 zum nächsten Kandidaten für die Übertragung wird. Die Kopfbereichsgruppe der benannten Eigenschaften ist für das Datenobjekt 812, so beispielsweise FAI, nicht wohldefiniert, sodass das gesamte Datenobjekt übertragen wird. Ein weiterer Kandidat für die Übertragung weist eine wohldefinierte Kopfbereichsgruppe aus benannten Eigenschaften auf (das heißt, das Kandidatendatenobjekt besitzt sämtliche benannten Eigenschaften, die von der E-Mail-Client-Komponente als zur Kopfbereichsgruppe aus benannten Eigenschaften gehörig definiert sind), weshalb nur ein E-Mail-Nachrichten-Kopfbereich 813 übertragen wird.
  • Ein Beispiel zur Implementierung dieses Aspekts der vorliegenden Erfindung besteht darin, dass ein Flag, so beispielsweise IGNORE_MODE_ON_FAI, das in einer Fernope ration zur Synchronisierung, so beispielsweise SynchFolder, siehe vorstehende Beschreibung, enthalten ist, verwendet wird. Eine E-Mail-Server-Komponente kann Fernoperationen sowohl mit als auch ohne das IGNORE_MODE_ON_FAI-Flag mit lediglich einer mäßigen Zunahme der Komplexität geeignet verarbeiten. Fernoperationen können die Eigenschaften enthalten, die in der nachstehenden Tabelle dargestellt sind, um die Replikation eines E-Mail-Ordners zwischen einer E-Mail-Server-Komponente und einer E-Mail-Client-Komponente zu erreichen.
    Fernoperation, die von einem Protokoll zur Kommunikation mit Servern einer älteren Version verwendet werden kann Fernoperation, die von einem Protokoll zur Kommunikation mit Servern einer aktuellen Version verwendet werden kann
    Kennung (ID) der Fernoperation SynchFolder SynchFolder
    Neue Parameter n/a IGNORE_MODE_ON_FAI-Flag: Ist es gesetzt, so kann für Datenobjekte wie FAI, die keine wohldefinierte Gruppe von Kopfbereichs- und/oder Körperbereichseigenschaften aufweisen, die E-Mail-Server-Komponente auf eine Übertragungsanforderung mit dem gesamten Datenobjekt unabhängig vom vorherrschenden Übertragungsmodus antworten.
  • E-Mail-Nachrichten sind üblicherweise an einen oder mehrere E-Mail-Netzwerk-Anwender adressiert. Eine E-Mail-Nachricht kann als zugestellt angesehen werden, wenn sie von einer E-Mail-Server-Komponente zur Speicherung angenommen ist. Ein E-Mail-Netzwerk kann mehrere E-Mail-Server-Komponenten aufweisen. Üblicherweise verfügt ein E-Mail-Netzwerk-Protokoll über eine bestimmte Strategie zum Beschränken der Anzahl von E-Mail-Server-Komponenten, die ein E-Mail-Netzwerk nach neuen Nachrichten durchsuchen muss. Ein gängiges Beispiel hierfür ist die Heim-Server-Strategie (home server strategy), durch die ermöglicht wird, dass E-Mail-Nachrichten, die an einen bestimmten E-Mail-Netzwerk-Anwender adressiert sind, nur von einer bestimmten Heim-Server des Anwenders genannten E-Mail-Server-Komponente angenommen werden. In einem derartigen Fall kann eine E-Mail-Client-Komponente derart konfiguriert sein, dass nur der Heim-Server berücksichtigt wird, wenn beispielsweise periodisch eine Prüfung hinsichtlich neuer E-Mail-Nachrichten oder eine Registrierung zur Benachrichtigung hinsichtlich neuer E-Mail-Nachrichten vorgenommen wird.
  • 9 zeigt den Fall, dass auch das Beispiel einer einfachen Heim-Server-Strategie mit Komplikationen verbunden ist. Bei dem in 9 dargestellten Beispiel wird eine bestimmte E-Mail-Server-Komponente 901 zunächst als Heim-Server für einen bestimmten E-Mail-Netzwerk-Anwender bezeichnet. Mit der Zeit wechselt der bezeichnete Heim-Server für den Anwender zu anderen E-Mail-Server-Komponenten 903 und 905, was üblicherweise aus administrativen bzw. verwaltungstechnischen Gründen erfolgt. Die E-Mail-Server-Komponenten 901, 903 und 905 können beispielsweise physisch oder logisch verschieden sein oder verschiedenen Versionen angehören. Die E-Mail-Server-Komponente 902 kann nur mit der E-Mail-Server-Komponente 901 von dem Zeitpunkt T0 bis zu dem Zeitpunkt T1 kommunizieren, woraufhin die E-Mail-Client-Komponente 904 nur mit der E-Mail-Server-Komponente 903 bis zu dem Zeitpunkt T2 kommunizieren kann, woraufhin wiederum die E-Mail-Client-Komponente 906 nur mit der E-Mail-Server-Komponente 905 kommunizieren kann. Die E-Mail-Client-Komponenten 902, 904 und 906 können gleich oder verschieden sein. Die E-Mail-Server-Komponenten 901 und 903 können nach dem Zeitpunkt T2 existieren oder auch nicht. Diese Komplikationen können bei einer E-Mail-Nachrichten-Speicherreplikation, die nachstehend erläutert wird, wichtig werden.
  • E-Mail-Nachrichten können von einer E-Mail-Server-Komponente in einem expliziten E-Mail-Nachrichten-Speicher abgelegt werden, der beispielsweise unter Verwendung bekannter Datenbanktechnologien implementiert sein kann. Eine E-Mail-Server-Komponente kann einen oder mehrere derartige Nachrichten-Speicher aufweisen. Ein E-Mail-Netzwerk-Anwender kann über einen Heim-Nachrichten-Speicher (home message store) verfügen. Eine Änderung der Heim-Nachrichten-Speicher kann dieselben Wirkungen mit sich bringen, die für eine Änderung der Heim-Server beschrieben worden sind.
  • Einige E-Mail-Netzwerk-Protokolle verfügen über die Fähigkeit, Teile eines E-Mail-Nachrichten-Speichers in eine Speichereinrichtung zu replizieren, die lokal bei einer E-Mail-Client-Komponente angesiedelt ist. Die Replikation von Teilen eines entfernt befindlichen E-Mail-Nachrichten-Speichers in eine lokale E-Mail-Speichereinrichtung kann das Leistungsvermögen des Protokolls und/oder das wahrgenommene Leistungsvermögen des Protokolls verbessern, und zwar beispielsweise durch Replizieren sämtlicher neuer E-Mail-Nachrichten in die lokale E-Mail-Speichereinrichtung vor einer expliziten E-Mail- Netzwerk-Anwender-Anforderung zum Zwecke des Durchsehens. Eine derartige Replikation kann darüber hinaus eine zusätzliche Funktionalität für die E-Mail-Client-Komponente bereitstellen, indem beispielsweise ein E-Mail-Netzwerk-Anwender in die Lage versetzt wird, eine E-Mail-Nachricht während Unterbrechungen der Netzwerkkonnektivität anzusehen.
  • In einer E-Mail-Netzwerkumgebung kann eine einfache Replikation schnell ineffizient werden. Verfügt eine E-Mail-Server-Komponente beispielsweise über eine E-Mail-Nachricht, die mit einem bestimmten E-Mail-Netzwerk-Anwender verknüpft ist, ist diese Nachricht bereits in der Client-Komponente für den Netzwerk-Anwender repliziert worden und trifft eine neue E-Mail-Nachricht für jenen E-Mail-Netzwerk-Anwender ein, so ist erforderlich, dass zwei neue E-Mail-Nachrichten als Antwort auf eine einfache Replikationsanforderung gesendet werden. Trifft eine weitere neue E-Mail-Nachricht nach der Replikation der beiden E-Mail-Nachrichten ein, so ist erforderlich, dass nunmehr drei E-Mail-Nachrichten als Antwort auf eine einfache Replikationsanforderung gesendet werden, und so weiter. Einige E-Mail-Netzwerk-Protokolle bewerkstelligen eine inkrementelle Replikation von E-Mail-Nachrichten-Speichern, um dieses Problem zu beheben. Bei einer inkrementellen Replikation müssen nur Änderungen an einem E-Mail-Nachrichten-Speicher, die nach einer älteren erfolgreichen inkrementellen Replikation vorgenommen worden sind, als Antwort auf eine Replikationsanforderung gesendet werden. Ist beispielsweise die einzige Änderung seit der letzten erfolgreichen inkrementellen Replikation das Eintreffen einer neuen E-Mail-Nachricht, so muss nur die neue E-Mail-Nachricht als Antwort auf eine inkrementelle Replikationsanforderung gesendet werden.
  • 10 zeigt ein detaillierteres Beispiel für ein Protokoll, das eine inkrementelle Replikation ermöglicht. Ein E-Mail-Nachrichten-Speicher kann in E-Mail-Ordner unterteilt werden. Jeder E-Mail-Ordner kann unabhängig von den anderen repliziert werden, was eine genauere Einflussnahme auf den Replikationsprozess ermöglicht. Bei diesem Beispiel wird der inkrementelle Replikationsprozess Synchronisation genannt, da die Verbreitung von Änderungen von der E-Mail-Client-Komponente 501 zu der E-Mail-Server-Komponente 502 wie auch von der E-Mail-Server-Komponente 502 zu der E-Mail-Client-Komponente 501 enthalten ist. Im Gefolge einer Synchronisationsanforderung 1001 wird die Fernoperation SynchFolder von der E-Mail-Server-Komponente 502 verarbeitet. Die Fernoperation enthält einen (nicht gezeigten) Ordnerkennungsparameter (folderID paramater) und einen stateblob0-Parameter. Der Ordnerkennungsparameter identifiziert einen E-Mail-Ordner, der das Ziel der Synchronisationsanforderung 1001 darstellt. Der stateblob0-Parameter enthält Informationen, die eine E-Mail-Server-Komponente 502 in die Lage versetzen zu bestimmen, welche Änderungen überhaupt an dem E-Mail-Ordner aufgetreten sind, seit dieser letztmalig synchronisiert worden ist. Stellt die Anforderung 1001 die erste überhaupt getätigte Synchronisationsanforderung für den Zielordner durch die E-Mail-Client-Komponente 501 dar, so bestimmt die E-Mail-Server-Komponente 502, ob der Ziel-E-Mail-Ordner in dem E-Mail-Nachrichten-Speicher im Vergleich zu einem leeren Ordner geändert worden ist. Als Antwort 1002 auf die Anforderung 1001 sendet die E-Mail-Server-Komponente 502 beliebige Änderungen an der E-Mail-Client-Komponente 501, enthaltend beliebige E-Mail-Nachrichten und/oder andere Datenobjekte, die dem Zielordner hinzugefügt worden sind, sowie eine Liste von beliebigen E-Mail-Nachrichten und/oder anderen Datenobjekten, die aus dem Zielordner gelöscht worden sind. Die E-Mail-Server-Komponente 502 erstellt zudem einen neuen stateblob1, der den Zustand des Zielordners anzeigt, wie dieser sich in der E-Mail-Client-Komponente 501 unmittelbar im Gefolge der Synchronisation darstellt, und sendet diesen stateblob1 zusätzlich in der Antwort 1002. Sendet die E-Mail-Client-Komponente 501 die nächste Synchronisationsanforderung 1003 für denselben Ordner wie in der Anforderung 1001, so enthält die Anforderung 1003 als Parameter denselben stateblob1, der mit der Antwort 1002 ausgegeben worden ist. Wie vorher bedient sich die E-Mail-Server-Komponente 502 der in dem stateblob1 enthaltenen Informationen, um festzustellen, welche Änderungen, wenn überhaupt, in dem Zielordner aufgetreten sind, und sendet diese Änderungen zusammen mit einem neuerstellten stateblob2 in der Antwort 1004 zurück an die E-Mail-Client-Komponente 501.
  • Weist ein stateblob-Datenobjekt eine große Größe auf, so kann dies nachteilige Auswirkungen auf das Leistungsvermögen des Protokolls haben, da eine Sendung an eine E-Mail-Server-Komponente beziehungsweise von einer E-Mail-Server-Komponente beispielsweise für jede E-Mail-Ordner-Synchronisationsanforderung erfolgt. In einigen E-Mail-Netzwerk-Protokollen, die eine E-Mail-Ordner-Synchronisation ermöglichen, kann der stateblob weitgehend aus einer Gruppe von Nachrichtenänderungskennungsdatenobjekten (message changeID data objects) zusammengesetzt sein, die Änderungen an den E-Mail-Nachrichten identifizieren, die von einer E-Mail-Client-Komponente gesehen worden sind. Eine E-Mail-Nachrichten-Änderung kann als von einer E-Mail-Client-Komponente und/oder einer E-Mail-Server-Komponente gesehen betrachtet werden, wenn die geänderte E-Mail-Nachricht an jene Komponente übertragen worden ist.
  • Ein Ziel eines Nachrichtenänderungskennungsdatenobjektes kann darin bestehen, eine Änderung an einer E-Mail-Nachricht im Kontext eines gesamten E-Mail-Netzwerkes eindeutig zu identifizieren. In einem E-Mail-Netzwerk, das sich einer Heim-Server-Strategie bedient, kann ein Heim-Server eines Anwenders dafür verantwortlich sein, ein Nachrichtenänderungskennungsdatenobjekt mit einer vorher nicht gesehenen E-Mail-Nachrichten-Änderung zu verknüpfen. So kann ein Heim-Server beispielsweise Nachrichtenänderungskennungsdatenobjekte einsetzen, die ein Server-Kennungsdatenobjekt und eine Seriennummer umfassen. Ein Server-Kennungsdatenobjekt kann auf eindeutige Weise eine E-Mail-Server-Komponente im Kontext eines gesamten E-Mail-Netzwerkes unter Verwendung wohlbekannter Techniken, so beispielsweise global eindeutiger Kennungen, identifizieren. Wo immer solche Kennungen selbst eine große Größe aufweisen, kann das Server-Kennungsdatenobjekt anstelle dessen ein Index in eine Kennungsnachschlagetabelle sein, die in der E-Mail-Server-Komponente vorgehalten wird. Die Seriennummer kann von einem Zähler beispielsweise mit einer Breite von 6 Byte bereitgestellt werden, wobei der Zähler lokal bei einer E-Mail-Server-Komponente angesiedelt ist und immer dann inkrementiert wird, wenn die E-Mail-Server-Komponente eine vorher nicht gesehene E-Mail-Nachricht zur Speicherung annimmt.
  • Für die vorliegende Beschreibung wird ein Nachrichtenänderungskennungsdatenobjekt beispielsweise durch „S1:1" dargestellt, wobei „S1" das Server-Kennungsdatenobjekt für eine erste E-Mail-Server-Komponente und „1" eine Seriennummer bezeichnen. Eine Gruppe von Nachrichtenänderungskennungsdatenobjekten kann beispielsweise durch „S1:1, S1:2, S1:3" bezeichnet werden, wobei „S1:1", „S1:2" und „S1:3" aufeinanderfolgende Nachrichtenänderungskennungsdatenobjekte bezeichnen, die von einer E-Mail-Server-Komponente mit der Server-Kennung S1 eingesetzt werden.
  • Für den Fall, dass ein stateblob weitgehend aus einer Gruppe von Nachrichtenänderungskennungsdatenobjekten besteht, die E-Mail-Nachrichten-Änderungen darstellen, die von einer E-Mail-Client-Komponente gesehen werden (eine Gruppe „Nachrichtenänderungen gesehen"), sind Techniken entwickelt worden, um die Gruppe zu kodieren, wodurch sich ihre Größe verringert. So kann beispielsweise die Gruppe „S1:1, S1:2, S1:3, S1:4" als „S1:1–4" kodiert werden. Darüber hinaus kann eine E-Mail-Server-Komponente sicherstellen, dass die verwendeten Seriennummern stets zunehmen. In diesem Fall kann eine unzusammenhängende Gruppe „Nachrichtenänderungen gesehen", so beispielsweise „S1:1, S1:3, S1:5, S1:7", als „S1:1–7" kodiert werden, das heißt als Bereich, der die minimalen und maximalen Seriennummern enthält, wobei dies nicht mit einem Verlust an Funktionalität einhergeht.
  • In dem in 9 dargestellten Szenario kann die Gruppe „Nachrichtenänderungen gesehen" Nachrichtenänderungskennungsdatenobjekte beinhalten, die von E-Mail-Server-Komponenten (beispielsweise S1 und S2) erstellt sind, die nicht der aktuelle Heim-Server (beispielsweise S3) sind. Ein Nachrichtenänderungskennungsdatenobjekt, das von dem aktuellen Heim-Server erstellt wird, kann als heimische bzw. native Nachrichtenänderungskennung bezeichnet werden, während ein Nachrichtenänderungskennungsdatenobjekt, das von anderen E-Mail-Server-Komponenten erstellt worden ist, als fremde Nachrichtenänderungskennung bezeichnet werden kann. E-Mail-Netzwerk-Protokolle für die Kommunikation mit E-Mail-Server-Komponenten einer älteren Version haben bislang nicht die Optimierung von unzusammenhängenden fremden Nachrichtenänderungskennungssequenzen als Bereich ermöglicht, der die minimalen und maximalen Seriennummern auf einer Pro-E-Mail-Server-Komponenten-Grundlage enthält. Die nachfolgende Tabelle zeigt den Nutzen, den eine derartige Optimierung bei einem Ausführungsbeispiel der vorliegenden Erfindung mit sich bringt.
    Optimierung, die von einem Server einer älteren Version (aktueller Heim-Server S3) verwendet wird Optimierung, die von einem Server einer aktuellen Versinn (aktueller Heim-Server S3) verwendet wird
    Gruppe „Nachrichtenänderungen gesehen" vor der Optimierung S1:1, S1:3, S1:5, S1:7 S2:1, S2:3, S2:5, S2:7 S3:1, S3:3, S3:5, S3:7
    Gruppe „Nachrichtenänderungen gesehen" nach der Optimierung S1:1, S1:3, S1:5, S1:7 S2:1, S2:3, S2:5, S2:7 S3:1–7 S1:1–7 S2:1–7 S3:1–7
  • Ein Ausführungsbeispiel der vorliegenden Erfindung greift auf Fernoperationen zurück, die die in der nachstehenden Tabelle aufgeführten Eigenschaften aufweisen, um die Synchronisation eines E-Mail-Ordners zwischen einer E-Mail-Server-Komponente und einer E-Mail-Client-Komponente zu erreichen. Eine E-Mail-Server-Komponente kann die verbesserte stateblob-Kodiertechnik bei einem lediglich mäßigen Anstieg der Komplexität implementieren.
    Fernoperationsergebnis, das von einem Protokoll zur Kommunikation mit Servern einer älteren Version verwendet werden kann Fernoperationsergebnis, das von einem Protokoll zur Kommunikation mit Servern einer aktuellen Version verwendet werden kann
    Kennung (ID) der Fernoperation SynchFolder SynchFolder
    Ungeänderte Parameter, die in einem neuen Modus verwendet werden stateblob: Optimierung, nicht enthaltend unzusammenhängende Gruppen von fremden Nachrichtenänderungskennungsdatenobjekten stateblob: verbesserte Optimierung, enthaltend unzusammenhängende Gruppen von fremden Nachrichtenänderungskennungsdatenobjekten
  • 11A und 11B zeigen den Unterschied zwischen einer Unterprozedur, die von einem Server einer älteren Version beziehungsweise einem Server einer aktuellen Version verwendet werden können, um auf die Fernoperation SynchFolder zu antworten. 11A zeigt Schritte 1101, 1102 und 1103. In Schritt 1101 wird eine anfängliche Gruppe „Nachrichtenänderungen gesehen" erstellt. In Schritt 1102 werden die Elemente der Gruppe „Nachrichtenänderungen gesehen", die native Nachrichtenänderungskennungsdatenobjekte darstellen, optimiert. In Schritt 1103 wird die optimierte Gruppe „Nachrichtenänderungen gesehen" zu einem stateblob-Datenobjekt hinzugefügt, das mit einer Antwort an die E-Mail-Client-Komponente gesendet werden kann, die diese Synchronisation angefordert hat. 11B beinhaltet einen zusätzlichen Schritt 1104, der Elemente der Gruppe „Nachrichtenänderungen gesehen" beinhaltet, die fremde Nachrichtenänderungskennungsdatenobjekte sind, die ebenfalls vor der Gruppe „Nachrichtenänderungen gesehen" – nunmehr mit einer verbesserten Optimierung – optimiert werden, und zwar unter Hinzufügung eines stateblob-Datenobjektes in Schritt 1103.
  • Während das Unterteilen eines E-Mail-Nachrichten-Speichers in E-Mail-Ordner eine genauere Einflussnahme auf den Synchronisationsprozess ermöglicht, bringt es nicht automatisch eine Verbesserung des Leistungsvermögens des Protokolls mit sich; es kann vielmehr auch zu einer Verschlechterung des Leistungsvermögens des Protokolls kommen. Einige Protokolle erfordern beispielsweise, dass jeder Nachrichtenspeicherordner gesondert synchronisiert wird. Jede Synchronisationsoperation weist üblicherweise einen bestimmten Overhead auf, der signifikant sein kann. Synchronisationsoperationen, die stateblob-Datenobjekte verwenden, sind Beispiele für Operationen, die einen signifikanten Overhead aufweisen. Für den Fall der Synchronisierung eines gesamten Nachrichtenspeichers können Protokolle, bei denen erforderlich ist, dass jeder Nachrich tenspeicherordner gesondert synchronisiert wird, einen Nachteil im Vergleich zu Protokollen darstellen, bei denen weniger Synchronisationsoperationen erforderlich sind.
  • Das Synchronisieren eines gesamten Nachrichtenspeichers und das Aufrechterhalten der Synchronisierung sind ein wünschenswertes Ziel für eine E-Mail-Client-Komponente. Herkömmliche E-Mail-Client-Komponenten aus dem Stand der Technik suchen dieses Ziel auch dann zu erreichen, wenn dies einen nachteiligen Einfluss auf das Leistungsvermögen des Protokolls hat. Ein Aspekt der vorliegenden Erfindung besteht darin, dass man in die Lage versetzt wird, den nachteiligen Einfluss auf das Protokoll zu minimieren, während dieses Ziel dennoch erreicht wird, und zwar unter Verwendung einer Tiefhierarchietabelle. Herkömmliche aus dem Stand der Technik bekannte E-Mail-Server-Komponenten sind nicht in der Lage, eine Tiefhierarchietabelle bereitzustellen.
  • Werden E-Mail-Nachrichten-Speicher in E-Mail-Ordner unterteilt, so können die E-Mail-Ordner in Hierarchien organisiert werden. 12 zeigt ein Beispiel für eine E-Mail-Ordner-Hierarchie. In 12 ist der Ordner 1204 ein Unterordner des Ordners 1203. Der Ordner 1203 ist wiederum ein Unterordner des Ordners 1202. Der Ordner 1201 ist der Ausgangsordner. Der Ausgangsordner ist kein Unterordner irgendeines anderen Ordners. Alle anderen Ordner sind Elemente der von dem Ordner 1201 ausgehenden Ordnerhierarchie. Üblicherweise verfügt nicht jeder Ordner einer Ordnerhierarchie über einen direkten Verweis auf jeden anderen Ordner. Ein Ordner kann nur einen direkten Verweis auf seine Unterordner enthalten. Ein Ordner kann auch einen direkten Verweis auf beliebige Ordner enthalten, von denen er Unterordner ist. Es kann auch der Fall auftreten, dass der einzige Ordner, für den jeder Ordner einen direkten Verweis enthält, der Ausgangsordner der Hierarchie ist.
  • Eine Tiefhierarchietabelle kann Informationen über jeden Ordner in einer Ordnerhierarchie enthalten. Jeder Ordner kann eine Reihe in der Tiefhierarchietabelle innehaben. Die Informationen in der Tiefhierarchietabelle sind derart, dass sie zu einer Bestimmung dahingehend verwendet werden können, ob die Inhalte eines E-Mail-Ordners während einer bestimmten Zeitspanne geändert worden sind. Die Bestimmung einer Änderung an einem E-Mail-Ordner während einer bestimmten Zeitspanne kann unter Verwendung eines einfachen Vergleiches einer Kopie einer Ordnerreihe auf Grundlage einer Aufnahme zu Beginn der Zeitspanne mit einer Kopie jener Ordnerreihe auf Grundlage einer Aufnahme am Ende der Zeitspanne implementiert werden. Bei einem Ausführungsbeispiel beinhaltet jede Reihe der Tiefhierarchietabelle die nachfolgenden Attribute.
    Name des Attributes Typ des Attributes Anmerkungen
    Ordnerkennung (ID) FID Der Typ FID umfasst eine globale eindeutige Kennung (GUID) und eine 6 Byte umfassende Seriennummer. Dieser Wert kann verwendet werden, um einen E-Mail-Ordner im Kontext eines E-Mail-Netzwerkes eindeutig zu identifizieren.
    PR_LOCAL_COMMIT_TIME_MAX Zeitstempel Dieser Zeitstempel wird immer dann aktualisiert, wenn die Inhalte des Ordners geändert werden.
    PR_DELETED_COUNT_TOTAL QWORD Dieser Wert ist ein Zähler für die Gesamtzahl von Elementen, die jemals aus einem Ordner gelöscht worden sind.
  • Die Attribute einer E-Mail-Ordner-Reihe in einer Tiefhierarchietabelle können aktualisiert werden, wann immer eine Änderung an den Inhalten eines Ordners vorgenommen wird. Für eine effiziente Implementierung einer Aktualisierung einer Tiefhierarchietabelle hat man im Zusammenhang mit der vorliegenden Erfindung herausgefunden, dass das Bereitstellen eines schnellen und direkten Verweises auf die Tiefhierarchietabelle hilfreich ist. Man hat grundsätzlich herausgefunden, dass eine kleine und vorhersagbare Anzahl von Indirektionsniveaus vorhanden sein sollte, wenn ein Zugriff auf die Tiefhierarchietabelle versucht wird. Das Positionieren einer Tiefhierarchietabelle auf einem beliebigen Niveau einer Ordnertabelle erzeugt beispielsweise keine vorhersagbare Anzahl von Indirektionsniveaus. Bei einem Ausführungsbeispiel der vorliegenden Erfindung kann aus diesem Grunde eine Tiefhierarchietabelle mit dem Ausgangsordner einer einem E-Mail-Netzwerk-Anwender zu eigenen E-Mail-Nachrichten-Speicher-Hierarchie verknüpft werden.
  • Kommunikationsvorgänge zwischen einer E-Mail-Client-Komponente und einer E-Mail-Server-Komponente können in Kommunikationssitzungen unterteilt werden. Es kann ein Verlust der E-Mail-Nachrichten-Speichersynchronisation zwischen Sitzungen auftreten, so beispielsweise während einer Unterbrechung der Netzwerkkonnektivität. Um die E-Mail-Nachrichten-Speichersynchronisation zu Beginn einer Kommunikationssitzung wiederherzustellen, bedienen sich einige Protokolle für die Kommunikation mit E-Mail-Server-Komponenten einer älteren Version der Fernoperation SynchFolder für jeden Ordner in der Ordnerhierarchie. Üblicherweise haben sich die Inhalte einiger der Ordner zwischen zwei Sitzungen nicht geändert. Die Fernoperation SynchFolder mit einem nichtgeänderten Ordner als Ziel führt zu einer „Nullsynchronisation" (null synch). Obwohl eine „Nullsynchronisation" nicht dazu führt, dass irgendwelche Ordneränderungen an eine E-Mail-Client-Komponente übertragen werden, weist sie immer noch einen damit verknüpften Overhead auf, so beispielsweise ein stateblob-Datenobjekt, das signifikant sein kann.
  • 13 zeigt ein Ausführungsbeispiel der Erfindung, bei dem Ergebnisse einer „Nullsynchronisation" durch Verwenden einer Tiefhierarchietabelle vermieden werden. In einer ersten Anforderung 1301 sendet eine E-Mail-Client-Komponente 501 eine Fernoperation (beispielsweise GetHierarchyTable), die eine Tiefhierarchietabelle anfordert, an eine E-Mail-Senner-Komponente 502. In einer ersten Antwort 1302 wird eine Kopie der Tiefhierarchietabelle für die E-Mail-Client-Komponente 501 bereitgestellt. Üblicherweise verfügt eine E-Mail-Client-Komponente 501 über eine ältere Kopie der Tiefhierarchietabelle. Die E-Mail-Client-Komponente 501 kann schnell bestimmen, welche Ordner in dem einem Anwender zu eigenen E-Mail-Nachrichten-Speicher auf der E-Mail-Server-Komponente 502 geändert worden sind, und zwar unter Verwendung eines reihenweise erfolgenden Vergleiches der beiden Kopien. Anschließend werden Fernoperationen (beispielsweise SynchFolder) eingesetzt, um nur diejenigen Ordner, die eine Änderung erfahren haben, zu synchronisieren. Anforderungen 1303 und Antworten 1304 können gegebenenfalls wiederholt werden, um die geänderten Ordner zu synchronisieren. Im Gefolge einer erfolgreichen Synchronisierung kann die der E-Mail-Client-Komponente zu eigene Kopie der Tiefhierarchietabelle derart aktualisiert werden, dass sie mit der letzten Kopie übereinstimmt, die in der Antwort 1302 gesendet worden ist. Vertilgt die E-Mail-Client-Komponente 501 nicht über eine ältere Kopie der Tiefhierarchietabelle, so können sämtliche Ordner, die über eine Reihe in der neuesten Kopie verfügen, synchronisiert werden.
  • Sobald eine Synchronisation des dem Anwender zu eigenen E-Mail-Nachrichten-Speichers erfolgt ist, kann eine Synchronisation durch periodisches Wiederholen des Anfangs von Sitzungsschritten, siehe vorstehende Beschreibung, (periodisches Abfragen bzw. Pollen der E-Mail-Server-Komponente) aufrechterhalten werden. Dieses Schema weist jedoch Nachteile auf. Die Abfragezeitspanne kann beispielsweise viel kürzer als die Zeitspanne zwischen Änderungen an einem dem Anwender zu eigenen E-Mail-Nachrichten-Speicher sein. In diesem Fall geben vergleichsweise viele der Tiefhierarchie tabellenvergleiche an, dass keine Ordner geändert worden sind. Derartige Vergleiche sind allerdings überflüssiger Aufwand, weshalb ein Protokoll, das darauf verzichten kann, effizienter ist.
  • Einige E-Mail-Netzwerke beinhalten eine Einrichtung, mit der sich eine E-Mail-Client-Komponente dafür anmelden kann, dass sie von einer E-Mail-Server-Komponente benachrichtigt wird, wenn sich beispielsweise die Inhalte eines bestimmten E-Mail-Ordners ändern. Einige E-Mail-Client-Komponenten einer älteren Version bedienen sich einer derartigen Einrichtung, um eine Synchronisation mit dem dem Anwender zu eigenen E-Mail-Nachrichten-Speicher durch Erstellen einer gesonderten Subskription für die Änderungsbenachrichtigungen in Verknüpfung mit jedem Ordner in der Ordnerhierarchie eines Anwenders aufrechtzuerhalten. Bei einem Ausführungsbeispiel der vorliegenden Erfindung kann eine E-Mail-Client-Komponente nur eine einzelne Subskription für Änderungsbenachrichtigungen in Verknüpfung mit der Tiefhierarchietabelle erstellen. Eine einzelne Subskription ist effizienter, da weniger Fernoperationen benötigt werden, um sie zu bewerkstelligen, weshalb auch weniger serverseitige Ressourcen beansprucht werden.
  • Wie weiterhin in 13 gezeigt ist, ist, wenn eine E-Mail-Client-Komponente 501 einer aktuellen Version entsprechend einem Aspekt der vorliegenden Erfindung die Fernabfrage GetHierarchyTable in einer ersten Anforderung 1301 zu Beginn einer Kommunikationssitzung mit einer E-Mail-Server-Komponente 502 einsetzt, die E-Mail-Client-Komponente 501 automatisch für Änderungsbenachrichtigungen subskribiert, die mit der Tiefhierarchietabelle verknüpft sind, was in der Antwort 1302 ausgegeben wird. Tritt eine Änderung an einem E-Mail-Ordner in einem dem Anwender zu eigenen E-Mail-Nachrichten-Speicher in der E-Mail-Client-Komponente auf, wird also beispielsweise eine E-Mail-Nachricht zu dem Ordner hinzugefügt, so wird auch die Tiefhierarchietabelle, wie vorstehend beschrieben worden ist, aktualisiert. Die Änderung an der Tiefhierarchietabelle löst einen Benachrichtigungsalarm 1305 für die E-Mail-Client-Komponente 501 aus. Obwohl der Benachrichtigungsalarm als Antwort auf die von der Anforderung 1301 gestellte Subskription erfolgt, ist er nicht Teil eines expliziten Anforderungs-Antwort-Zyklus. Damit führt die Verwendung des Benachrichtigungssystems gemäß Bereitstellung durch die vorliegende Erfindung zu sehr viel weniger Overhead in dem E-Mail-Netzwerk.
  • Eine einzelne Subskription kann zu vielen Benachrichtigungen führen. Bei einem Ausführungsbeispiel wird der Alarm unter Verwendung eines verbindungslosen Netzwerktrans portmechanismus verbreitet, so beispielsweise mittels UDP/IP (User Datagramm Protocol/Internet Protokoll UDP/IP, Anwenderdatagrammprotokoll/Internetprotokoll, wobei jedoch ein beliebiger geeigneter Netzwerktransportmechanismus verwendet werden kann. Als Antwort auf den Alarm sendet die E-Mail-Client-Komponente 501 eine Anforderung 1306, die eine Fernoperation (beispielsweise GetNotification) enthält, an die E-Mail-Server-Komponente 502. Als Antwort 1307 werden alle geänderten Reihen der Tiefhierarchietabelle (beispielsweise Reihen entsprechend einem geänderten Ordner, der die Benachrichtigung ausgelöst hat) an die E-Mail-Client-Komponente 501 gesendet. Die E-Mail-Client-Komponente 501 verwendet anschließend Fernoperationen (beispielsweise SynchFolder), um nur die Ordner, die Änderungen erfahren haben, zu synchronisieren.
  • Mehrere E-Mail-Client-Komponenten können für Änderungsbenachrichtigungen in Verknüpfung mit demselben Datenobjekt (beispielsweise demselben E-Mail-Ordner) subskribiert werden, um beispielsweise eine kollaborative Funktionalität bereitzustellen. Wie in 18 gezeigt ist, werden die E-Mail-Client-Komponenten 1801, 1802 und 1803 für Änderungsbenachrichtigungen in Verknüpfung mit demselben Datenobjekt (nicht gezeigt) in lokaler Anordnung in der E-Mail-Server-Komponente 1804 subskribiert. Die E-Mail-Client-Komponente 1803 sendet eine Fernoperation 1805 an die E-Mail-Server-Komponente 1804, was zu einer Änderung an dem Datenobjekt führt. Als Ergebnis der Änderung sendet die E-Mail-Server-Komponente 1804 Änderungsbenachrichtigungen 1806, 1807 und 1808 an die E-Mail-Client-Komponenten 1801, 1802, 1803. Änderungsbenachrichtigungen verfügen über kaum mehr Information als das Identifizieren des Datenobjektes, das geändert worden ist, sodass beispielsweise für eine E-Mail-Client-Komponente keine Möglichkeit besteht zu bestimmen, ob sie der Grund für eine bestimmte Änderung gewesen ist. Ist das Datenobjekt beispielsweise ein E-Mail-Ordner, so können die Änderungsbenachrichtigungen 1801, 1802 und 1803 dazu führen, dass in jeder E-Mail-Client-Komponente 1801, 1802, 1803 die Synchronisation für den geänderten Ordner initiiert wird. Da in diesem Beispiel die E-Mail-Client-Komponente 1803 für die Änderung verantwortlich war, ist das Ergebnis eine „Nullsynchronisierung".
  • Aus vorstehend erläuterten Gründen kann es wünschenswert sein, Synchronisationen zu beseitigen, deren Ergebnis eine „Nullsynchronisation" ist. Das beschriebene Benachrichtigungsverhalten ist jedoch gegebenenfalls nicht immer unerwünscht, und es können einige E-Mail-Client-Komponenten davon abhängen. Ein Aspekt der vorliegenden Erfindung besteht darin, die Fähigkeit bereitzustellen, dass eine E-Mail-Client-Komponente das Benachrichtigungsverhalten der E-Mail-Server-Komponenten einer aktuellen Version konfiguriert, um das Leistungsvermögen des Protokolls bei gleichzeitiger Bereitstellung von E-Mail-Client-Komponenten einer älteren Version mit ungeändertem Benachrichtigungsverhalten zu verbessern.
  • 19A zeigt das Benachrichtigungsverhalten, das von E-Mail-Server-Komponenten einer älteren Version bereitgestellt werden kann. 19B zeigt ein konfigurierbares Benachrichtigungsverhalten entsprechend einem Aspekt der vorliegenden Erfindung. Falls erwünscht, kann eine aktuelle E-Mail-Client-Komponente gegenüber einer E-Mail-Server-Komponente anzeigen, dass sie zu einem Benachrichtigungsverhalten gemäß 19 imstande ist, und zwar beispielsweise durch Bereitstellen eines Flags mit einer Anforderung – in dem Beispiel von 19B das Flag IGNORE_OWN.
  • In Schritt 1901 wird der nächste Kandidat aus der Gruppe der zu benachrichtigen Teilnehmer ausgewählt. In Schritt 1904 wird die Subskription für das Flag IGNORE_OWN untersucht. Ist das Flag nicht vorhanden, so geht Schritt 1904 zu Schritt 1902 über, wo eine Benachrichtigung an den Kandidatenteilnehmer gesendet wird. Wird das Flag vorgefunden, so geht Schritt 1904 zu Schritt 1905 über, wo der Teilnehmer erneut untersucht wird, um zu bestimmen, ob der Teilnehmer die Benachrichtigung ausgelöst hat. Diese Bestimmung kann beispielsweise durch Untersuchen einer Kommunikationssitzungskennung („Sitzungs-ID") derjenigen Sitzung, die zur Erstellung der Subskription geführt hat, verwendet werden. Eine Sitzungskennung kann beispielsweise eine global eindeutige Kennung und eine 6 Byte umfassende Seriennummer umfassen. Die Benachrichtigung wird auch nach der mit ihrer Ursache verknüpften Sitzungskennung untersucht. Passen beide zusammen, so wird die Benachrichtigung unterdrückt. Ein Ergebnis besteht darin, dass eine E-Mail-Client-Komponente, die eine Benachrichtigung ausgelöst hat, jene Benachrichtigung nicht erhält. Die Unterprozedur geht sodann, wie nachstehend noch beschrieben wird, zu Schritt 1903 über.
  • Hat der Teilnehmer die Benachrichtigung nicht ausgelöst, so ist die Sitzungskennung in Verknüpfung mit der Subskription nicht die gleiche wie die Sitzungskennung in Verknüpfung mit dem Grund der Benachrichtigung, und Schritt 1905 geht zu Schritt 1902 über, wo die Benachrichtigung gesendet wird. Der Prozess geht sodann zu Schritt 1903 über, wo eine Bestimmung dahingehend erfolgt, ob mehr Teilnehmer benachrichtigt werden sollen. Ist dies der Fall, so kehrt die Unterprozedur zu Schritt 1901 zurück, wohingegen sie ansonsten endet.
  • Wie vorstehend ausgeführt, kann eine E-Mail-Client-Komponente, die sich eines Cashspeichers von E-Mail-Nachrichten bedient, beispielsweise über eine Fernoperation die Synchronisation von Nachrichten oder anderen Datenobjekten zwischen einem lokalen Client-Datenspeicher und dem in der E-Mail-Server-Komponente verfügbaren Datenspeicher anfordern. Die E-Mail-Client-Komponente kann auf ähnliche Weise das Kopieren von Nachrichten aus dem Server-Speicher in den Client-Speicher anfordern. In beiden Fällen kann die Anforderung unter Verwendung eines Schnellübertragungsmodus erfolgen.
  • Üblicherweise beinhaltet, wenn Nachrichten oder andere Daten, so beispielsweise Dateien, für ein Synchronisieren oder Kopieren angefordert werden, die Anforderung (beispielsweise eine Fernoperation) einen Hinweis auf alle Nachrichten, für die eine Synchronisation erwünscht ist. Diese Liste kann automatisch dadurch von einer E-Mail-Server-Komponente erstellt werden, dass beispielsweise das vorstehend beschriebene stateblob-Merkmal verwendet wird. Bei E-Mail-Server-Komponenten einer älteren Version (Stand der Technik) verursacht ein Fehler in einer Nachricht oder in einem Datenobjekt in einer Fernoperationsanforderung einen Fehler bei sämtlichen Elementen in der Anforderung. Dieser Prozess ist in 14A gezeigt, wo eine eine Fernoperation (beispielsweise FXPrepare) enthaltende Anforderung in Schritt 1401 mit einer Nachrichtenkennungsgruppe, die für das Kopieren oder Synchronisieren bestimmt ist, gesendet wird. Ein Schnellübertragungsmechanismus wird in die E-Mail-Server-Komponente 502 eingestellt, und es wird eine Schnellübertragungskennung in Schritt 1402 an die E-Mail-Client-Komponente 501 gesendet. Die E-Mail-Client-Komponente 501 fordert anschließend das Kopieren oder Synchronisieren der Datenobjekte mittels einer Anforderung an, die beispielsweise eine Fernoperation FXGetBuffer enthält (Schritt 1403). Es tritt ein Fehler bei einer oder mehreren der Nachrichten oder der anderen Datenobjekte auf, wenn die E-Mail-Server-Komponente 502 versucht, die angeforderten Nachrichten zu öffnen. Beispiele für Fehler sind beispielsweise beschädigte Nachrichten oder Datenobjekte, ein Serverausfall, eine E-Mail-Server-Komponente 502 außerhalb des Speichers oder ein bei dem Datenobjekt erfasster Virus.
  • Nach dem Fehler sendet die E-Mail-Server Komponente 502 einen schweren Fernoperationsfehler in den Daten, die an die E-Mail-Client-Komponente 501 gesendet werden, siehe Schritt 1404. Schlägt die Synchronisierung als solche fehl, so werden die Nachrichten innerhalb der Nachrichtenkennungsgruppe nicht synchronisiert oder kopiert, und der stateblob oder eine ähnliche Aktualisierungsinformation werden von der E-Mail- Client-Komponente 501 nicht empfangen. Die E-Mail-Client-Komponente 501 muss anschließend die Synchronisation oder das Kopieren der Datenobjekte zu einem anderen Zeitpunkt anfordern. Es ist möglich, dass für den Fall, dass ein Fehler nicht in der E-Mail-Server-Komponente 502 fixiert ist, weiterhin viele Nachrichten gesendet werden und die Nachrichten innerhalb der Nachrichtenkennungsgruppe niemals synchronisiert oder kopiert werden können.
  • Entsprechend einem Aspekt der vorliegenden Erfindung kann anstelle eines schweren Fernoperationsfehlers eine aktuelle E-Mail-Server-Komponente eine Fehlerinformation hinsichtlich des bestimmten Datenobjektes (beispielsweise eine E-Mail-Nachricht) senden, sodass die Synchronisation nur für jenes Datenobjekt fehlschlägt. Dieses Merkmal ermöglicht, dass Nachrichten oder andere Datenobjekte innerhalb einer Fernoperation oder einer anderen Anforderung auch dann gesendet und synchronisiert oder kopiert werden, wenn eine Nachricht oder ein anderes Datenobjekt mit einem Fehler in der Antwort enthalten ist.
  • Als ein Beispiel dafür, wie mit einem objektspezifischen Fehler umzugehen ist, kann eine aktuelle E-Mail-Server-Komponente eine Fehlernachricht in einem Datenstream für das Datenobjekt mit einem Objektfehler senden. In diesem Beispiel wird der Fehler, um die Bezeichnung zu vereinfachen, mit FXErrorInfo bezeichnet. Falls erwünscht, kann, was nachstehend noch beschrieben wird, FXErrorInfo Informationen enthalten, so beispielsweise die Nachrichtenkennung für das Datenobjekt mit dem Fehler, sowie zusätzliche Informationen dahingehend, warum die Nachricht fehlerhaft ist.
  • 14B zeigt eine Synchronisation, bei der ein Fehler in einer Nachricht M3 auftritt. Der Fehler führt zu einer FXGetBuffer-Antwort 1405, die eine Nachricht M1 und eine Nachricht M2, gefolgt von FXErrorInfo, und sodann eine Nachricht M4 enthält. Die Information FXErrorInfo ermöglicht, dass die E-Mail-Client-Komponente 501 Kenntnisse dahingehend besitzt, welche Nachricht einen Fehler aufweist, und sämtliche anderen Nachrichten in der Antwort synchronisiert. Enthält die Fehlernachricht FXErrorInfo Informationen über den Grund für den Fehler, so kann die Information entsprechend von der Client-Komponente behandelt werden, so beispielsweise dadurch, dass dem Anwender eine Fehlernachricht angezeigt wird.
  • Die nachfolgende Tabelle zeigt ein Beispiel für das Format, in dem FXErrorInfo vorliegen kann.
    FXErrorInfo
    Name des Attributes Typ des Attributes Anmerkungen
    Version WORD Version dieser Struktur
    Fehlercode DWORD
    Nachrichtenkennung MID Der Typ MID umfasst eine global eindeutige Kennung (GUID) und eine 6 Byte umfassende Seriennummer. Es handelt sich um die Nachrichtenkennung der Nachricht, die den Fehler verursacht hat.
    ... ... Null oder mehr Attribute können hier hinzugefügt werden.
    Hilfsfeldgröße ULONG Größe des folgenden Feldes
    Hilfsfeld BYTE-Feld unstrukturiertes Feld zum Kommunizieren von Fehlerdetails
  • Es ergibt sich, dass das als Beispiel angegebene Format ein Versionsattribut, einen Fehlercode und eine Nachrichtenkennung enthält. Darüber hinaus können, so dies gewünscht ist, ein oder mehrere Attribute hinzugefügt werden. Wie vorstehend ausgeführt worden ist, kann ein Hilfsfeld zur Kommunikation von Fehlerdetails definiert werden. Als solches kann ein Attribut zum Vorgeben der Feldgröße der Fehlerdetails (beispielsweise ein Feld) definiert werden, und es kann ein Feld vorgesehen sein, das beispielsweise ein unstrukturiertes Feld zum Kommunizieren der Fehlerdetails ist. Wie vorstehend ausgeführt worden ist, können die Fehlerdetails nach Bedarf von der E-Mail-Client-Komponente 501 gehandhabt werden.
  • FXErrorInfo ermöglicht die vollständige Synchronisation der ersten Antwort, was zu einem stateblob oder einer anderen Information führt, die an den E-Mail-Client-Komponente 501 übermittelt wird. Da die E-Mail-Client-Komponente nunmehr durch die Nachricht M4 synchronisiert ist, kann die nächste Anforderung 1406 zur Synchronisierung zu einer Antwort 1407 mit den Nachrichten nach M4 (beispielsweise M5 und M6) führen.
  • Um darauf hinzuweisen, dass eine E-Mail-Client-Komponente 501 eine aktuelle Version und damit in der Lage ist, mit der Nachricht FXErrorInfo umzugehen, kann ein Flag, beispielsweise FXRecoverMode, definiert werden, das mit einer Fernoperation zur Anforderung eines Synchronisierens oder Kopierens gesendet werden kann. Andere Hinweise können verwendet werden, damit die E-Mail-Client-Komponente 501 mit der E-Mail- Server-Komponente 502 kommunizieren kann, die wiederum in der Lage ist, mit der Nachricht FXErrorInfo umzugehen.
  • Sendet die E-Mail-Server-Komponente 502 eine oder mehrere Nachrichten oder andere Datenobjekte an die E-Mail-Client-Komponente 501, so kann der Datenstream an die E-Mail-Client-Komponente durch Eigenschafts-Tags (property tags, beispielsweise ptags) abgetrennt oder definiert werden. Eine Liste von Nachrichten kann beispielsweise für jede Nachricht einen Anfangsnachrichten-Tag und einen Endnachrichten-Tag enthalten. Zwischen den Anfangs- und End-ptags können ein Eigenschaftslisten-ptag und ein Themen-ptag mit der Eigenschaft einer Zeichenfolge (string) liegen. Auf den Themen-ptag kann das Thema selbst folgen. Weitere Eigenschafts-Tags können enthalten sein.
  • Für den Fall, dass ein Fehler beim Senden einer Nachricht auftritt, kam FXErrorInfo als ptag bereitgestellt werden und binäre Eigenschaften aufweisen, wie sie beispielsweise in vorstehender Tabelle definiert sind. Nachfolgend ist als Beispiel ein Datenstream angegeben, der sowohl eine erfolgreiche Nachricht wie auch eine Nachricht, in der ein Fehler auftritt, enthält. Für den Fall, dass der Fehler auftritt, wird der Endnachrichten-ptag für diese bestimmte Nachricht nicht verwendet, wobei der ptag FXErrorInfo der letzte ptag für diese Nachricht ist.
  • Figure 00380001
  • 15 zeigt Schritte, die eine E-Mail-Server-Komponente 502 einsetzen kann, um Nachrichten an eine E-Mail-Client-Komponente 501 einer älteren Version zu übertragen. Begonnen wird in Schritt 1501, wo die Nachrichtengruppe vorbereitet wird, und zwar beispielsweise durch Verbringen der Nachrichtengruppe in den Schnellübertragungsdatenspeicher. In Schritt 1502 beginnt man mit der Aussendung der Nachricht, so beispiels weise unmittelbar nach der Verbringung in den Sendepuffer der E-Mail-Server-Komponente 502. Tritt ein Fehler beim Aussenden der Nachricht auf, so wird ein schwerer Fernoperationsfehler an die E-Mail-Client-Komponente 501 in Schritt 1504 ausgesendet. Anschließend endet die Unterprozedur. Tritt beim Senden der Nachricht kein Fehler auf, so wird in Schritt 1503 eine Bestimmung dahingehend vorgenommen, ob weitere Nachrichten in der Gruppe vorhanden sind. Ist dem so, so kehrt der Prozess zu Schritt 1502 zurück, in dem die nächste Nachricht ausgesendet wird. Ist dem nicht so, so endet die Unterprozedur.
  • 15B zeigt eine Prozedur zum Umgang mit einer Nachrichtengruppe durch eine E-Mail-Server-Komponente 1502 einer aktuellen Version. Die unternommenen Schritte unterscheiden sich in Abhängigkeit davon, ob die E-Mail-Client-Komponente von einer aktuellen Version oder von einer älteren Version ist. Schritte 1501 bis 1504 werden mit einer E-Mail-Client-Komponente einer älteren Version unternommen und sind dieselben wie die mit denselben Bezugszeichen bezeichneten Schritte im vorhergehenden Abschnitt.
  • Wird in Schritt 1502 ein Fehler beim Senden der Nachricht vorgefunden, so wird in Schritt 1505 eine Bestimmung dahingehend vorgenommen, ob die Anforderung ein Flag, so beispielsweise FXRecoverMode, enthält. Enthält die Anforderung das Flag, so ist die E-Mail-Client-Komponente 501 eine aktuelle Version, und Schritt 1505 geht zu Schritt 1506 über, in dem FXErrorInfo an die E-Mail-Client-Komponente 501 ausgesendet wird. Der Prozess kann sodann zu Schritt 1503 übergehen. Enthält die Anforderung das Flag nicht, so geht Schritt 1505 zu Schritt 1504 über, wo ein schwerer Operationsfehler ausgesendet wird. Die Unterprozedur endet sodann.
  • Es ergibt sich, dass das Vorhandensein des Flags in der Anforderung ermöglicht, dass der Aussendeprozess weitergeht, indem ein Aussenden von FXErrorInfo ermöglicht wird, anstelle dass abgebrochen und ein schwerer Fernoperationsfehler ausgesendet würde. Das Flag wird von einer E-Mail-Client-Komponente 501 einer aktuellen Version ausgesendet. Ältere Versionen von E-Mail-Client-Komponenten enthalten das Flag nicht, was zu einem Fehler beim Aussenden eines schweren Fernoperationsfehlers, wie vorstehend beschrieben worden ist, führt.
  • Gegebenenfalls kann bei einem alternativen Ausführungsbeispiel die Fehlernachricht (beispielsweise FXErrorInfo) für bestimmte Eigenschaften einer Nachricht oder eines anderen Datenobjektes anstatt für eine gesamte Nachricht ausgesendet werden. So kann FXErrorInfo beispielsweise für den Körperbereich einer Nachricht oder für ein Attachment an der Nachricht ausgesendet werden. Die E-Mail-Client-Komponente 501 kann anschließend die Eigenschaften, die ohne einen Fehler erfolgreich gesendet worden sind, synchronisieren oder kopieren, wobei lediglich diejenigen Eigenschaften, die Fehler aufweisen, nicht synchronisiert oder kopiert werden.
  • Bisweilen kann eine Nachricht oder ein anderes Datenobjekt von einer derart ausreichenden Größe sein, dass sie/es mehrere FXGetBuffer-Antworten überspannt. Um mit derartigen Nachrichten umzugehen, kann die E-Mail-Client-Komponente 501 eine Wiederholungslogik enthalten, sodass sie sich einer beliebigen teilweise empfangenen Nachricht entledigen kann und anschließend dahingehend weitermacht, dass die weiteren Nachrichten nach dem Empfangen einer Fehlernachricht geeignet empfangen werden.
  • Bisweilen kann erwünscht sein, dass eine E-Mail-Client-Komponente mit einer Rückmeldung im Zusammenhang mit dem Prozess des Kopierens oder Synchronisierens von Datenobjekten, so beispielsweise von E-Mail-Nachrichten, versehen ist. Entsprechend einem Aspekt der vorliegenden Erfindung kann eine aktuelle Version einer E-Mail-Client-Komponente 501 anzeigen, dass sie in der Lage ist, mit Fortschrittsmodi umzugehen, beispielsweise durch Senden eines Flags wie PROGRESS_MODE, an eine E-Mail-Server-Komponente 502 beim Anfordern des Synchronisierens oder Kopierens von Datenobjekten. Als Antwort kann eine aktuelle Version einer E-Mail-Server-Komponente 502 eine Vielzahl von Informationen zusammen mit den Nachrichten senden, so beispielsweise die Gesamtgröße sämtlicher Nachrichten, die Gesamtanzahl der Nachrichten und die Gesamtgröße jeder Nachricht oder eine Kombination hieraus.
  • 16 zeigt ein Beispiel für eine E-Mail-Client-Komponente 501 einer älteren Version, wobei hier als Antwort auf eine Schnellübertragungsanforderung (1601 und 1603) für eine Gruppe von Nachrichten die E-Mail-Client-Komponente 501 die Nachrichten empfängt. In 16A werden Nachrichten in zwei Antworten 1604 und 1606 empfangen. In E-Mail-Client-Komponenten 501 einer älteren Version, wo ein Schnellübertragungsmechanismus zum Einsatz kommt, ist eine Fortschrittsanzeige der an den Client ausgesendeten Nachrichten nicht vorgesehen.
  • Ist jedoch, wie in 16B gezeigt ist, eine Antwort 1607 auf eine Anforderung einer Nachrichtengruppe seitens der E-Mail-Client-Komponente gegeben, so kann die E-Mail-Server-Komponente 502 eine Gesamtzahl von zur Übertragung anstehenden Datenobjekten sowie die Gesamtgröße sämtlicher zur Übertragung anstehenden Datenobjekte bereitstellen. Diese Information ist in 16B mit „Pall" bezeichnet. Eine aktuelle Version einer E-Mail-Server-Komponente 502 kann zudem die Größe jeder Nachricht angeben, was in 16B mit „P1, P2, P3, ..." bezeichnet ist. Darüber hinaus können gegebenenfalls die Informationen in Verknüpfung mit jeder Nachricht und mit der gesamten Gruppe von Nachrichten zusätzliche Informationen dahingehend beinhalten, ob jede Nachricht FAI oder eine tatsächliche E-Mail-Nachricht ist. Bei einem Ausführungsbeispiel werden die in 16B mit „Pall" bezeichneten Informationen stets als Antwort auf eine Schnellübertragungsanforderung gesendet, und zwar auch dann, wenn nur Datenobjekte übertragen werden, was die Verarbeitung des Datenstreams vereinfacht.
  • Ein Beispiel für das Format von Größe und Anzahl aller übertragenen Datenobjekte ist in der nachfolgenden Tabelle gezeigt.
    IncrSyncProgressMode
    Name des Attributes Typ des Attributes Anmerkungen
    Version WORD (beispielsweise eine ganze Zahl mit 16 Bit) Version dieser Struktur
    cAssocMsgs DWORD (beispielsweise eine ganze Zahl mit 32 Bit) Anzahl der zur Übertragung anstehenden FAI-Datenobjekte
    IITotalAssocMsgSize DWORD (beispielsweise eine ganze Zahl mit 64 Bit) Gesamtgröße aller zur Übertragung anstehenden FAI-Datenobjekte
    cNormalMsgs DWORD Anzahl der zur Übertragung, anstehenden E-Mail-Nachrichten
    IITotalNormalMsgSize QWORD Anzahl aller zur Übertragung anstehenden E-Mail-Nachrichten
  • Es ergibt sich, dass gesonderte Attribute für die Anzahl von FAI-Datenobjekten, die Gesamtgröße aller FAI-Datenobjekte, die Anzahl der zur Übertragung anstehenden E-Mail-Nachrichten und die Gesamtgröße aller zur Übertragung anstehenden E-Mail-Nachrichten definiert werden können. Andere Kombinationen und zusätzliche Attribute können je nach Bedarf zu dem Format hinzugefügt werden.
  • Die nachfolgende Tabelle zeigt ein Format für die Größe und andere Informationen, die mit jeder Nachricht einhergehen können.
    IncrSyncProgressModePerMsg
    Name des Attributes Typ des Attributes Anmerkungen
    Größe der Nachricht LONG (lang) Größe der nächsten Nachricht
    FAI-Flag BOOL gibt an, ob die nächste Nachricht FAI ist
  • Es ist ersichtlich, dass das Format die Größe der nächsten Nachricht und Informationen dahingehend, ob die nächste Nachricht FAI ist, beinhaltet.
  • 17A und 17B zeigen Schritte zum Senden einer Nachrichtengruppe entsprechend einer älteren Version der E-Mail-Komponenten beziehungsweise einer aktuellen Version der E-Mail-Komponenten. Die Schritte in 17A sind ähnlich zu den Schritten 1501 bis 1503 in 15A. Mit Blick auf 17B bleibt festzuhalten, dass das Flag PROGESSMODE, beispielsweise mit einer Fernoperation, von einer aktuellen E-Mail-Client-Komponente 501 gesendet worden ist. Nachdem die Nachricht in Schritt 1701 vorbereitet worden ist, wird eine Bestimmung dahingehend vorgenommen, ob das Flag vorhanden ist. Ist dem so, so werden die Fortschrittsdaten insgesamt in Schritt 1702 gesendet, woraufhin der Prozess zu Schritt 1502 übergeht, in dem die erste Nachricht gesendet wird. Ist das Flag nicht vorhanden, so geht Schritt 1701 direkt zu Schritt 1502 über.
  • Nachdem die erste Nachricht gesendet worden ist, geht der Prozess zu Schritt 1703 über, wo eine Bestimmung dahingehend erfolgt, ob das Flag vorhanden ist. Ist dem so, so geht Schritt 1703 zu Schritt 1704 über, wo die Fortschrittsdaten pro Nachricht gesendet werden. Der Prozess geht sodann zu Schritt 1503 über, der bereits beschrieben worden ist. Ist das Flag nicht vorhanden, so geht Schritt 1703 direkt zu Schritt 1503 über.
  • Ein Beispiel für das Senden von Daten für eine aktuelle Server-Komponente, die Daten an eine aktuelle Client-Komponente sendet, ist nachstehend dargestellt. Das Senden von Daten ist ähnlich dem Senden von Daten gemäß vorstehender Beschreibung, enthält jedoch zusätzlich ptags für Fortschrittsgesamtdaten (ptagIncrSyncProgressMode), die beispielsweise binäre Eigenschaften aufweisen können. Für jede Nachricht sind beispielsweise die Fortschrittsdaten pro Nachricht, beispielsweise PtagIncrSyncProgressModePerMsg, bereitgestellt.
  • Figure 00430001
  • In dem gezeigten Beispiel sind die ptags, die die Fortschrittsgesamtdaten (ptagIncrSyncProgressMode) und die ptags für die Nachrichtenfortschrittsdaten (ptagIncrSyncProgressModePerMsg) enthalten, vor der Liste der Nachrichten beziehungsweise vor jeder Nachricht angesiedelt. Gleichwohl kann die Struktur des Sendens der Datenobjekte derart umgestaltet werden, dass die Fortschrittsdaten in den Nachrichten oder in der Nachrichtenliste enthalten sind. Es ist darüber hinaus möglich, die Struktur des Sendens von Datenobjekten derart umzugestalten, dass ptag-Begrenzungsnachrichten und/oder Nachrichtenlisten in Gänze beseitigt werden.
  • Eine E-Mail-Client-Komponente, die Fortschrittsdaten empfängt, kann diese Daten zur Bestimmung des Fortschrittes des Synchronisierens oder Kopierens von Datenobjekten von der E-Mail-Server-Komponente und die Fortschrittsdaten pro Nachricht zur Bestimmung des Fortschrittes bei jeder einzelnen Nachricht verwenden. Diese Informationen können beispielsweise beim Überwachen von Echtzeitinformationen hinsichtlich des Fortschrittes einer Synchronisierung hilfreich sein.
  • Es gibt verschiedene Zeichensätze, die zum Speichern von E-Mail-Nachrichten oder anderen Datenobjekten verwendet werden können. So ist beispielsweise ASCII der zur Speicherung von englischsprachigen Zeichen am häufigsten benutzte Zeichensatz. Gleichwohl ist ASCII zum Speichern von Zeichen in allen Sprachen nicht ausreichend, da er auf 8 Bit umfassenden Zeichen beruht. Daher kann der ASCII-Code nur für 256 Zeichen verwendet werden, was genug für das Englische, jedoch nicht genug für Sprachen ist, die über weitere Zeichen verfügen. Unicode ist demgegenüber ein Zeichensatz, der auf 16 Bit (2 Byte) für jedes Schriftzeichen zugreift und daher in der Lage ist, mehr Schriftzeichen als ASCII darzustellen. Unicode kann 65.536 Zeichen umfassen und wird daher zur Codierung nahezu sämtlicher Sprachen der Welt verwendet. Unicode enthält den ASCII-Zeichensatz in sich.
  • Im Allgemeinen weisen ältere Versionen von E-Mail-Client-Komponenten 501 eine bestimmte Codeseite (codepage) oder einen Zeichensatz und/oder eine damit verknüpfte Sprache auf. Eine bestimmte Version der E-Mail-Client-Komponente 501 kann beispielsweise eine deutsche Codeseite aufweisen, während eine andere Version eine ANSI-Codeseite aufweist. Bisweilen kann es für eine E-Mail-Client-Komponente 501 wünschenswert sein, E-Mails im Zeichensätzen zu empfangen, die nicht der bezeichneten Codeseite entsprechen. Entsprechend einem Aspekt der vorliegenden Erfindung kann eine aktuelle Client-Komponente eine E-Mail-Server-Komponente zwingen, alle E-Mails in Unicode darzustellen. Sobald die E-Mails von der E-Mail-Client-Komponente 501 empfangen worden sind, können die Unicode-E-Mails in die dem Client zu eigene Codeseite umgewandelt werden oder alternativ in Unicode verbleiben.
  • Um anzuzeigen, dass eine E-Mail-Client-Komponente 501 E-Mails abruft, die in Unicode bereitgestellt werden sollen, kann die Client-Komponente 501 beispielsweise ein Flag, so beispielsweise FORCEUNICODE, für die E-Mail-Server-Komponente 502 bereitstellen. Das Flag kann mit einer Anforderung, so beispielsweise einer Fernoperation, versehen sein. Ist die E-Mail-Server-Komponente 502 eine aktuelle Version, so kann die E-Mail-Server-Komponente 502 eine Unicode-Version, falls verfügbar, bereitstellen oder kann E-Mail-Nachrichten in andere Zeichensätze als Unicode umwandeln.
  • 20 zeigt die Schritte zur Bereitstellung eines bestimmten Zeichensatzes für eine Nachricht entsprechend einem Aspekt der vorliegenden Erfindung. Beginnend in Schritt 2001 ruft zunächst die E-Mail-Server-Komponente 502 eine Nachricht aus ihrem Datenspeicher ab. In Schritt 2002 wird eine Bestimmung dahingehend vorgenommen, ob das Flag FORCEUNICODE vorhanden ist. Ist dem nicht so, so geht Schritt 2002 zu Schritt 2003 über, wo die E-Mail-Server-Komponente 502 die E-Mail-Nachricht in der der E-Mail-Client-Komponente zu eigenen bestimmten Codeseite bereitstellt und gegebenenfalls eine Umwandlung vornimmt.
  • Ist das Flag FORCEUNICODE vorhanden, so geht Schritt 2002 zu Schritt 2004 über, wo eine Bestimmung dahingehend vorgenommen wird, ob die Nachricht als Unicode gespeichert ist. Ist dem so, so geht Schritt 2004 zu Schritt 2005 über, wo die Nachricht für die E-Mail-Client-Komponente 501 im Unicode-Zeichensatz bereitgestellt wird. Ist die Nachricht nicht in Unicode gespeichert, so geht Schritt 2004 zu Schritt 2006 über, wo die Nachricht in Unicode umgewandelt wird, woraufhin der Prozess bei Schritt 2005 weitergeht, wo die Nachricht für die E-Mail-Client-Komponente in Unicode bereitgestellt wird.
  • Die Verwendung der Begriffe „ein/eine/ein" und „der/die/das" und ähnlicher Worte im Kontext der Beschreibung der Erfindung (insbesondere im Kontext der nachfolgenden Ansprüche) soll sich sowohl auf den Singular wie auch auf den Plural beziehen, außer dies ist durch den Kontext eindeutig anderweitig nahegelegt. Die Begriffe „umfassend, „aufweisend", „beinhaltend" und „enthaltend" sollen als nicht abgeschlossene Begriffe (das heißt in der Bedeutung „beinhaltend, aber nicht beschränkt hierauf") verstanden werden, außer dies wird anderweitig angegeben. Die Nennung von Wertebereichen soll nur als Kurzschreibweise für eine Bezugnahme auf jeden einzelnen Wert, der in dem Bereich vorhanden ist, dienen, außer dies ist explizit anders angegeben, wobei jeder einzelne Wert genauso in der Beschreibung enthalten sein soll, als würde er dort explizit genannt. Sämtliche hier beschriebenen Verfahren können in einer geeigneten Reihenfolge ausgeführt werden, außer dies ist explizit anders niedergelegt oder der Kontext legt Gegenteiliges nahe. Die Verwendung beliebiger Beispiele oder aller Beispiele oder auf Beispiele hinweisender Wendungen (beispielsweise) soll in der vorliegenden Beschreibung nur einer besseren Erläuterung der Erfindung dienen und keinerlei Beschränkung des Schutzumfanges darstellen, außer dies ist anderweitig angegeben. Keine Angabe in der Beschreibung soll derart verstanden werden, dass sie ein nichtbeanspruchtes Element als wesentlich für die Umsetzung der Erfindung in die Praxis angibt.

Claims (18)

  1. Datenpaket, das auf einem computerlesbaren Medium ausgeführt ist, wobei es umfasst: ein erstes Datenfeld, das eine E-Mail-Client-Komponente identifiziert; ein zweites Datenfeld, das eine Anforderung einer Vielzahl von E-Mail-Datenobjekten enthält; und dadurch gekennzeichnet, dass es umfasst: ein drittes Datenfeld, das eine Anzeige dahingehend enthält, dass die E-Mail-Client-Komponente Fortschrittsmodus-Daten verarbeiten kann, die zusammen mit der Vielzahl angeforderter E-Mail-Datenobjekte gesendet werden, wobei die Fortschrittsmodus-Daten eine Gesamtgröße der Vielzahl der E-Mail-Datenobjekten, eine Gesamtzahl von E-Mail Nachrichten in der Vielzahl von E-Mail-Datenobjekten sowie eine Größe jedes der E-Mail-Datenobjekte enthalten.
  2. Datenpaket nach Anspruch 1, wobei die Anzeige ein Flag umfasst, das in der Anforderung enthalten ist.
  3. Datenpaket nach Anspruch 1, wobei die Anforderung eine Anforderung von Synchronisation eines Ordners umfasst, in dem sich die E-Mail-Datenobjekte befinden.
  4. Datenpaket nach Anspruch 1, wobei die Anforderung eine Anforderung einer Kopie von E-Mail-Nachrichten umfasst.
  5. Datenpaket nach Anspruch 1, wobei die Fortschrittsmodus-Daten die Anzahl von Ordnerverknüpfungsinformations (folder associated information – FAI) – Objekten in der Vielzahl von E-Mail-Datenobjekten enthalten.
  6. Datenpaket nach Anspruch 5, wobei die Fortschrittsmodus-Daten die Größe aller FA-Objekte in der Vielzahl von E-Mail-Datenobjekten enthalten.
  7. Datenpakete nach Anspruch 1, wobei die Fortschrittsmodus-Daten des Weiteren Informationen darüber enthalten, ob jedes Objekt ein FAI-Objekte ist.
  8. Computerlesbares Medium, das durch Computer ausführbare Befehle aufweist, wobei die Befehle umfassen: Empfangen einer Anforderung einer Vielzahl von E-Mail-Datenobjekten und einer Anzeige von einer E-Mail-Client-Komponente dahingehend, dass die E-Mail-Client-Komponente in der Lage ist, Fortschrittsmodus-Daten zu verarbeiten; In Reaktion auf die Anforderung und die Anzeige Abrufen der Vielzahl von E-Mail-Datenobjekten; und Bereitstellen von Fortschrittsmodus-Daten für die E-Mail-Client-Komponente zusammen mit der Vielzahl von der E-Mail-Datenobjekten, wobei die Fortschrittsmodus-Daten eine Größe jedes der E-Mail-Datenobjekte, eine Gesamtgröße der Vielzahl von E-Mail-Datenobjekten und eine Gesamtzahl von E-Mail-Nachrichten in der Vielzahl von E-Mail-Datenobjekten umfassen.
  9. Computerlesbares Medium nach Anspruch 8, wobei die Anzeige ein Flag umfasst, das in der Anforderung enthalten ist.
  10. Computerlesbares Medium nach Anspruch 8, wobei die Anforderung eine Anforderung von Synchronisation eines Ordners umfasst, in dem sich die E-Mail-Datenobjekte befinden.
  11. Computerlesbares Medium nach Anspruch 8, wobei die Anforderung eine Anforderung einer Kopie von E-Mail-Nachrichten umfasst.
  12. Computerlesbares Medium nach Anspruch 8, wobei die Fortschrittsmodus-Daten des Weiteren die Anzahl von Ordnerverknüpfungsinformations (folder associated information-FAI)-Objekten in der Vielzahl von E-Mail-Datenobjekten enthalten.
  13. Computerlesbares Medium nach Anspruch 12, wobei die Frotschrittsmodus-Daten des Weiteren die Größe aller FAI-Objekte in der Vielzahl von E-Mail-Datenobjekten enthalten.
  14. Computerlesbares Medium nach Anspruch 8, wobei die Fortschrittsmodus-Daten des Weiteren Informationen darüber enthalten, ob jedes Ebenen-Mail-Datenobjekt ein FAI-Objekt ist.
  15. Computerimplentiertes Verfahren, das die folgenden Schritte umfasst: Senden einer Anforderung einer Vielzahl von E-Mail-Datenobjekten und einer Anzeige von einer E-Mail-Client-Komponente dahin gehend, dass die E-Mail-Client-Komponente Fortschrittsmodus-Daten verarbeiten kann, die zusammen mit der Vielzahl angeforderter E-Mail-Datenobjekte gesendet werden, wobei die Fortschrittsmodusdaten eine Größe jedes der E-Mail-Datenobjekte, eine Gesamtgröße der Vielzahl von E-Mail-Datenobjekten und eine Gesamtzahl von E-Mailnachrichten in der Vielzahl von E-Mail-Datenobjekten enthalten; in Reaktion auf die Anforderung und die Anzeige Abrufen der Vielzahl von E-Mail-Datenobjekten und Fortschrittsmodus-Daten für die Vielzahl von E-Mail-Datenobjekten an einer E-Mail-Server-Komponente; und an der E-Mail-Client-Komponente Empfangen der Fortschrittsmodus-Daten, die zusammen mit der Vielzahl angeforderter E-Mail-Datenobjekte gesendet werden, und Nutzen der Fortschrittsmodus-Daten, um Sendefortschritt der Vielzahl von E-Mail-Datenobjekten zu der E-Mail-Client-Komponente zu überwachen.
  16. Verfahren nach Anspruch 15, wobei die Fortschrittsmodus-Daten die Anzahl von Ordnerverknüpfungsinformations (folder associated information-FAI)-Objekten in der Vielzahl von E-Mail-Datenobjekten umfassen.
  17. Verfahren nach Anspruch 16, wobei die Fortschrittsmodus-Daten die Größe aller FAI-Objekte in der Vielzahl von E-Mail-Datenobjekten umfassen.
  18. Verfahren nach Anspruch 15, wobei die Fortschrittsmodus-Daten des Weiteren Informationen darüber enthalten, ob jedes Datenobjekt ein FAI-Objekt ist.
DE60317453T 2003-01-03 2003-12-03 Verfahren zur Datenströmung zwischen einem Server und einem Client Expired - Lifetime DE60317453T2 (de)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US43786903P 2003-01-03 2003-01-03
US437869P 2003-01-03
US367161 2003-02-14
US10/367,161 US7620688B2 (en) 2003-01-03 2003-02-14 Progress mode for electronic mail component

Publications (2)

Publication Number Publication Date
DE60317453D1 DE60317453D1 (de) 2007-12-27
DE60317453T2 true DE60317453T2 (de) 2008-03-06

Family

ID=32511093

Family Applications (2)

Application Number Title Priority Date Filing Date
DE60317453T Expired - Lifetime DE60317453T2 (de) 2003-01-03 2003-12-03 Verfahren zur Datenströmung zwischen einem Server und einem Client
DE60335218T Expired - Lifetime DE60335218D1 (de) 2003-01-03 2003-12-03 Verfahren und Vorrichtung zur verbesserten Kommunikation zwischen einem Server und einem Client

Family Applications After (1)

Application Number Title Priority Date Filing Date
DE60335218T Expired - Lifetime DE60335218D1 (de) 2003-01-03 2003-12-03 Verfahren und Vorrichtung zur verbesserten Kommunikation zwischen einem Server und einem Client

Country Status (16)

Country Link
US (1) US7620688B2 (de)
EP (3) EP1631024B1 (de)
JP (1) JP4438989B2 (de)
KR (1) KR101021385B1 (de)
CN (1) CN100433733C (de)
AT (2) ATE378758T1 (de)
AU (1) AU2003268611B2 (de)
BR (1) BR0306065A (de)
CA (2) CA2452527C (de)
DE (2) DE60317453T2 (de)
HK (1) HK1066953A1 (de)
MX (1) MXPA03011674A (de)
MY (1) MY137065A (de)
PL (1) PL364157A1 (de)
RU (1) RU2331920C2 (de)
TW (1) TWI339052B (de)

Families Citing this family (29)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2003105004A1 (en) * 2002-06-06 2003-12-18 Crescendo Networks Ltd. System and method for connecting multiple slow connections to multiple fast connections
US7111039B2 (en) 2002-11-20 2006-09-19 Microsoft Corporation System and method for using packed compressed buffers for improved client server communications
US7650403B2 (en) 2002-11-20 2010-01-19 Microsoft Corporation System and method for client side monitoring of client server communications
US7386590B2 (en) * 2003-01-03 2008-06-10 Microsoft Corporation System and method for improved synchronization between a server and a client
US20150195231A1 (en) * 2004-09-30 2015-07-09 Nahush Mahajan System and Method for Avoiding Loops in Automatic Message Processing
KR100659584B1 (ko) * 2004-12-07 2006-12-20 한국전자통신연구원 메시지 교환 방법
US7788237B2 (en) * 2004-12-17 2010-08-31 Microsoft Corporation Method and system for tracking changes in a document
US7805629B2 (en) * 2005-03-04 2010-09-28 Netapp, Inc. Protecting data transactions on an integrated circuit bus
US8090810B1 (en) 2005-03-04 2012-01-03 Netapp, Inc. Configuring a remote management module in a processing system
US7899680B2 (en) * 2005-03-04 2011-03-01 Netapp, Inc. Storage of administrative data on a remote management device
US8291063B2 (en) * 2005-03-04 2012-10-16 Netapp, Inc. Method and apparatus for communicating between an agent and a remote management module in a processing system
US7610345B2 (en) 2005-07-28 2009-10-27 Vaporstream Incorporated Reduced traceability electronic message system and method
US9282081B2 (en) 2005-07-28 2016-03-08 Vaporstream Incorporated Reduced traceability electronic message system and method
US7471218B2 (en) * 2006-09-18 2008-12-30 National Semiconductor Corporation Methods and systems for efficiently storing and retrieving streaming data
CN100417074C (zh) * 2006-09-30 2008-09-03 中兴通讯股份有限公司 一种无线局域网ip组播传输异常的快速检测方法
US20090037735A1 (en) * 2007-08-01 2009-02-05 O'farrell David Method and system for delivering secure messages to a computer desktop
US8396928B2 (en) * 2007-09-21 2013-03-12 Smartbrief, Inc. Methods and systems for handling electronic message content for electronic communications devices
US8407296B2 (en) * 2007-09-24 2013-03-26 Smartbrief, Inc. Multiple and multi-part message methods and systems for handling electronic message content for electronic communications devices
US8949344B2 (en) * 2008-09-15 2015-02-03 Microsoft Corporation Asynchronous queued messaging for web applications
CN101583150B (zh) * 2009-06-18 2011-04-20 中兴通讯股份有限公司 一种无线接入点检测无线终端异常的方法及装置
US8504818B2 (en) * 2010-04-15 2013-08-06 Microsoft Corporation Method and system for reliable protocol tunneling over HTTP
US9084180B2 (en) * 2011-12-14 2015-07-14 Qualcomm Incorporated Systems and methods for transmitting and receiving discovery and paging messages
US10158594B2 (en) 2015-09-16 2018-12-18 Microsoft Technology Licensing, Llc Group headers for differentiating conversation scope and exposing interactive tools
US10516630B2 (en) 2016-11-01 2019-12-24 Microsoft Technology Licensing, Llc Switching synchronization systems for synchronizing server/client data
US11405345B2 (en) 2016-11-01 2022-08-02 Microsoft Technology Licensing, Llc E-mail with smart reply and roaming drafts
US10812434B2 (en) 2017-03-23 2020-10-20 Blackberry Limited Apparatus and method for maintaining message databases in eventual consistency distributed database systems
FR3064437A1 (fr) * 2017-03-24 2018-09-28 Orange Procede de recommandation d'une pile de communication
US11347375B2 (en) * 2018-03-21 2022-05-31 Atlassian Pty Ltd. Digital task management using an intermediary single-account issue inbox system
CN114124925B (zh) * 2020-08-25 2023-05-12 华为技术有限公司 一种电子邮件的同步方法及电子设备

Family Cites Families (49)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPS63205747A (ja) 1987-02-13 1988-08-25 インターナシヨナル・ビジネス・マシーンズ・コーポレーシヨン 通信方法及びデータ処理システム
RU2095857C1 (ru) 1989-01-17 1997-11-10 Филипс Электроникс Н.В. Способ передачи информации с использованием носителя данных, носитель информации и устройство для воспроизведения информации с такого носителя
JP3612652B2 (ja) 1992-06-18 2005-01-19 インターナシヨナル・ビジネス・マシーンズ・コーポレイシヨン ローカル・コンピュータ上で実行されるローカル・タスクによってリモート・コンピュータ上のリモート・タスクを実行する方法
US5537551A (en) * 1992-11-18 1996-07-16 Denenberg; Jeffrey N. Data compression method for use in a computerized informational and transactional network
US5325361A (en) 1992-12-01 1994-06-28 Legent Corporation System and method for multiplexing data transmissions
JP3184763B2 (ja) 1995-06-07 2001-07-09 インターナショナル・ビジネス・マシーンズ・コーポレ−ション マルチメディア直接アクセス記憶装置及びフォーマット方法
US5923846A (en) * 1995-11-06 1999-07-13 Microsoft Corporation Method of uploading a message containing a file reference to a server and downloading a file from the server using the file reference
US6151643A (en) 1996-06-07 2000-11-21 Networks Associates, Inc. Automatic updating of diverse software products on multiple client computer systems by downloading scanning application to client computer and generating software list on client computer
JP3082245B2 (ja) 1996-09-03 2000-08-28 トヨタ自動車株式会社 情報通信制御装置及びそのシステム
US6377978B1 (en) * 1996-09-13 2002-04-23 Planetweb, Inc. Dynamic downloading of hypertext electronic mail messages
US6233318B1 (en) 1996-11-05 2001-05-15 Comverse Network Systems, Inc. System for accessing multimedia mailboxes and messages over the internet and via telephone
JP3318503B2 (ja) 1997-02-27 2002-08-26 京セラ株式会社 無線通信システム
JPH1168987A (ja) 1997-08-15 1999-03-09 Sony Corp 情報通信システム、情報通信端末、サーバ装置および情報通信方法
US6073137A (en) 1997-10-31 2000-06-06 Microsoft Method for updating and displaying the hierarchy of a data store
US6219669B1 (en) 1997-11-13 2001-04-17 Hyperspace Communications, Inc. File transfer system using dynamically assigned ports
US6324587B1 (en) 1997-12-23 2001-11-27 Microsoft Corporation Method, computer program product, and data structure for publishing a data object over a store and forward transport
US6167402A (en) * 1998-04-27 2000-12-26 Sun Microsystems, Inc. High performance message store
FI105971B (fi) 1998-04-30 2000-10-31 Nokia Mobile Phones Ltd Menetelmä ja laitteisto sähköpostin käsittelemiseksi
US6134582A (en) 1998-05-26 2000-10-17 Microsoft Corporation System and method for managing electronic mail messages using a client-based database
US20010054115A1 (en) * 1998-05-29 2001-12-20 Tabitha Ferguson System and method for bundling information
US6438585B2 (en) 1998-05-29 2002-08-20 Research In Motion Limited System and method for redirecting message attachments between a host system and a mobile data communication device
CA2275840A1 (en) 1998-08-18 2000-02-18 Lucent Technologies Inc. Generalized messaging construct
US6886030B1 (en) 1998-08-18 2005-04-26 United Video Properties, Inc. Electronic mail system employing a low bandwidth link for e-mail notifications
US6639687B1 (en) * 1998-09-08 2003-10-28 International Business Machines Corporation Progress indicator for multiple actions
US6484156B1 (en) 1998-09-15 2002-11-19 Microsoft Corporation Accessing annotations across multiple target media streams
US6324544B1 (en) 1998-10-21 2001-11-27 Microsoft Corporation File object synchronization between a desktop computer and a mobile device
JP3603936B2 (ja) 1999-01-22 2004-12-22 株式会社ソニー・コンピュータエンタテインメント 電子メール広告システム
US6449634B1 (en) 1999-01-29 2002-09-10 Digital Impact, Inc. Method and system for remotely sensing the file formats processed by an E-mail client
WO2000057612A2 (en) 1999-03-22 2000-09-28 Webxi Application layer protocol
US6304898B1 (en) 1999-10-13 2001-10-16 Datahouse, Inc. Method and system for creating and sending graphical email
US6993559B2 (en) 2000-02-14 2006-01-31 Bigbow.Com, Inc. System, method, apparatus and computer program product for operating a web site by electronic mail
US6684088B1 (en) 2000-03-01 2004-01-27 Axi Mobile Ltd. System and method for displaying electronic mail messages on a low bandwidth device
EP2237580B1 (de) 2000-04-10 2013-01-09 Research In Motion Limited System und Verfahren zur Anzeige des Zustandes einer Nachricht
JP2001339422A (ja) 2000-05-25 2001-12-07 Mitsubishi Electric Corp メールデータ管理システム
WO2002021749A2 (en) 2000-09-08 2002-03-14 Plumtree Software Providing a personalized web page by accessing different servers
EP1235396A4 (de) 2000-09-26 2004-01-07 Interlex Inc System und verfahren zur verwendung elektronischer post als werbemedium
US6934734B2 (en) 2000-12-04 2005-08-23 International Business Machines Corporation Method and apparatus for managing and presenting changes to an object in a data processing system
FI20002854A (fi) 2000-12-22 2002-06-23 Nokia Corp Etälataamisen tilaindikaattorit langattomissa lyhyen kantaman laitteissa
CA2329891A1 (en) 2000-12-29 2002-06-29 Subsecond Technology Inc. Method and apparatus for remote database maintenance and access
JP2002208959A (ja) 2001-01-09 2002-07-26 Casio Comput Co Ltd 電子メールサーバ装置、電子メール転送制御方法及び記録媒体
AUPR444601A0 (en) 2001-04-17 2001-05-17 Pro-Super Holdings Limited Business tracking system
JP3798263B2 (ja) 2001-06-01 2006-07-19 三菱電機株式会社 電子メールサーバ及び電子メールキャッシュ方法及び電子メールキャッシュプログラム
US7149813B2 (en) 2001-08-14 2006-12-12 Microsoft Corporation Method and system for synchronizing mobile devices
US20030177171A1 (en) 2002-01-22 2003-09-18 Brown Bruce Loring Electronic mail retrieval
US20030231207A1 (en) * 2002-03-25 2003-12-18 Baohua Huang Personal e-mail system and method
US6868143B1 (en) 2002-10-01 2005-03-15 Bellsouth Intellectual Property System and method for advanced unified messaging
US20040068544A1 (en) * 2002-10-08 2004-04-08 Bellsouth Intellectual Property Corporation Multi-user e-mail client and alert schema
US7366760B2 (en) 2003-01-03 2008-04-29 Microsoft Corporation System and method for improved client server communications of email messages
US7386590B2 (en) 2003-01-03 2008-06-10 Microsoft Corporation System and method for improved synchronization between a server and a client

Also Published As

Publication number Publication date
KR20040062891A (ko) 2004-07-09
JP4438989B2 (ja) 2010-03-24
CA2452527A1 (en) 2004-07-03
US7620688B2 (en) 2009-11-17
KR101021385B1 (ko) 2011-03-14
EP1631024B1 (de) 2013-01-16
AU2003268611B2 (en) 2009-07-09
AU2003268611A1 (en) 2004-07-22
MY137065A (en) 2008-12-31
EP1631024A3 (de) 2006-05-31
DE60335218D1 (de) 2011-01-13
RU2331920C2 (ru) 2008-08-20
EP1631025A2 (de) 2006-03-01
CN100433733C (zh) 2008-11-12
JP2004215279A (ja) 2004-07-29
EP1631025B9 (de) 2011-12-21
CA2841691A1 (en) 2004-07-03
CA2452527C (en) 2016-08-23
CN1518304A (zh) 2004-08-04
TW200421802A (en) 2004-10-16
TWI339052B (en) 2011-03-11
DE60317453D1 (de) 2007-12-27
MXPA03011674A (es) 2005-02-25
ATE490632T1 (de) 2010-12-15
PL364157A1 (en) 2004-07-12
EP1435711B1 (de) 2007-11-14
EP1631025A3 (de) 2006-05-17
EP1631024A2 (de) 2006-03-01
EP1435711A1 (de) 2004-07-07
CA2841691C (en) 2015-02-17
BR0306065A (pt) 2005-05-17
RU2003137881A (ru) 2005-06-10
EP1631025B1 (de) 2010-12-01
US20040133643A1 (en) 2004-07-08
ATE378758T1 (de) 2007-11-15
HK1066953A1 (en) 2005-04-01

Similar Documents

Publication Publication Date Title
DE60317453T2 (de) Verfahren zur Datenströmung zwischen einem Server und einem Client
DE69926940T2 (de) Verfahren und System zum Auslagern der Konversionen von Nachrichtenanhängen
DE602006000660T2 (de) Platzsparende Speicherung und Archivierung von elektronischer Post auf Basis einer Kommunikationsstruktur
DE60317925T2 (de) Steuerung von netzwerkverkehr in einer peer-to-peer umgebung
DE69736045T2 (de) Verfahren zum Übertragen und Darstellen von Datenseiten in einem Datennetzwerk
EP2490393B1 (de) Verfahren und Vorrichtung zur Analyse von Datenpaketen
DE60015423T2 (de) Verfahren und Vorrichtung zur Objektwiedergabe in einem Netzwerk
DE60203550T2 (de) Verfahren, System and Computerprogrammprodukt für die Synchronisation von verschiedenen Datenstrukturen durch Benutzung von Aktualisierungsmeldungen
DE10064627B4 (de) Verfahren und System für die Verarbeitung von E-Mail-Nachrichten in einem Datenübertragungssystem
DE602005000984T2 (de) Verfahren und Vorrichtung zur Speicherung von Eingangs-Filterkriterien und zur Spezifizierung von Triggerpunkt-Vorlagen zum Zeitpunkt der Diensteimplementierung
DE60129232T2 (de) Xml-kodierungsverfahren
DE69821050T2 (de) Datenstromdifferenzierungssystem für Endgerätemulator
DE60305035T2 (de) Anpassen des längsten präfix unter verwendung von baumartigen "bitmap" datenstrukturen
DE60214823T2 (de) Verfahren und System für eine verteilte Multicastcachetechnik
DE60109467T2 (de) Verfahren und vorrichtung zur übertragung von netzwerkinformationen durch sichere transkodierung
EP1522028B9 (de) Verfahren und vorrichtungen zum kodieren/dekodieren von strukturierten dokumenten, insbesondere von xml-dokumenten
DE69832057T2 (de) Datendienst in einem mobilen kommunikationsnetz
DE602005002679T2 (de) WEB-Dienst-Anwendungsprotokoll und SOAP-Verarbeitungsmodell
DE69534411T2 (de) Offenes Transaktionverwaltungszugriffsystem und Verfahren
DE602004004200T2 (de) System und Verfahren zum Verwalten von gepufferten Objekten unter Verwendung von Mitteilungsverbindungen
DE60204031T2 (de) Hierarchische cachespeicherung in telekommunikationsnetzen
DE602004004601T2 (de) Verteilung von Mitgliedschaftsinformationen für Mehrfachteilnehmersitzungen auf der Applikationsebene
EP1605649A1 (de) Verfahren und Vorrichtung zum Verwalten von elektronischen Nachrichten
DE602005001322T2 (de) Speichern, Übertragen und Empfangen von Textnachrichtenketten auf einem drahtlosen Kommunikationsgerät
DE602005004370T2 (de) Synchronisation von Server- und Geräte-Daten unter Benutzung von Geräte-Daten-Schemata

Legal Events

Date Code Title Description
8364 No opposition during term of opposition