DE10356724B3 - Verfahren zum Verringern des Transportvolumens von Daten in Datennetzen - Google Patents

Verfahren zum Verringern des Transportvolumens von Daten in Datennetzen Download PDF

Info

Publication number
DE10356724B3
DE10356724B3 DE10356724A DE10356724A DE10356724B3 DE 10356724 B3 DE10356724 B3 DE 10356724B3 DE 10356724 A DE10356724 A DE 10356724A DE 10356724 A DE10356724 A DE 10356724A DE 10356724 B3 DE10356724 B3 DE 10356724B3
Authority
DE
Germany
Prior art keywords
proxy
data
client
message digest
server
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Fee Related
Application number
DE10356724A
Other languages
English (en)
Inventor
Michael Angermann
Jens Kammann
Patrick Dr. Robertson
Christian Wasel
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.)
Deutsches Zentrum fuer Luft und Raumfahrt eV
Original Assignee
Deutsches Zentrum fuer Luft und Raumfahrt eV
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 Deutsches Zentrum fuer Luft und Raumfahrt eV filed Critical Deutsches Zentrum fuer Luft und Raumfahrt eV
Priority to DE10356724A priority Critical patent/DE10356724B3/de
Priority to EP04027953A priority patent/EP1538804B1/de
Priority to AT04027953T priority patent/ATE510394T1/de
Priority to US11/002,602 priority patent/US20050117558A1/en
Application granted granted Critical
Publication of DE10356724B3 publication Critical patent/DE10356724B3/de
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/329—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer [OSI layer 7]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/90—Details of database functions independent of the retrieved data types
    • G06F16/95—Retrieval from the web
    • G06F16/957—Browsing optimisation, e.g. caching or content distillation
    • G06F16/9574—Browsing optimisation, e.g. caching or content distillation of access to content, e.g. by caching
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/12—Applying verification of the received information
    • H04L63/123—Applying verification of the received information received data contents, e.g. message integrity
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/04—Protocols specially adapted for terminals or networks with limited capabilities; specially adapted for terminal portability
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/2866—Architectures; Arrangements
    • H04L67/288—Distributed intermediate devices, i.e. intermediate devices for interaction with other intermediate devices on the same level
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H04L67/568—Storing data temporarily at an intermediate stage, e.g. caching
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H04L67/565—Conversion or adaptation of application format or content
    • H04L67/5651—Reducing the amount or size of exchanged application data

Abstract

In einem Proxy-Server (CP) wird aus den auf eine Anfrage eines Clients (CA) von einer Datenquelle (SA) ausgegebenen Antwortdaten ein Message-Digest (MD) gebildet, der in diesem Proxy-Server durch Vergleichen dahingehend überprüft wird, ob bereits vorher ein übereinstimmender Message-Digest in diesem Proxy-Server für den betreffenden Client gespeichert worden ist. Wenn ja, dann wird dem Client von diesem Proxy-Server zusammen mit dem Message-Digest eine kurze Antwortmeldung (HIT) übermittelt, die signalisiert, dass die Content-Daten dort im Cache-Speicher eines diesem Client zugeordneten Proxys (MP) gefunden werden können. Wenn nein, werden als Antwort zum Proxy des Clients (CA) zur Speicherung im dortigen Cache-Speicher die vollständigen Content-Daten einschließlich des als Schlüssel dienenden Message-Digest übertragen. DOLLAR A Anwendung bei mobilen Datendiensten, welche den Transport von Daten über Funknetze benötigen.

Description

  • Die Erfindung betrifft ein Verfahren zum Verringern des Transportvolumens von Daten in Datennetzen, wobei von einer Datenquelle zu einem Client über einen Übertragungsweg bereits übertragene Content-Daten beim Client für eine spätere Wiederbenutzung nach Art des sogenannten Caching-Verfahrens zwischengespeichert werden. Ein derartiges Verfahren ist aus EP 1 308 853 A1 bekannt.
  • Da der Transport von Daten in Datennetzen stets mit Kostenaufwand und Wartezeit verbunden ist, werden verschiedene Techniken eingesetzt, um das Datentransportvolumen zu reduzieren. Ein häufig zu diesem Zweck angewandtes Verfahren besteht darin, bereits übertragene Daten beim Client zur eventuellen Wiederbenutzung zu speichern. Dieses Verfahren wird als "Caching" bezeichnet. Hierbei entsteht das Problem, dass die Aktualität der gespeicherten Daten sichergestellt bzw. überprüft werden muss.
  • Es handelt sich hierbei um ein Problem, das nicht nur vorkommt, wenn ein Vorabrufen ("Prefetching") von Content ausgeführt wird, sondern in jedem Fall dann auftritt, wenn Kopien von Daten gehalten werden, was darin liegt, dass stets die Möglichkeit einer Änderung der Originaldaten besteht. Immer wenn sich eine solche Änderung ereignet, ist die Kopie überholt oder ungültig, wobei "überholt" bedeutet, dass die Originaldaten sich geändert haben, und "ungültig" besagt, dass die Kopie überholt ist und sich der Gebrauch der überholten Kopie negativ auswirkt. Gewöhnlich ist es zu vermeiden, dass ein Benutzer der Daten eine überholte Version empfängt. Algorithmen und Protokollerweiterungen, die einen solchen Gebrauch von überholten Daten verhindern, werden gewöhnlich "Cache-Invalidierungsmethoden" genannt und sind ein Gebiet intensiver Untersuchung mit der Bezeichnung Cache Konsistenz.
  • Bei der hier betrachteten Cache-Konfiguration und -Anwendung lassen sich vier bekannte und grundsätzlich unterschiedliche Methoden unterscheiden, nämlich die zeitliche Invalidierung, die ortsabhängige Invalidierung, die aktive Validierung/Invalidierung durch den Client und die Invalidierung durch Rückfrage.
  • Bei der zeitlichen Cache-Invalidierung wird ein Ablaufdatum verwendet, das der Kopie der Daten zugewiesen ist. Nach diesem Ablaufdatum wird die Kopie als überholt angesehen. Diese Methode wird bei dem im World Wide Web eingesetzten HTTP-Protokoll praktiziert, indem das Ablaufdatum mit dem optionalen "Expires"-Header-Feld (z.B. Expires: Wed. 31 Dec 2003 18:00:00 GMT) übertragen wird. Es wird dann die URL und das Ablaufdatum verglichen. Es sollte angemerkt werden, dass diese Methode keine allgemeine Lösung des Cache-Konsistenzproblems ist, sondern eine Übereinkunft zwischen dem Benutzer und dem Provider von Daten bildet, wobei der Provider sicherstellt, dass das Original bis zum Ablaufdatum nicht verändert wird oder dass bei seiner Veränderung vor dem Ablaufdatum keine negativen Auswirkungen durch Verwendung der überholten Kopie entstehen, d.h. die Daten sind zwar überholt, aber nicht ungültig.
  • Die ortsabhängige Cache-Invalidierung ist aus dem Aufsatz von B. Zheng, J. Xu, D.L. Lee: "Cache Invalidation and Replacement Strategies for Location-Dependent Data in Mobile Environments" in "IEEE Transactions on Computers", Vol. 51, No. 10, Oktober 2002, Seiten 1141 bis 1153 vorgeschlagen worden. Diese Methode betrachtet den Fall eines mobilen Benutzers mit bekannter geographischer Position, für den die Daten nur dann als gültig angesehen werden, wenn er sich innerhalb eines bestimmten geographischen Gebiets befindet. Als ein Beispiel wird die Abfrage nach dem "nächstgelegenen Restaurant" ange geben. Das Ergebnis dieser Abfrage hängt ganz eindeutig vom Ort des Benutzers ab. Bewegt sich der Benutzer einmal in ein Gebiet hinein, in dem ein anderes Restaurant näher ist, dann ist das Ergebnis nicht mehr gültig. Zur Erzielung einer empfindlichen Validierung wird bei dieser bekannten Methode vorgeschlagen, ein Gebiet, das als Geltungsbereichsgebiet bezeichnet wird, mit der Kopie der Daten zu speichern. Abfragen, welche die Suche nach einem Objekt mit dem Prädikat "nächstgelegenes" spezifizieren, werden Segmente eines sogenannten Voronoi-Diagramms. Die Daten werden dann als überholt und ungültig angesehen, wenn der Benutzer das Geltungsbereichsgebiet verlässt.
  • Wenn die aktive Validierung durch den Client angewandt wird, trägt der Client die Verantwortung, die Kopie jedesmal zu validieren, wenn auf die Kopie zugegriffen wird. Er kontaktiert deshalb den Server, der die Originaldaten enthält, und fragt an, ob die Originaldaten seit dem Zeitpunkt, zu dem die Kopie angefertigt worden ist, geändert worden sind. Zu diesem Zweck speichert die Cache-Instanz diesen Zeitpunkt mit der Kopie. Innerhalb des HTTP-Protokolls wird diese Methode immer dort angewandt, wo ein Client ein besonderes Verfahren, gewöhnlich GET, benutzt und es durch einen "If-Modified-Since"-Header unter eine Bedingung stellt. (z.B. If-Modified-Since: Thu, 27 Mar 2003 11:20:00 GMT). Wenn sich das Dokument seit der spezifizierten Zeit geändert hat, gibt der Server die neue Version frei. Wenn es sich nicht geändert hat, gibt der Server einen Error-Code (304) frei, der dem Client besagt, dass die Kopie noch gültig ist.
  • Die Methode der Invalidierung durch Rückfrage verlangt, dass der Server alle Kopien verfolgt, die angefertigt worden sind. Immer wenn die Originaldaten verändert worden sind, meldet der Server, d.h. die Datenquelle, auf Anfrage aktiv allen In stanzen, die Kopien halten, dass eine neuere Version vorhanden ist. Diese Methode wird innerhalb des HTTP-Protokolls nicht realisiert.
  • Ein weiterer wichtiger Punkt, der einen starken praktischen Einfluss auf das Caching und Vorabrufen ("Prefetching") hat, betrifft den dynamisch erzeugten Content. Eine große und anwachsende Anzahl von Websites macht Gebrauch von der modernen Webserver-Fähigkeit, Nutzer-Sitzungen durch die dynamische Erzeugung der Links, z.B. innerhalb HTML-Dateien, zu verfolgen. Wenn eine Anfrage entsprechend einem dynamisch erzeugten Link beim Server ankommt, ist die Server-Anwendung dazu fähig, die Informationen zu den notwendigen Dateien von der Zusatzinformation zu trennen, die zum Verfolgen der Sitzungen verwendet wird. Im Ergebnis kommt es oft vor, dass ein identischer Content unter vielfach verschiedenen URLs verabreicht wird. Häufig werden die ungünstigen Auswirkungen dieser Erscheinung als Argumente gegen die Anwendung von Caching und Vorabrufen ("Prefetching") angeführt, da der Prozentsatz von cachingfähigen Dokumenten erheblich verringert sein kann. 1 zeigt diesen Fall anhand eines Beispiels mit zwei unterschiedlichen URLs und dabei identischem, dynamisch erzeugten Content.
  • Eine ähnliche Erscheinung tritt auch bei statischem Content in Fällen auf, bei denen die gleichen Daten, z.B. für ein bestimmtes, für ein Symbol benutztes Bild, durch mehrere Websites unter potentiell unterschiedlichen Dateinamen verwendet werden. Dieser Effekt behindert das Caching und Vorabrufen ("Prefetching") nicht, da alle Instanzen der Daten cachingfähig sind und wiederbenutzt werden können. Nichtsdestoweniger könnten zusätzliche Übertragungs- und Speicherbetriebsmittel eingespart werden, wenn die Qualität/Identität der Daten detektiert werden könnte. 2 zeigt diesen Fall anhand eines Beispiels mit zwei unterschiedlichen URLs und dabei identischem, statisch erzeugten Content.
  • Die existierenden Verfahren zur Cache-Validierung weisen also vor allem große Schwächen bei dynamisch erzeugtem Content, insbesondere durch Webanwendungen oder Skripte, wie z.B. PHP, ASP, Servlets, JSP oder Perl, auf. Zum einen werden Daten, deren URL sich geändert hat bzw. deren URL dynamisch erzeugt worden ist, unnötigerweise erneut übertragen, obwohl sie inhaltsgleich sind, und zum anderen werden Daten, deren URL gleich geblieben ist, nicht erneut übertragen, obschon es nötig gewesen wäre.
  • Die Punkte der Caching-Konsistenz und dynamischen Content-Erzeugung sind an dieser Stelle besonders herausgearbeitet worden, um das durch die Erfindung vorgestellte Verfahren zum Erlangen einer besseren Verständlichkeit aufzubereiten.
    •
  • Der Erfindung liegt die Aufgabe zu Grunde, bei Verfahren, bei welchen von einer Datenquelle zu einem Client bereits übertragene Daten beim Client für eine spätere Wiederbenutzung nach Art des sogenannten Caching-Verfahrens puffergespeichert werden, die Aktualität bzw. die Synchronität der im Caching-Speicher gespeicherten Daten mit denen der Datenquelle sicherzustellen, wobei keine Kooperation der Betreiber der Datenquellen notwendig ist.
  • Gemäß der Erfindung, die sich auf ein Verfahren der eingangs genannten Art bezieht, wird diese Aufgabe in vorteilhafter Weise dadurch gelöst, dass in einem Proxy-Server aus den auf eine Anfrage des Clients von einer Datenquelle ausgegebenen Antwortdaten ähnlich einer Prüfsummenbildung ein Message-Digest gebildet wird, dass dieser Message-Digest in diesem Proxy-Server durch Vergleichen dahingehend überprüft wird, ob bereits vorher ein übereinstimmender Message-Digest in diesem Proxy-Server für den betreffenden Client gespeichert worden ist, dass dann, wenn bereits ein übereinstimmender Message-Digest für den betreffenden Client in diesem Proxy-Server eingespeichert ist, dem Client von diesem Proxy-Server zusammen mit dem Message-Digest eine kurze Antwortmeldung übermittelt wird, welche die Tatsache signalisiert, dass die Content-Daten dort im Cache-Speicher des Clients oder eines dem Client zugeordneten Proxys gefunden werden können, der den Message-Digest als einen Schlüssel zum Aufspüren der Content-Daten aus seinem Cache-Speicher benutzt und diese an den Client liefert, bei welchem die Content-Daten dann präsentiert werden, und dass nur dann, wenn in dem der Datenquelle zugeordneten Proxy-Server bei der vergleichenden Überprüfung des Message-Digests festgestellt wird, dass dort kein übereinstimmender, vorher eingespeicherter Message-Digest vorhanden ist, als Antwort zum Client die vollständigen Content-Daten einschließlich dem Message-Digest übertragen werden, wobei die Content-Daten zusammen mit dem einer späteren Identifizierung als Schlüssel dienenden Message-Digest im Cache-Speicher des dem Client zugeordneten Proxys gespeichert werden.
  • Durch den Einsatz eines Proxy-Systems, das sich als Split-Proxy mit Cache- und Hashing-Funktionalität bezeichnen lässt, und der Überprüfung und des Vergleichs der Daten anhand von Message-Digests, die ähnlich gebildet werden können wie die Prüfsummenbildung z.B. gemäß RFC 1321 (MD5), werden die unter der Aufgabenstellung angesprochenen Probleme vollständig gelöst. Hierbei ist keine Kooperation mit den Betreibern der Datenquellen erforderlich.
  • Das Verfahren nach der Erfindung ermöglicht es dem Endnutzer und/oder dem Betreiber der Zugangsnetze, diese effizienter auszunutzen und damit Zeit und Kosten zu sparen, was insbesondere bei Mobilfunknetzen eine sehr hohe Bedeutung hat.
  • Das Verfahren nach der Erfindung umfasst eine besondere Arbeitsarchitektur, Algorithmen und Protokolle, deren Kombination die gestellte Aufgabe vor allem auch bei typischen mobilen Szenarien löst. Die Wirkungen des Verfahrens sind vor allem unter der Voraussetzung wirksam, dass für ein drahtloses Zugangslink die Kommunikationskapazität bedeutend geringer und die Wartezeit erheblich höher als innerhalb eines sich anschließenden Kernnetzwerks ist.
  • Unter dieser Voraussetzung ist es möglich und vorteilhaft, die Validierung des ganzen Contents zu versuchen, sogar wenn dieser sich nicht explizit für das Caching empfiehlt. Innerhalb des Verfahrens nach der Erfindung wird davon abgegangen, zum Identifizieren und Indexieren der Daten URLs oder URIs zu verwenden. Anstelle davon werden in vorteilhafter Weise an sich bekannte Message-Digestion-Algorithmen wie z.B. MD5 und SHA-1 benutzt, die einen schnellen Vergleich von Daten auf Gleichheit hin erleichtern. Dadurch wird man in die Lage versetzt, die Validität des Contents ohne jeglichen Blick auf die – potentiell dynamisch – zugewiesene Kennzeichnung der Daten zu prüfen.
  • Vorteilhafte Weiterbildungen des Verfahrens nach der Erfindung sind in den unmittelbar oder mittelbar auf den Patentanspruch 1 rückbezogenen Unteransprüchen angegeben.
  • Der Client kann mit seinem Proxy vom Aufbau her sehr vorteilhaft in einem mobilen drahtlosen Informationsendgerät betrieben werden, das für Datendienste wie z.B. WAP oder Web sowie alle weiteren Dienste für mobile Endgeräten wie z.B. Mobiltelefone, PDAs oder Laptops zugänglich ist. Dabei wird die Kom munikation zwischen dem im mobilen drahtlosen Informationsendgerät untergebrachten Proxy des Clients und dem Proxy-Server entweder über ein öffentliches Mobilfunknetz oder über einen residenten Proxy, der über ein Kurzstreckenfunksystem, wie z.B. Bluetooth oder W-LAN, mit dem Proxy des Clients kommuniziert, und ein öffentliches Festnetz, an welches sowohl der residente Proxy als auch der der Datenquelle zugeordnete Proxy-Server angebunden sind, vorgenommen.
  • Das Verfahren nach der Erfindung wird nachfolgend anhand von Zeichnungen erläutert. Es zeigen:
  • 1 anhand eines Blockschaltbildes den bekannten und bereits vorher geschilderten Fall eines Beispiels mit zwei unterschiedlichen URLs und dabei identischem, dynamisch erzeugten Content,
  • 2 anhand eines Blockschaltbildes den ebenfalls bekannten und vorher auch schon abgehandelten Fall eines Beispiels mit zwei unterschiedlichen URLs und dabei identischem, statisch erzeugten Content,
  • 3 in einem schematischen Blockschaltbild ein Beispiel einer vollen Architektur eines Systems zur Durchführung des Verfahrens nach der Erfindung,
  • 4 den Verlauf eines Hash-Protokolls zur Benutzung beim Verfahren nach der Erfindung, falls vorher noch kein identischer Content von einer Server-Anwendung zu einer Client-Anwendung übertragen worden ist,
  • 5 den Verlauf eines Hash-Protokolls zum Einsatz beim Verfahren nach der Erfindung, falls vorher bereits ein identischer Content von der Server-Anwendung zur Client-Anwendung mit Cache übertragen worden ist, und
  • 6 in einer graphischen Funktionsdarstellung die Abhängigkeit der Zeitdauer der Hash-Berechnung, also der Message-Digest-Berechnungszeit, von der Datenlänge für die in Tabelle 1 angegebenen Realisierungsfälle bei Anwendung zweier verschiedener Message-Digestion-Algorithmen, nämlich MD5 und SHA-1.
    •
  • In dem in 3 dargestellten Architekturbeispiel sind drei mobile drahtlose Informationsendgeräte WIDa, WIDb und WIDc vorgesehen, die jeweils im betreffenden Geräteaufbau eine Client-Anwendung CA und einen mobilen Proxy MP enthalten. Die Client-Informationsendgeräte WIDa, WIDb und WIDc können beispielsweise Mobiltelefone, PDAs oder Laptops sein und sind allesamt über Funk angebunden. Dabei kommuniziert der mobile Proxy MP des ersten Client-Informationsendgerätes WIDa über eine Bluetooth-Kurzstreckenfunkstrecke BT mit einem residenten Proxy RP einer lokalen Dienststelle LSPi.
  • Der mobile Proxy MP des zweiten Client-Informationsendgerätes WIDb kommuniziert über ein Bluetooth-Kurzstreckenfunksystem BT mit dem residenten Proxy RP der lokalen Dienststelle LSPi und über eine W-LAN-Funkstrecke gemäß IEEE 802.11 mit dem residenten Proxy RP einer zweiten lokalen Dienststelle LSPj.
  • Das dritte Client-Informationsendgerät WIDc erreicht mit seinem mobilen Proxy MP keine lokale Dienststelle, sondern kommuniziert über ein öffentliches landgestütztes Mobilfunknetz, das im Architekturbeispiel GPRS-Funktionalität aufweist, direkt mit einem zentralen Proxy-Server CP, der drei verschie denen Server-Anwendungen SA mit abfragbaren Datenquellen auf drei Host-Servern SA Hostp, SA Hostq und SA Hostr zugeordnet und mit diesen über Leitungen verbunden ist. An diesen zentralen Proxy-Server CP sind auch die beiden lokalen Zugangsknoten LSPi und LSPj mit ihren residenten Proxys RP über Leitungen angebunden. Zu Statistikzwecken ist an den zentralen Proxy CP noch ein Situationsstatistik-Server SSS angebunden.
  • 4 und 5 stellen die Kommunikation zwischen den fünf Entitäten CA (= Client-Anwendung), MP (= mobiler Proxy), RP (= residenter Proxy), CP (= zentraler Proxy-Server) und SA (= Server-Anwendung) gemäß einem vorgeschlagenen Hash-Protokoll dar, das zum Ausräumen der vorher beschriebenen nachteiligen Effekte bei der dynamischen Content-Erzeugung zweckmäßig eingesetzt wird. Es ist wichtig, die erheblichen Unterschiede in der Datenübertragungsrate, der Wartezeit und im Kostenaufwand der verschiedenen Kommunikationsverbindungen im Gedächtnis zu behalten.
  • Die Client-Anwendung CA und der mobile Proxy MP liegen strukturell auf der gleichen Vorrichtung, so dass davon ausgegangen werden kann, dass hier hohe Datenübertragungsraten erreicht werden, wogegen zwischen dem mobilen Proxy MP und dem residenten Proxy RP die Verbindung auf Grund der Eigenschaft des drahtlosen Mediums stets langsamer als alle anderen Verbindungen ist. Diese verschiedenen Datenübertragungsraten und Wartezeiten sind in 4 und 5 angegeben. Zur verständlicheren Bezugnahme sind dort Ereignisse oder Schritte von Interesse mit entsprechenden, mit einem Kreis umrahmten Zahlen markiert, z.B. mit ➀ im Text und in den Figuren.
  • Es wird mit ➀ begonnen. Hier gibt die Client-Anwendung CA eine Datenübermittlungsanfrage Req1 zum mobilen Proxy MP aus, der auf der gleichen Vorrichtung angeordnet ist. Der mobile Proxy MP enthält eine einzige Identität IDWID, welche das drahtlose Informationsendgerät WID im Header kennzeichnet, und leitet bei ➁ die Anfrage Req1 über eine drahtlose Kurzbereichskommunikation zum residenten Proxy RP an einen erreichbaren lokalen Zugangsknoten LSP weiter. Vom residenten Proxy RP wird die Anfrage Req1 bei ➂ unverändert zum zentralen Proxy CP weitergeleitet, der seinerseits bei ➃ die Anfrage Req1 zur eigentlichen Server-Anwendung SA bei ➄ weiterleitet. Wenn keine lokale Dienststelle LSP zugänglich sein sollte, wird der residente Proxy RP ausgelassen und die Anfrage Req1 wird über ein öffentliches Mobilfunknetz und die geeigneten Zugänge direkt zum zentralen Proxy CP bei ➃ weitergeleitet.
  • Die Server-Anwendung SA empfängt bei ➃ und zerlegt bei ➄ die Anfrage Req1, erzeugt die Antwort Resp1 mit den angefragten Daten und startet damit, diese Daten, die im Beispiel die Daten eines Bildes sind, zum zentralen Proxy CP zu senden. In typischer Weise besteht keine Notwendigkeit, die Identität IDWID in die Antwort Resp1 mit einzuschließen, da alle Kommunikationen dazwischen verbindungsorientiert sind. Die Antwort Resp1 ist daher mit der entsprechenden Anfrage automatisch verbunden.
  • Dies trifft für die allgemeine Praxis zu, um HTTP-Verkehr über TCP zu transportieren. Nichtsdestoweniger ist dies kein "Muss", da HTTP auch über verbindungslose (z.B. UDP) oder nachrichtenorientierte (z.B. E-Mail) Kanäle zwischen Proxys transportiert werden kann. In diesem Fall erfordert es das Verfahren nach der Erfindung, in die Antworten auch Informationen miteinzuschließen, welche das jeweilige drahtlose Informationsendgerät WID identifizieren.
  • Der zentrale Proxy CP bei ➅ wartet, bis die vollständige Antwort Resp1 angekommen ist. Dann berechnet der zentrale Proxy CP den in der Antwort Resp1 eingeschlossenen Message-Digest der Daten. Für jedes drahtlose Informationsendgerät WID, das durch den zentralen Proxy CP bedient wird, hält dieser eine Liste, welche die Message-Digests aller Antwortdaten enthält, die zu der besonderen Vorrichtung WID gesendet worden sind. Wenn die Daten vorher nicht zum drahtlosen Informationsendgerät WID gesendet worden sind, wird ihr Message-Digest MD nicht in dieser Liste gefunden.
  • In diesem Fall, der in 4 dargestellt ist, schließt der zentrale Proxy CP bei ➅ den Message-Digest MD in die Liste und in den Antwort-Header mit ein und schickt die vollständige Antwort Resp1 zum residenten Proxy RP. Der residente Proxy RP führt keinerlei Operation an den Daten oder an den Headers aus. Es startet unmittelbar der Vorgang ➆, um den Datenfluss vom residenten Proxy RP zum mobilen Proxy MP weiterzuleiten. Die Kommunikation zwischen dem residenten Proxy RP und dem mobilen Proxy MP ist relativ langsam, wie bereits vorher erwähnt worden ist. Deswegen müssen die vom zentralen Proxy CP ankommenden Daten in eine Warteschlange eingereiht werden.
  • Nach Ankunft der Anfangsbytes der Antwort Resp1 am mobilen Proxy MP bei ➇, wird damit begonnen, diese zur Client-Anwendung CA weiterzuleiten. Diese Verbindung ist gewöhnlich die schnellste in der Übertragungskette und zwar deswegen, weil durch eine Interprozesskommunikation innerhalb einer Vorrichtung transportiert wird. Daher müssen in der Regel auch keine oder nur kurze Warteschlangen aufgebaut werden. Der eingeschlossene Message-Digest MD wird in einer Tabelle zusammen mit den Antwortdaten zur potentiellen späteren Wiederverwendung gespeichert. Dieses bildet die aktuelle Caching- Operation. Danach wird die vollständige Antwort Resp1 bei ➈ an die Client-Anwendung CA weitergeleitet. Die Client-Anwendung CA kann die Ergebnisse dem Benutzer präsentieren bzw. die Dokumentbeschreibung für Bezugnahmen analysieren, die auf eingebettete Objekte hinweisen.
  • Im Zusammenhang mit 5 wird nachfolgend aufgezeigt, wie trotz eines höheren Aufwandes durch Anwendung des Verfahrens nach der Erfindung die Kommunikationsbelastung reduziert wird.
  • Zu einem späteren Zeitpunkt soll von der Client-Anwendung CA eine weitere Datenübermittlungsanfrage Reqk ausgegeben werden. Die Schritte ➀ bis ➃, welche die Abwicklung einer Anfrage Reqk betreffen, sind identisch zum vorher erläuterten Fall der 1. Im Unterschied dazu spielt sich jedoch diesmal das Geschehen so ab, dass die bei ➄ in der Antwort Respk enthaltenen Daten eine genaue Kopie, d.h. im dargestellten Beispiel das gleiche Bild, der bereits vorher einmal zum drahtlosen Informationsendgerät WID transportierten Daten sind.
  • Dieser Umstand wird detektiert, da im zentralen Proxy-Server CP der Message-Digest MD dieser Antwort Respk berechnet wird und dieses Mal in der Liste gefunden wird, die für das besondere drahtlose Informationsendgerät WID im zentralen Proxy CP gehalten wird. Der zentrale Proxy CP erzeugt dann bei ➅ eine Antwort mit einem Header, der die Tatsache signalisiert, dass die Daten auf dem besonderen Informationsendgerät WID gefunden werden können (HIT), und mit dem Message-Digest MD(Resp1).
  • Diese Kurzantwort HIT,MD (Resp1) wird bei ➅ vom zentralen Proxy-Server CP an den residenten Proxy RP gesendet, bei ➆ vom residenten Proxy RP zum mobilen Proxy MP hin weitergeleitet und bei ➇ am mobilen Proxy MP empfangen. Der mobile Proxy MP benutzt den Message-Digest MD(Resp1) als einen Schlüssel zum Aufspüren der Daten aus seinem Cache und liefert diese als volle Resp1 an die Client-Anwendung CA, wo der Content dann bei ➈ im Beispiel in Form des Bildes präsentiert wird.
  • Es sollte an dieser Stelle betont werden, dass kein Zusammenwirken von Server-Anwendungen SA benötigt wird, damit sich das Verfahren nach der Erfindung entfalten kann.
  • Es ist zwar die Tatsache in Kauf zu nehmen, dass die Berechnung des Message-Digests Betriebsmittel und Zeit in Anspruch nimmt und somit eine zusätzliche Wartezeit einführt. Um diese unerwünschte zusätzliche Wartezeit einzuschätzen, sind Versuche für zwei verschiedene Message-Digest-Algorithmen, nämlich MD5 und SHA-1, auf drei verschiedenen Plattformen durchgeführt worden, die in der nachfolgenden Tabelle 1 aufgeführt sind.
    Figure 00140001
    Tabelle 1
  • Es besteht besonderes Interesse an der Art der Zunahme (linear, polynomial, exponentiell, ...) von Berechnungszeit in Abhängigkeit von der Messagedaten-Länge. Die Ergebnisse der Versuche sind in 6 abgebildet und zeigen mäßige Message-Digest-Berechnungszeiten [ms] mit lediglich linearer Zunahme bei zunehmenden Messagedaten-Längen [byte]. Es lässt sich ersehen, dass MD5 bei allen Plattformen marginal schneller als SHA-1 arbeitet. Dies ergibt sich zum Teil aus der geringeren Message-Digest-Länge für MD5. Die Ergebnisse erlauben den Schluss, dass die durch die Rechenzeit eingeführten Verzögerungen für jede beliebige gegebene Message-Digest-Länge erheblich kleiner als die Verzögerungen sind, die durch die begrenzte Datenübertragungsrate verursacht werden.
  • Es wird daher als ratsam angesehen, das erfindungsgemäß arbeitende Verfahren zur Cache-Validierung insbesondere für eine dynamische Content-Erzeugung und einen Dienst anzuwenden, der für mobile Vorrichtungen bereitgestellt wird. Ohne allerdings irgend eine Bevorzugung auszusprechen, ist MD5 als Standard-Message-Digest-Algorithmus innerhalb eines vorgeschlagenen Protokolls auf Grund seiner ausreichenden Länge, seiner geringfügig schnelleren Rechenzeit und seiner für eine große Anzahl von Plattformen vorhandenen Verfügbarkeit gewählt worden.
    • BT
    Bluetooth-Funkstrecke
    CA
    Client-Anwendung
    CP
    Zentraler Proxy-Server
    GPRS
    Mobilfunknetz mit GPRS
    LSPi,LSPj
    Lokale Dienststelle
    MD
    Message-Digest
    MP
    Mobiler Proxy
    RP
    Residenter Proxy
    Req1, Reqk
    Anfrage
    Resp1,Respk
    Antwort
    SA
    Server-Anwendung
    SA Hostp, SA Hostq, SA Hostr
    Host-Server
    SSS
    Situationsstatistik-Server
    W-LAN
    W-LAN-Funkstrecke (IEEE 802.11)
    WIDa, WIDb, WIDc
    Drahtloses Informationsendgerät

Claims (7)

  1. Verfahren zum Verringern des Transportvolumens von Daten in Datennetzen, wobei von einer Datenquelle (SA) zu einem Client (CA) über einen Übertragungsweg bereits übertragene Content-Daten beim Client (CA) für eine spätere Wiederbenutzung nach Art des sogenannten Caching-Verfahrens zwischengespeichert werden, dadurch gekennzeichnet, dass in einem Proxy-Server (CP) aus den auf eine Anfrage (Req) des Clients (CA) von einer Datenquelle (SA) ausgegebenen Antwortdaten (Resp) ähnlich einer Prüfsummenbildung durch Rechnung ein Message-Digest (MD) gebildet wird, dass dieser Message-Digest (MD) in diesem Proxy-Server (CP) durch Vergleichen dahingehend überprüft wird, ob bereits vorher ein übereinstimmender Message-Digest (MD) in diesem Proxy-Server (CP) für den betreffenden Client (CA) gespeichert worden ist, dass dann, wenn bereits ein übereinstimmender Message-Digest (MD) für den betreffenden Client (CA) in diesem Proxy-Server (CP) eingespeichert ist, dem Client (CA) von diesem Proxy-Server (CP) zusammen mit, dem Message-Digest (MD) eine kurze Antwortmeldung (HIT) übermittelt wird, welche die Tatsache signalisiert, dass die Content-Daten dort im Cache-Speicher eines diesem Client (CA) zugeordneten Proxys (MP) gefunden werden können, der den Message-Digest (MD) als einen Schlüssel zum Aufspüren der Content-Daten aus seinem Cache-Speicher benutzt und diese an den Client (CA) liefert, bei welchem die Content-Daten dann präsentiert werden, und dass nur dann, wenn in dem der Datenquelle (SA) zugeordneten Proxy-Server (CP) bei der vergleichenden Überprüfung des Message-Digests (MD) festgestellt wird, dass dort kein übereinstimmender, vorher eingespeicherter Message-Digest (MD) vorhanden ist, als Antwort zum Client (CA) die vollständigen Content-Daten einschließlich dem Message-Digest (MD) übertragen werden, wobei die Content-Daten zusammen mit dem einer späteren Identifi zierung als Schlüssel dienenden Message-Digest (MD) im Cache-Speicher des dem Empfänger (CA) zugeordneten Proxys (MP) gespeichert werden.
  2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass als Message-Digestion-Algorithmus in dem der Datenquelle (SA) zugeordneten Proxy-Server (CP) bei der vergleichenden Überprüfung des Message-Digests (MD) mit Hashing-Funktionalität der MD5- oder SHA-1-Algorithmus eingesetzt wird, die einen schnellen Vergleich von Daten auf Gleichheit hin erleichtern.
  3. Verfahren nach Anspruch 1 oder 2, dadurch gekennzeichnet, dass der Client (CA) mit seinem Proxy (MP) in einem mobilen drahtlosen Informationsendgerät (WID) betrieben wird, das für Datendienste, wie z.B. WAP oder Web, verwendbar ist.
  4. Verfahren nach Anspruch 3, dadurch gekennzeichnet, dass die Kommunikation zwischen dem im mobilen drahtlosen Informationsendgerät (WID) untergebrachten Proxy (MP) des Clients (CA) und dem der Datenquelle (SA) zugeordneten Proxy-Server (CP) entweder über ein öffentliches Mobilfunknetz oder über einen residenten Proxy (RP), der über eine Kurzstreckenfunkstrecke, wie z.B. Bluetooth oder W-LAN, mit dem Proxy des Clients (CA) kommuniziert, und ein öffentliches Festnetz, an welches sowohl der residente Proxy (RP) als auch der Proxy-Server (CP) angebunden sind, vorgenommen wird.
  5. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass der mobile Proxy (MP) in die Client-Anwendung (CA) integriert wird.
  6. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass der zentrale Proxy-Server (CP) in die Server-Anwendung (SA) integriert wird.
  7. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass im zentralen Proxy-Server (CP) statistische Daten erfasst werden.
DE10356724A 2003-12-02 2003-12-02 Verfahren zum Verringern des Transportvolumens von Daten in Datennetzen Expired - Fee Related DE10356724B3 (de)

Priority Applications (4)

Application Number Priority Date Filing Date Title
DE10356724A DE10356724B3 (de) 2003-12-02 2003-12-02 Verfahren zum Verringern des Transportvolumens von Daten in Datennetzen
EP04027953A EP1538804B1 (de) 2003-12-02 2004-11-25 Verfahren zum Verringern des Transportvolumens von Daten in Datennetzen
AT04027953T ATE510394T1 (de) 2003-12-02 2004-11-25 Verfahren zum verringern des transportvolumens von daten in datennetzen
US11/002,602 US20050117558A1 (en) 2003-12-02 2004-12-02 Method for reducing data transport volume in data networks

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
DE10356724A DE10356724B3 (de) 2003-12-02 2003-12-02 Verfahren zum Verringern des Transportvolumens von Daten in Datennetzen

Publications (1)

Publication Number Publication Date
DE10356724B3 true DE10356724B3 (de) 2005-06-16

Family

ID=34442444

Family Applications (1)

Application Number Title Priority Date Filing Date
DE10356724A Expired - Fee Related DE10356724B3 (de) 2003-12-02 2003-12-02 Verfahren zum Verringern des Transportvolumens von Daten in Datennetzen

Country Status (4)

Country Link
US (1) US20050117558A1 (de)
EP (1) EP1538804B1 (de)
AT (1) ATE510394T1 (de)
DE (1) DE10356724B3 (de)

Families Citing this family (42)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7574500B2 (en) * 2005-02-14 2009-08-11 Reactivity, Inc. Establishing a cache expiration time to be associated with newly generated output by determining module- specific cache expiration times for a plurality of processing modules
US8583827B2 (en) * 2005-05-26 2013-11-12 Citrix Systems, Inc. Dynamic data optimization in data network
CA2513014A1 (en) * 2005-07-22 2007-01-22 Research In Motion Limited A method of controlling delivery of multi-part content from an origin server to a mobile device browser via a proxy server
CA2513018A1 (en) * 2005-07-22 2007-01-22 Research In Motion Limited Method for training a proxy server for content delivery based on communication of state information from a mobile device browser
CA2513016A1 (en) 2005-07-22 2007-01-22 Research In Motion Limited A secure method of synchronizing cache contents of a mobile browser with a proxy server
CA2513019A1 (en) * 2005-07-22 2007-01-22 Research In Motion Limited A method for communicating state information between a server and a mobile device browser with version handling
CA2513022A1 (en) 2005-07-22 2007-01-22 Research In Motion Limited System and method for communicating state management between a browser user-agent and a mobile data server
CA2513010A1 (en) * 2005-07-22 2007-01-22 Research In Motion Limited A method for detecting state changes between data stored in a first computing device and data retrieved from a second computing device
US8484162B2 (en) 2008-06-24 2013-07-09 Commvault Systems, Inc. De-duplication systems and methods for application-specific data
US8930306B1 (en) 2009-07-08 2015-01-06 Commvault Systems, Inc. Synchronized data deduplication
US20110202634A1 (en) * 2010-02-12 2011-08-18 Surya Kumar Kovvali Charging-invariant and origin-server-friendly transit caching in mobile networks
US8799480B2 (en) 2010-07-19 2014-08-05 Movik Networks Content pre-fetching and CDN assist methods in a wireless mobile network
US8572340B2 (en) 2010-09-30 2013-10-29 Commvault Systems, Inc. Systems and methods for retaining and using data block signatures in data protection operations
US8364652B2 (en) 2010-09-30 2013-01-29 Commvault Systems, Inc. Content aligned block-based deduplication
US9020900B2 (en) 2010-12-14 2015-04-28 Commvault Systems, Inc. Distributed deduplicated storage system
US20120150818A1 (en) 2010-12-14 2012-06-14 Commvault Systems, Inc. Client-side repository in a networked deduplicated storage system
IN2014DN09138A (de) * 2012-04-04 2015-05-22 Unwired Planet Inc
US9251186B2 (en) 2012-06-13 2016-02-02 Commvault Systems, Inc. Backup using a client-side signature repository in a networked storage system
US9633033B2 (en) 2013-01-11 2017-04-25 Commvault Systems, Inc. High availability distributed deduplicated storage system
US9009103B2 (en) 2013-03-15 2015-04-14 Microsoft Technology Licensing, Llc Fingerprint-based, intelligent, content pre-fetching
IN2013CH05044A (de) 2013-11-08 2015-05-29 Huawei Technologies India Pvt Ltd
US9633056B2 (en) 2014-03-17 2017-04-25 Commvault Systems, Inc. Maintaining a deduplication database
US10380072B2 (en) 2014-03-17 2019-08-13 Commvault Systems, Inc. Managing deletions from a deduplication database
US11249858B2 (en) 2014-08-06 2022-02-15 Commvault Systems, Inc. Point-in-time backups of a production application made accessible over fibre channel and/or ISCSI as data sources to a remote application by representing the backups as pseudo-disks operating apart from the production application and its host
US9852026B2 (en) 2014-08-06 2017-12-26 Commvault Systems, Inc. Efficient application recovery in an information management system based on a pseudo-storage-device driver
US9575673B2 (en) 2014-10-29 2017-02-21 Commvault Systems, Inc. Accessing a file system using tiered deduplication
US10339106B2 (en) 2015-04-09 2019-07-02 Commvault Systems, Inc. Highly reusable deduplication database after disaster recovery
US20160350391A1 (en) 2015-05-26 2016-12-01 Commvault Systems, Inc. Replication using deduplicated secondary copy data
US9766825B2 (en) 2015-07-22 2017-09-19 Commvault Systems, Inc. Browse and restore for block-level backups
US10310953B2 (en) 2015-12-30 2019-06-04 Commvault Systems, Inc. System for redirecting requests after a secondary storage computing device failure
US10296368B2 (en) 2016-03-09 2019-05-21 Commvault Systems, Inc. Hypervisor-independent block-level live browse for access to backed up virtual machine (VM) data and hypervisor-free file-level recovery (block-level pseudo-mount)
US10846024B2 (en) 2016-05-16 2020-11-24 Commvault Systems, Inc. Global de-duplication of virtual disks in a storage platform
US10795577B2 (en) 2016-05-16 2020-10-06 Commvault Systems, Inc. De-duplication of client-side data cache for virtual disks
US10740193B2 (en) 2017-02-27 2020-08-11 Commvault Systems, Inc. Hypervisor-independent reference copies of virtual machine payload data based on block-level pseudo-mount
US10664352B2 (en) 2017-06-14 2020-05-26 Commvault Systems, Inc. Live browsing of backed up data residing on cloned disks
CN109558421A (zh) * 2018-10-29 2019-04-02 中国建设银行股份有限公司 基于缓存的数据处理方法、系统、装置及存储介质
US11010258B2 (en) 2018-11-27 2021-05-18 Commvault Systems, Inc. Generating backup copies through interoperability between components of a data storage management system and appliances for data storage and deduplication
US11698727B2 (en) 2018-12-14 2023-07-11 Commvault Systems, Inc. Performing secondary copy operations based on deduplication performance
US20200327017A1 (en) 2019-04-10 2020-10-15 Commvault Systems, Inc. Restore using deduplicated secondary copy data
US11463264B2 (en) 2019-05-08 2022-10-04 Commvault Systems, Inc. Use of data block signatures for monitoring in an information management system
US20210173811A1 (en) 2019-12-04 2021-06-10 Commvault Systems, Inc. Optimizing the restoration of deduplicated data stored in multi-node replicated file systems
US11687424B2 (en) 2020-05-28 2023-06-27 Commvault Systems, Inc. Automated media agent state management

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1308853A1 (de) * 2001-10-30 2003-05-07 Hewlett-Packard Company Zwichenspeichern von Daten

Family Cites Families (20)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5864852A (en) * 1996-04-26 1999-01-26 Netscape Communications Corporation Proxy server caching mechanism that provides a file directory structure and a mapping mechanism within the file directory structure
US6397259B1 (en) * 1998-05-29 2002-05-28 Palm, Inc. Method, system and apparatus for packet minimized communications
US6658463B1 (en) * 1999-06-10 2003-12-02 Hughes Electronics Corporation Satellite multicast performance enhancing multicast HTTP proxy system and method
US6779042B1 (en) * 1999-09-10 2004-08-17 Ianywhere Solutions, Inc. System, method, and computer program product for enabling on-device servers, offline forms, and dynamic ad tracking on mobile devices
US20020073167A1 (en) * 1999-12-08 2002-06-13 Powell Kyle E. Internet content delivery acceleration system employing a hybrid content selection scheme
US7412462B2 (en) * 2000-02-18 2008-08-12 Burnside Acquisition, Llc Data repository and method for promoting network storage of data
US6981157B2 (en) * 2000-08-30 2005-12-27 Lucent Technologies Inc. Method and apparatus for ensuring security of users of short range wireless enable devices
US6934740B1 (en) * 2000-09-19 2005-08-23 3Com Corporation Method and apparatus for sharing common data objects among multiple applications in a client device
US6407680B1 (en) * 2000-12-22 2002-06-18 Generic Media, Inc. Distributed on-demand media transcoding system and method
US7165107B2 (en) * 2001-01-22 2007-01-16 Sun Microsystems, Inc. System and method for dynamic, transparent migration of services
AU2002234258A1 (en) * 2001-01-22 2002-07-30 Sun Microsystems, Inc. Peer-to-peer network computing platform
US6993660B1 (en) * 2001-08-03 2006-01-31 Mcafee, Inc. System and method for performing efficient computer virus scanning of transient messages using checksums in a distributed computing environment
US7287053B2 (en) * 2002-01-15 2007-10-23 International Business Machines Corporation Ad hoc data sharing in virtual team rooms
JP4366040B2 (ja) * 2002-03-07 2009-11-18 インターナショナル・ビジネス・マシーンズ・コーポレーション ネットワークサービスシステム、サーバ及びプログラム
US20040044731A1 (en) * 2002-03-22 2004-03-04 Kailai Chen System and method for optimizing internet applications
CN1221898C (zh) * 2002-08-13 2005-10-05 国际商业机器公司 刷新网络代理高速缓存服务器对象的系统和方法
US7284030B2 (en) * 2002-09-16 2007-10-16 Network Appliance, Inc. Apparatus and method for processing data in a network
US7171469B2 (en) * 2002-09-16 2007-01-30 Network Appliance, Inc. Apparatus and method for storing data in a proxy cache in a network
JP4098610B2 (ja) * 2002-12-10 2008-06-11 株式会社日立製作所 アクセス中継装置
GB0303192D0 (en) * 2003-02-12 2003-03-19 Saviso Group Ltd Methods and apparatus for traffic management in peer-to-peer networks

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1308853A1 (de) * 2001-10-30 2003-05-07 Hewlett-Packard Company Zwichenspeichern von Daten

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
BAIHUA, Zheng et al.: Cache Invalidation and Re- placement Strategies for Location-Dependent Data in Mobile Environments, IEEE TRANSACTIONS ON COM- PUTERS, Vol.51, No.10, October 2002, S.1141-1153 *
RIVEST,R.: RFC 1321-The MD5 Message-Digest Algo- rithm, April 1992, S.1-21 *

Also Published As

Publication number Publication date
US20050117558A1 (en) 2005-06-02
ATE510394T1 (de) 2011-06-15
EP1538804B1 (de) 2011-05-18
EP1538804A1 (de) 2005-06-08

Similar Documents

Publication Publication Date Title
DE10356724B3 (de) Verfahren zum Verringern des Transportvolumens von Daten in Datennetzen
EP1930818B1 (de) Verfahren zum Vorabübertragen strukturierter Datenmengen zwischen einer Clienteinrichtung und einer Servereinrichtung
DE202021103600U1 (de) Dynamische Optimierung von Anfrageparametern für Proxy-Server
DE69909839T3 (de) Optimierte Lokalisierung von Netzwerkbetriebsmittel
EP1826956B1 (de) Anpassung von virtuellen und physikalischen Netzwerkschnittstellen
DE69924103T2 (de) Verfahren und netzwerk zur verwaltung von wsp (wireless session protocol) sitzungen
DE60222871T2 (de) Anordnung und Verfahren zum Schutz von Endbenutzerdaten
DE102014113582B4 (de) Vorrichtung, Verfahren und System für die kontextbewusste Sicherheitssteuerung in einer Cloud-Umgebung
US20040044731A1 (en) System and method for optimizing internet applications
DE60204031T2 (de) Hierarchische cachespeicherung in telekommunikationsnetzen
DE202008013034U1 (de) System zum Beschleunigen von Browsing-Sitzungen
DE102012216028A1 (de) Webseiten-skriptverwaltung
EP2145445B1 (de) Verfahren zur verbesserung eines tcp datenübertragungsprozesses im fall einer unterbrechung des physikalischen übertragungsmediums
EP2826224A1 (de) Zugriff von clients auf einen serverdienst mittels einer opc-ua
DE60304100T2 (de) Erzwingung eines Zeitpunktes zur Trennung einer Kommmunikationsverbindung mit schnurlosen Endgeräten mit transienten Netzwerkadressen
DE112013000702T5 (de) Objekt-Caching für mobile Datenübertragung mit Mobilitätsverwaltung
US20150006622A1 (en) Web contents transmission method and apparatus
DE60318252T2 (de) Verfahren und vorrichtungen zur datenübertragung zwischen speichernetzwerken
DE102004023652A1 (de) Verfahren zum Ermöglichen einer Peer-to-Peer-Datenübertragung
EP1482701B1 (de) Verfahren zum paketorientierten Übertragen von Daten in Telekommunikationsnetzen mittels Umsetzung in einem Zwischenknoten von einem verbindungslosen zu einem verbindungsorientierten Übertragungsprotokoll und umgekehrt
DE102017222299A1 (de) Kommunikation mit geringer latenz
DE60114186T2 (de) Nachrichten-Vermittler
EP1083722A2 (de) Verfahren, System und Gateway, die einen End-zu-End gesicherten Zugriff auf WAP-Dienste erlauben
EP1604494B1 (de) Verfahren und sender zur übertragung von datenpaketen
DE10296626T5 (de) Verfahren zur unleugbaren Verwendung kryptographischer Signaturen in kleinen Einrichtungen

Legal Events

Date Code Title Description
8100 Publication of patent without earlier publication of application
8364 No opposition during term of opposition
8327 Change in the person/name/address of the patent owner

Owner name: DEUTSCHES ZENTRUM FUER LUFT- UND RAUMFAHRT E.V.

R119 Application deemed withdrawn, or ip right lapsed, due to non-payment of renewal fee

Effective date: 20130702