DE10305456A1

DE10305456A1 - Vorrichtung und Verfahren zur Optimierung einer Datenübertragung und von Speicheranforderungen in einer Anordnung mit Client-Einrichtung und Server-Einrichtung

Info

Publication number: DE10305456A1
Application number: DE10305456A
Authority: DE
Inventors: Nils Seifert; Jörg Ott
Original assignee: Tellique Kommunikationstechnik GmbH
Current assignee: Tellique Kommunikationstechnik GmbH
Priority date: 2003-02-04
Filing date: 2003-02-04
Publication date: 2004-08-12

Abstract

Die Erfindung bezieht sich auf ein Verfahren zum Übertragen von elektronischen Daten zwischen einem Server und einem Client über mindestens ein Übertragungsprotokoll, wobei eine Übertragungsstrecke vom Server zum Client in mindestens zwei Kommunikationsabschnitte unterteilt wird, die Unterteilung mindestens von einem Server-seitigen Zwischensystem und einem Client-seitigen Zwischensystem vorgenommen wird, auf einem Streckenabschnitt vom Server zum Server-seitigen Zwischensystem und auf einem Streckenabschnitt vom Client-seitigen Zwischensystem zum Client jeweils dasselbe Protokoll zum Einsatz kommt, und auf dem Streckenabschnitt vom Server-seitigen zum Client-seitigen Zwischensystem mindestens ein anderes, für die Eigenschaften dieses Streckenabschnitts optimiertes Protokoll zum Einsatz kommt. Ein Rückkanal von dem Client-seitigen Zwischensystem zum Server-seitigen Zwischensystem bleibt für die Dauer der Datenübertragung vom Server-Zwischensystem zum Client-Zwischensystem ungenutzt.

Description

Die Erfindungen liegen auf den Gebieten der Optimierung der Nutzung von Rückkanälen zur Datenübertragung zwischen einer Server-Einrichtung und einer Client-Einrichtung und/oder der Optimierung der Nutzung des Speicherplatzes auf den Empfangssystemen (Client-Einrichtungen).
Genereller Hintergrund:
Eine Datenübertragung in Datennetzen hat meist eine primäre Übertragungsrichtung. Lädt ein Internet-Nutzer beispielsweise eine große Datei aus dem Internet auf seinen Heim-PC, so werden die eigentlichen Nutzdaten dieser Datei von Einrichtungen aus dem Internet im Datennetz in Richtung des Heim-PCs übertragen (diese Übertragungsrichtung wird im folgenden "primäre Übertragungsrichtung" genannt; (3) in 1).
Aufgrund der Art der üblicherweise für diese Datenübertragung eingesetzten Übertragungsprotokolle (wie beispielsweise TCP – Transmission Control Protocol), ist es aber zumeist notwendig, während der Datenübertragung aus dem Internet zum Heim-PC auch regelmäßig Pakete in umgekehrter Richtung vom Heim-PC an/über die Einrichtungen im Internet bzw. an die eigentliche Datenquelle zu übertragen (diese Übertragungsrichtung wird im folgenden "rückwärtige Übertragungsrichtung" genannt; (4) in 1). Bei den in dieser Richtung übertragenen Paketen handelt es sich beispielsweise um Steuerpakete, mit denen beispielsweise der korrekte Empfang oder auch der nicht korrekte Empfang eines Teils der Nutzdaten (in diesem Beispiel letztendlich der Datei) der Datenquelle oder zwischengeschalteten Einrichtungen des Internets mitgeteilt werden.
Dies führt dazu, dass oftmals während der Dauer der Übertragung in der primären Übertragungsrichtung auch eine Übertragung in der rückwärtigen Übertragungsrichtung stattfindet. Diese rückwärtige Übertragung umfasst zwar oftmals deutlich weniger Daten (beispielswei se, wenn es sich nur um Steuerpakete handelt), erfordert aber dennoch eine relative häufige Nutzung des Datennetzes in rückwärtiger Richtung.
Unabhängig davon wird der Transfer von Informationen von der Datenquelle zum Nutzer durch den Nutzer initiiert. Hierzu wird mindestens eine Anfrage vom Heim-PC in der "rückwärtigen Übertragungsrichtung" an die eigentliche Datenquelle gesendet. Es ist also im allgemeinen auch anfänglich eine kurzzeitige Möglichkeit zur Kommunikation vom Heim-PC zur Datenquelle erforderlich. Nach Übermittlung der "Anfrage", wird die rückwärtige Übertragungsrichtung für diesen Zweck nicht mehr benötigt (bzw. erst wieder zum Stellen des nächsten Anfrage).
Diese Übertragung in rückwärtiger Richtung wird im folgenden auch Übertragung auf dem Rückkanal bzw. Rückkanal-Nutzung genannt.
Es ist sehr stark von den Verwendung findenden Datennetzen (oder allgemein Übertragungs- bzw. Kommunikations-Netzen) abhängig, wie in diesen Netzen (bzw. auf Teilabschnitten dieser Netze) eine Übertragung in der primären Übertragungsrichtung bzw. rückwärtigen Übertragungsrichtung ("auf dem Rückkanal") stattfinden kann.
Dabei gibt es insbesondere Netze bzw. Teilabschnitte dieser Netze, in denen der Rückkanal schmalbandiger ist und/oder nicht kontinuierlich zur Verfügung steht und/oder eine Datenübertragung auf dem Rückkanal mit Nachteilen wie beispielsweise höheren Kosten verbunden ist.
Einige Beispiele für diese Netze (hier sprachlich nicht von Übertragungsstrecken, Übertragungsmedien, Übertragungsabschnitten oder Netzabschnitten unterschieden) sind unter anderem:

a) 2-Wege Satellitennetze: Bei denen oftmals ein breitbandiger Übertragungskanal (von einigen 10 kbit/s bis zu vielen Mbits/s in der primären Richtung zur Verfügung steht, der ebenfalls über Satellit realisierte Rückkanal aber nur schmalbandiger ausgelegt ist. In vielen dieser Netze muß ein Rückkanal zur Nutzung durch eine Sendeeinrichtung zudem zunächst reserviert werden und/oder es konkurrieren mehrere Sendeeinrichtungen um die Nutzung eines einzelnen oder einer Anzahl an Rückkanälen (beispielsweise verbunden mit Time- und/oder Frequenzmultiplexings).
b) 1-Wege Satellitennetze mit alternativem Rückkanal: Einige Satellitennetze nutzen den Satelliten auch nur zur Datenübertragung in der primären Übertragungsrichtung. In der rückwärtigen Übertragungsrichtung werden dagegen andere Netze wie das Telefonnetz (POTS, ISDN, ...), das Internet, Funknetze, Mobilfunknetze (GSM, GPRS, UMTS, ...), ... eingesetzt (um nur einige der vielfältigen Möglichkeiten zu nennen). In diesen Fällen ist der Rückkanal oftmals wesentlich schmalbandiger als die in der primären Übertragungsrichtung mögliche Bandbreite. Zudem entstehen während der Nutzung des Rückkanals oftmals zusätzliche und/oder höhere Kosten.

Netze mit diesen Rückkanal-Eigenschaften sind aber bei weitem nicht auf die Nutzung von Satellitennetzen bzw. Satelliten-Übertragungsstrecken beschränkt.
In gleicher Weise könnte eine Übertragung über 2-wege Fernsehkabelnetze oder 1-wege Fernsehkabelnetze mit alternativem Rückkanal (wie oben unter b) beispielhaft aufgeführt) realisiert werden. Auch das relativ neu eingeführte DVB-T Broadcast Netz könnte zur 1-wege Übertragung mit einem alternativen Rückkanal genutzt werden.
Und nicht zuletzt auch herkömmliche kabelgebundene ADSL-Anschlüsse bieten oftmals in primärer Übertragungsrichtung eine größere Bandbreite als im zumeist nur zur rückwärtigen Übertragung eingesetzte Rückkanal.
Realisierbar sind auch Rückkanäle, die gar keine Netzverbindung im eigentlichen Sinne ermöglichen, sondern nur die Austausch kleinster Datenmengen wie beispielsweise einer SMS Nachricht in Mobilfunknetzen.
Festzuhalten bleibt daher insgesamt, dass es oftmals aus Kostengründen und/oder Performancegründen und/oder zum Freihalten von Übertragungskapazität für andere Zwecke sehr vorteilhaft sein kann, die Menge der in rückwärtiger Übertragungsrichtung ("auf dem Rückkanal") ausgetauschten Daten/Pakete möglichst gering zu halten. Dies ist ein Ziel dieser Erfin dung und kann beispielsweise Vorteile für den Endanwender und/oder Dienstanbieter und/oder Netzbetreiber bieten.
Neben dem Ziel, die Menge der über den Rückkanal ausgetauschten Daten gering zu halten, ist es ein erweitertes Ziel dieser Erfindung nach Möglichkeit auch die Zeitspannen, für die ein Rückkanal überhaupt genutzt wird, möglichst kurz zu halten. Also beispielsweise in einem optimalen Fall eben nur ganz zu Beginn einer Datenübertragung das eigentliche Kommando (bzw. Steuerpaket) zum Anfordern der Daten über den Rückkanal zu senden und anschließend möglichst ganz ohne weitere Nutzung, bzw. zeitlich möglichst gebündelter Nutzung, ... den Rückkanal möglichst weitgehend ungenutzt zu lassen. Dies bietet beispielsweise bei einem 2-wege Satellitennetz den Vorteil, dass eine gegebenenfalls erst anzufordernde Nutzung/Reservierung (die systembedingt auch zu einer weiteren Verzögerung des Kommunikationsvorgangs führt) eines Rückkanals möglichst selten erforderlich wird. Bei einem 1-wege Satellitennetz mit einem alternativen Rückkanal beispielsweise über das Telefonnetz bietet es den Vorteil, dass nach Möglichkeit/gegebenenfalls die Telefonverbindung nicht für die gesamte Dauer der Übertragung in der primärer Übertragungsrichtung aufrecht erhalten werden muss und so die Kosten für die Bereitstellung und Nutzung des Rückkanals deutlich gesenkt werden können.
Im folgenden werden verschiedene Aspekte und Anordnungen zur Lösung dieser Aufgabe dargestellt, wobei die Merkmale der einzelnen Anordnungen und Aspekte sowohl einzeln als auch in beliebiger Kombination bei der Verwirklichung der Erfindung in ihren verschiedenen Ausführungsformen von Bedeutung sein können. Insbesondere ergibt jede Anordnung und/oder jeder Aspekt für sich eine wesentliche Verbesserung des vorgenannten Standes der Technik.
Hierbei zeigen:
1 einen möglichen Grundaufbau der Erfindung;
2 eine bekannte Anordnung; und
3 eine erfindungsgemäße Anordnung, in der Client-Einrichtungen der Empfänger nicht nur Informationen von den Server-Einrichtungen empfangen können.
Die primäre Übertragungsrichtung erfolgt von einer Datenquelle 5 zu einem Empfänger 6. Zwischen der Datenquelle und dem Empfänger befindet ein Netz oder Netzabschnitt, in dem zwischen der primären Übertragungsrichtung und der Nutzung des Rückkanals/rückwärtige Übertragungsrichtung unterschieden wird und eine Optimierung der Rückkanal-Nutzung stattfinden soll.
Zu diesem Zweck werden eine Server-Einrichtung 1 und eine Client-Einrichtung 2 eingeführt.
Die Server-Einrichtung 1 und die Client-Einrichtung 2 sind dabei über ein Übertragungsnetz miteinander verbunden. Bei diesem Übertraungsnetz kann es sich dabei auch um mehrere verschiedene Übertragungsabschnitte und Netze handeln, die gemeinsam bzw. als Kette genutzt werden. Dabei kann das Übertragungsnetz gegebenenfalls auch unterschiedliche oder auch gleichartige Netze, Netzabschnitte beziehungsweise Übertragungsabschnitte für die einzelnen Übertragungsrichtungen 3 und 4 nutzen. Eventuell werden auch nur auf einem Teilabschnitt des Übertragungsnetzes unterschiedliche Netze beziehungsweise Technologien für die Übertragungsrichtungen 3 und 4 genutzt.
Die Datenquelle 5 kann (wie in 1 gezeigt) beispielsweise in einem mit der Server-Einrichtung verbundenen Datennetz angeordnet sein. Bei diesem Datennetz könnte es sich beispielsweise auch um das Internet und bei der Datenquelle über ein mit dem Internet verbundenen Webserver handeln.
Es ist aber auch möglich, dass die Datenquelle 5 über dedizierte Netzverbindungen mit der Server-Einrichtung 1 verbunden ist. Ebenso ist es möglich, dass die Datenquelle direkt lokal auf der/in die Server-Einrichtung integriert ist.
Der Empfänger 6 kann (wie in 1 gezeigt) beispielsweise in einem mit der Client-Einrichtung 2 verbundenen Datenetz angeordnet sein. Bei diesem Datennetz könnte es sich beispielsweise auch um ein lokales Datennetz (LAN) oder ein Corporate Netz handeln. Der Empfänger selbst könnte beispielsweise ein Internet-Browser auf einem Computer sein.
Es ist aber auch möglich, dass der Empfänger 6 über dedizierte Netzverbindungen mit der Client-Einrichtung 2 verbunden ist. Ebenso ist es möglich, dass der Empfänger direkt lokal auf der/in die Client-Einrichtung integriert ist (beispielsweise ein Internet-Browser direkt auf der Client-Einrichtung). Auch ist es möglich, dass der Empfänger 6 über ein komplexes (aus mehreren Teilnetzen bestehendes und geographisch und topologisch ausgedehntes) IP-Netz (das Internet, ein Unternehmens- oder ein Campus-Netz) mit der Client-Einrichtung verbunden.
Für die Anordnung der Datenquelle sowie des Empfängers und deren Verbindung mit der Server-Einrichtung beziegungsweise Client-Einrichtung sind viele Kombinationen und der Einsatz vielfältiger Datennetze und Datenverbindungen möglich, die dem Fachmann bekannt sind. Wichtig für die Erfindung ist, dass der Datenaustausch zwischen der Datenquelle und dem Empfänger über die Server-Einrichtung und die Client-Einrichtung geführt wird, so dass die im folgenden beschriebenen Anordnungen, Vorrichtungen und Verfahren Anwendung finden können.
Die beschriebenen Erfindungen sind sowohl mit als auch ohne Rückkanal einsetzbar sowie in Systemen, die nur gelegentlich über einen Rückkanal verfügen. Siehe zum Einsatz und zum Nutzen der Erfindung in Systemen ohne Rückkanal und der Vorteilen insbesondere die Abschnitte XV. und XVI.
I. Ausfiltern, Modifizieren und Einfügen von Paketen in bestehende Protkolle:
Viele zur Datenübertragung genutzte Protokolle, wie beispielsweise das TCP-Protokoll, nutzen und benötigen neben den Nutzdaten in den eigentlichen Datenpaketen auch Steuerinformationen (innerhalb der Datenpakete/Datenpaketheadern bzw. in zusätzlichen Steuerpaketen).
Diese Steuerinformationen werden dabei auch während der laufenden Datenübertragung in der primären Übertragungsrichtung über den Rückkanal ausgetauscht.
Es ist sehr vorteilhaft diese bestehenden Protokolle zur Datenübertragung wie beispielsweise TCP auch weiterhin zur Kommunikation mit dem Empfänger und der Datenquelle einzusetzen. Ein Austausch oder eine Modifikation dieser bestehenden Protokolle im Empfänger und/oder der Datenquelle ist oftmals nicht möglich oder mit zusätzlichem und potentiell nicht akzeptablem Zusatzaufwand verbunden.
Daher können im Rahmen dieser Erfindung die Client-Einrichtung und die Server-Einrichtung genutzt, um den Paketstrom und/oder Paketinhalt zwischen der Client-Einrichtung und Server-Einrichtung zumindest in der rückwärtigen Übertragungsrichtung zu modifizieren.
Bei vielen der über den Rückkanal gesendeten Pakete handelt es sich bei den meisten Protokollen um sogenannte Bestätigungen (Acknowledgements, ACKs), die der Datenquelle den korrekten Empfang von Nutzdaten durch den Empfänger bestätigen. Solche ACKs nutzt die Datenquelle oftmals zum Steuern von Übertragungswiderholungen, falls Nutzdaten nicht bestätigt werden. TCP (wie auch andere Protokolle) sieht feste Regeln vor, in bei welchen Ereignissen und in welcher Häufigkeit diese Bestätigungen generiert und gesendet werden müssen. Ein Abschalten bzw. Unterdrücken auf dem Empfangssystem ist im Protokoll nicht vorgesehen.
Im Rahmen dieser Erfindung gibt es mehrere Optimierungsmöglichkeiten zur Vermeidung von vielen Steuerpaketen mit ACKs über den Rückkanal. Dabei können diese Möglichkeiten sowohl einzeln als auch kombiniert eingesetzt werden.
Die Client-Einrichtung kann ACKs beispielsweise verzögern und so gesammelt (mehrere ACKs gemeinsam) an die Server-Einrichtung weiterleiten.
Alternativ bzw. zusätzlich kann die Client-Einrichtung ACKs (bzw. die entsprechenden Pakete) vollständig oder teilweise unterdrücken. Abhängig vom eingesetzten Übertragungsprotokoll wird es in diesem Fall oftmals erforderlich, dass die Server-Einrichtung die von der Client-Einrichtung unterdrückten ACKs selbstständig erzeugt und an die Datenquelle weiterleitet (da ansonsten oftmals die Datenquelle die Übertragung beispielsweise pausieren würde oder bereits gesendete Datenpakete erneut sendet). Falls die Server-Einrichtung selbstständig ACKs generiert und an die Datenquelle gesendet hat, muss sie intern die entsprechenden Datenpakete (beziehungsweise Nutzdaten) speichern, damit sie sie gegebenenfalls erneut über die Client-Einrichtung an den Empfänger senden kann (falls diese dort nicht korrekt angekommen sind).
Zusätzlich beziehungsweise alternativ kann die Client-Einrichtung von dem Empfänger empfangene ACK-Information (die den konekten Datenempfang angeben) so modifizieren, dass sie nur sogenannte Negative Acknowledgements NACKs an die Server-Einrichtung weitergibt. Dabei muss die Client-Einrichtung (je nach verwendetem Protokoll) zusätzlich zu den empfangenen ACKs die an den Empfänger weitergeleiteten Datenpakete/Nutzdaten beachten, um gegebenenfalls selbstständig ein NACK zu erzeugen, wenn ein Datenpaket/bestimmte Nutzdaten beispielsweise nach einer bestimmten Zeitspanne nicht von dem Empfänger mit einem ACK bestätigt wurden.
Die Server-Einrichtung wird in diesem Fall aus den erhaltenen NACKs und dem Wissen über die (und den Zeitpunkt der) an die Client-Einrichtung gesendete Datenpakete/Nutzdaten wieder ACKs entsprechend dem ursprünglichen Protokoll generieren und an die Datenquelle senden.
Bei vielen Übertragungsprotokollen einschließlich TCP gibt es zudem Verfahren zur sogenannten Flußkontrolle. Dabei gibt im wesentlichen die Empfangsseite ein sogenanntes Window vor, das angibt, wie viele Nutzdaten von der Sendeseite gesendet werden dürfen, ohne weitere Steuerinformation der Empfangsseite abzuwarten.
Daher bietet es sich im Rahmen der Optimierung der Rückkanal-Nutzung auch an, dieses Window/diese Windowsize entweder direkt auf dem Empfangsrechner auf einen hohen Wert zu setzen, oder aber durch ein Modifizieren entsprechender Protokoll Steuerinformationen auf der Client-Einrichtung und/oder der Server-Einrichtung der Datenquelle ein größeres auf dem Empfänger eingestelltes Window vorzutäuschen. In letzterem Fall wird es in der Regel die Client-Einrichtung sein, die beim Weiterleiten der empfangenen Datenpakete/Nutzdaten prüft, ob der eigentliche Empfänger momentan entsprechend des eigentlichen Windows ausreichend Speicherplatz zum Datenempfang vorrätig hat. Dementsprechend würde die Client-Einrichtung die Datenpakete/Nutzdaten gegebenenfalls entsprechend zwischenspeichern, bevor sie sie an den Empfänger weiterleitet.
Ein Verbindungsabbau auf der Ebene eines Übertragungsprotkolls könnte sich implizit aus einem Protokoll einer höheren Ebene ergeben. Beispielsweise bei Verwendung des ISO/OSI Schicht 4 Transportprotokolls TCP könnte ein TCP-Verbindungsabbau durch die Client-Einrichtung und/oder Server-Einrichtung selbstständig vorgenommen werden, sobald auf einer höheren Ebene wie beispielsweise einem genutzten HTTP Protokoll erkenntlich ist, dass eine Datenübertragung abgeschlossen ist (beispielsweise entsprechend der Menge der über tragenen Nutzdaten). In diesem Fall würde – gegebenenfalls nach Ablauf eines entsprechenden Timeouts – die Server-Einrichtung und/oder Client-Einrichtung die TCP Verbindung zur Datenquelle beziehungsweise zum Empfänger schließen, wenn alle Nutzdaten übertragen wurden. Auf die Übertragung entsprechender Steuerinformationen zwischen der Client-Einrichtung und der Server-Einrichtung würde in diesem Fall verzichtet werden können.
II. Nutzung spezieller Übertragungsprotokolle:
Während unter I. zunächst noch davon ausgegangen wird, dass das bestehende Übertragungsprotokoll (wie beispielsweise TCP) in mehr oder weniger stark modifizierter Form auch zur Datenübertragung zwischen dem Client-Proxy und dem Server-Proxy genutzt wird, ist es alternativ auch möglich, zwischen diesen beiden Komponenten ein eigens für diesen Zweck entwickeltes Protokoll einzusetzen. Dieses speziell entwickelte Protokoll nennen wir im folgenden ETCP (für Enhanced TCP).
Dabei würde potentiell (wie auch unter I. beschrieben) auch in diesem Fall weiterhin das bestehende Protokoll zur Kommunikation zwischen der Datenquelle und der Server-Einrichtung sowie zwischen der Client-Einrichtung und dem Empfänger eingesetzt werden.
Falls es aber möglich ist, das vom Empfänger oder der Datenquelle verwendete Protokoll auszutauschen, könnte man so zumindest auf einer der beiden Seiten die Funktionalität der Client-Einrichtung beziehungsweise Server-Einrichtung und damit die Unterstützung des Speziellen ETCP Protokolls auch direkt in den Empfänger bzw. die Datenquelle integrieren.
Ein speziell entwickeltes ETCP Protokoll könnte viele Erweiterungen enthalten, die einer Optimierung der Rückkanal-Nutzung dienen. Dabei können diese Möglichkeiten sowohl einzeln als auch kombiniert eingesetzt werden.
Es könnten nur aggregierte bzw. eine große Anzahl an Paketen bzw. Nutzdaten umfassende ACKs gesendet werden.
Schließlich können ACKs soweit reduziert werden, dass nur noch ein ACK pro Nutzeranfrage erzeugt wird, etwa sobald alle Daten empfangen worden sind. Die Server-Einrichtung könnte in einem solchen Fall die Daten beispielsweise wiederholt senden, bis schließlich ein ACK empfangen wird und dann den Transfer abbrechen.
Als weitere Alternative kann das ETCP Protokoll beispielsweise auch gänzlich auf das Senden von ACKs verzichten, wenn das Protokoll ein implizites ACK bei beispielsweise vollständig korrektem Empfang (je nach genutzten Zusatzverfahren ggf. nach Auswertung von Forward-Error-Correction) vorsieht. Dies hat unter anderem den Vorteil, dass noch weniger Daten auf dem Rückkanal ausgetauscht werden müssen und/oder der Rückkanal während einem korrekt laufenden Datenempfang sogar gänzlich ungenutzt bleiben kann und/oder sogar abgebaut wird, um beispielsweise sonst anfallende Zeit- und/oder Volumengebühren für die Rückkanal-Nutzung einzusparen.
Diese Optimierung kann beispielsweise auch in Kombination mit höheren Protokollschichten (wie etwa HTTP) erfolgen. Dabei könnte mit einem Request auf höherer Ebene implizit eine rückwärtige Datenübertragung von der Server-Einrichtung zur Client-Einrichtung starten. Die Client-Einrichtung könnte dabei für den Regelfall komplett auf das Senden von ACKs verzichten, solange Informationen über eben nicht entsprechend der ETCP Protkollspezifikation vorab als gegeben angenommene Ereignisse auftreten. Beispielsweise könnte ein vollständiger Empfang aller von der Server-Einrichtung an die Client-Einrichtung gesendeten Paketen bzw. Nutzdaten angenommen werden. Sofern diese Vorab-Annahmen nicht zutreffen, meldet die Client-Einrichtung dies der Server-Einrichtung (beispielsweise über ein ACK der Teilmenge der korrekt empfangenen Daten oder ein bzw. mehrere entsprechende NACKs). Auch für weitere Funktionen eines Transportprotokolls wie der weiter unten aufgeführten Flußkontrolle und/oder Staukontrolle lassen sich so über Vorab-Annahmen optimieren, so dass möglichst selbst eine Rückmeldung und damit Nutzung des Rückkanals von der Client-Einrichtung zur Server-Einrichtung erforderlich ist (hier könnten die Vorab-Annahmen beispielsweise sein, dass für die Flußkontrolle die Client-Einrichtung immer noch einen Empfangsspeicher von einer vordefinierten Größe frei hat; für die Staukontrolle könnte die Annahme sein, dass die Client-Einrichtung nicht mehr als einen bestimmten Prozentsatz an Paketen bzw. Nutzdaten nicht korrekt empfangen konnte, ...).
Wenn ACKs des Transportprotokolls in Zusammenhang mit höheren Protokollschichten (wie etwa HTTP) betrachtet werden, können sie nicht einfach nur syntaktische Dateneinheiten (etwa Anzahlen von Bytes oder Paketen) bestätigen, sondern vielmehr auch auf semantischer Ebene eingesetzt werden. Dann lassen sich ein oder mehrere semantische Objekte (etwa einzelne Dateien, Bilder, Webseiten usw.) durch ein oder mehrere ACKs bestätigen.
ACKs können Informationen über die Empfangsqualität (z.B. Anzahl der Paketverluste) enthalten, auf deren Basis die Server-Einrichtung die nächste Datenübertragung anpassen kann (z.B. durch Erhöhen oder Reduzieren von Redundanz = FEC, siehe auch III. unten).
Es könnten NACKs gänzlich oder zumeist anstelle von ACKs verwendet werden, und zwar in allen oben genannten Variationen.
Verfahren zur Flußkontrolle innerhalb des ETCP Protokolls könnten an selten genutzte ACKs und/oder NACKs angepasst werden und so ein relativ großes Window zum Sicherstellen einer unterbrechungsfreien Datenübertragung auch bei nur extrem selten über den Rückkanal von der Client-Einrichtung zur Server-Einrichtung eingehender Steuerinformationen gewährleistet werden.
Auch Verfahren zur sogenannten Congestion Control (Staukontrolle), mit der Übertragungsprotokolle beispielsweise anhand auftretender/gemeldeter Paketverluste die zur Verfügung stehende Bandbreite abschätzen, könnten im ETCP Protokoll angepasst werden und so mit sehr wenigen von der Client-Einrichtung zur Server-Einrichtung ausgetauschten Steuerinformationen arbeiten können.
Ein Verbindungsabbau auf der ETCP-Ebene könnte sich ebenfalls, wie unter I. beschrieben, implizit aus einem Protokoll einer höheren Ebene ergeben. Alternativ kann auf der ETCP-Ebene eine längerfristige Kommunikationsverbindung realisiert werden, die potentiell viele Interaktionen des Nutzers mit einer oder mehrerer Datenquelle(n) umfasst. Innerhalb einer solchen ETCP-Beziehung können dann die einzelnen Anfragen und der Nutzdatentransfer abgewickelt werden. Alternativ könnte der Verbindungsabbau auch durch allein von der Server-Einrichtung an die Client-Einrichtung gesendeten Steuerinformationen und/oder durch das Ablaufen einer bestimmten Zeitspanne (beispielsweise Inaktivitätsspanne) ergeben – also auch hier wieder mit wenigen oder keinen von der Client-Einrichtung an die Server-Einrichtung zu übertragenen Steuerinformationen). Alternativ könnte man Steuerinformationen beispielsweise für den Abbau einer ETCP-Verbindung auch gegebenenfalls zeitlich verzögert zusammen und/oder sogar innerhalb von Informationen einer neuen ETCP-Verbindung und/oder zusammen bzw. innerhalb von Informationen einer höheren Protokollebene austauschen. Dies könnte unter anderem vorteilhaft sein, wenn die Nutzung des Rückkanals dabei nur oder zumindest weitgehend nur dann erfolgt, wenn sowieso anderweitige Informationen von der Client-Einrichtung an die Server-Einrichtung ausgetauscht werden sollen.
Vorteilhaft kann es sein, wenn das ETCP Protokoll selbst wieder auf Standardprotokollen beziehungsweise Standardprotokollheadern aufsetzt.
Dies bietet den Vorteil, dass die die Client-Einrichtung und Server-Einrichtung sowie potentiell zwischengeschaltete Netzkomponenten die ETCP Pakete entsprechend darunterliegender Standardprotokolle und Protokollheader weiterleiten und behandeln können. Dabei bietet sich insbesondere das Nutzung von Standard-IP Paketheadern unterhalb der ETCP Header an. Zusätzlich kann es sinnvoll sein oberhalb von IP zusätzlich UDP Header zu verwenden, damit die ETCP Implementierung als normaler User-mode Prozess ohne notwendige Root-/Administrator-Rechte implementiert werden könnte.
Die Client-Einrichtung und die Server-Einrichtung müssen sich offensichtlich zwischen der Anwendung des Nutzers und der Datenquelle befinden. Dies kann u.a. auf folgende zwei Arten realisiert werden:
– Proxy-basierter Ansatz
Der Proxy-basierte Ansatz nutzt aus, dass heutige Anwendungen (nicht nur) zum Zugriff auf das Internet die Nutzung sogenannter Proxy-Server oder kurz Proxies unterstützen. In solchen Anwendungen kann der Nutzer konfigurieren, welcher Proxy für die Kommunikation verwendet werden soll. Alle folgende Anfragen und auch die entsprechenden Antworten durchlaufen dann diesen Proxy.
Stellt der Nutzer als Proxy die Adresse der Client-Einrichtung ein, so richtet die Anwendung alle Anfragen an die Client-Einrichtung, die diese dann bearbeiten und/oder anschließend zur Server-Einrichtung übertragen und/oder beantworten kann. Damit erhält die Client-Einrichtung die notwendige Kontrolle zur Bearbeitung und kann die im Rahmen dieser Erfindung beschriebenen Funktionen – ggf. gemeinsam mit der Server-Einrichtung – ausführen.
Eine Programme unterstützen statt oder in Ergänzung zu Proxies auch die sogenannte SOCKS-Schnittstelle. Auch damit lassen sich Anfragen und/oder Daten gezielt an eine Client-Einrichtung übermitteln, die dann (wie eben beschrieben) die weitere Bearbeitung im Sinne dieser Erfindung übernimmt.
– Transparenter Ansatz
Die eben beim Proxy-basierten Ansatz skizzierten Vorgehensweisen erfordern in allen Fällen eine (potentiell explizite) Konfiguration und damit ein (potentiell fehlerträchtiges) Eingreifen des Nutzers.
Statt dessen kann auch die Client-Einrichtung so aufgebaut werden, dass sie sich im Kommunikationspfad von der Anwendung zum Internet befindet. Die Client-Einrichtung kann dann alle von den Anwendungen Richtung Internet gesendeten IP-Pakete empfangen und je nach Paket (z.B. an Hand der Protokolltyps auf Transport und Anwendungsebene) entscheiden, ob sie Pakete einfach weiterleitet oder sie einer gesonderten Bearbeitung unterzieht. In letzterem Fall kann die Client-Einrichtung die Verbindung bzw. die Kommunikationsbeziehung von der Anwendung – transparent für letztere – terminieren und die von der bzw. an die Anwendung gesendeten Informationen im Sinne der Erfindung bearbeiten und/oder weiterleiten und/oder beantworten; dann führt sie (wie vorstehend auch für den Proxy-basierten Ansatz skizziert) im Rahmen dieser Erfindung beschriebenen Funktionen (ggf. im Zusammenspiel mit der Server-Einrichtung) durch.
Beide Ansätze lassen sich für UDP/IP-basierte wie auch TCP/IP-basierte Protokolle einsetzen, sind aber nicht auf diese beschränkt. Auch SCTP, ICMP, IGMP, Routing-Protokoll u.a. – im Prinzip alle IP-basierten Protokolle – lassen sich so durch die Client-Einrichtung "einfangen" und in Kooperation mit der Server-Einrichtung im Sinne der Erfindung optimieren.
Dabei ist der transparente Ansatz eventuell flexibler, weil es keine besonderen Anforderungen an die Art der Anwendung gibt.
III. Einsatz von Forward-Error-Correction:
In Transport-Protokollen im Internet (wie TCP) wird der Erhalt von Nutzdaten bestätigt. Dies ist notwendig, weil Pakete bei der Übertragung verloren gehen können. Paketverluste können aufgrund von Netzüberlast (dann werfen Router Pakete weg) oder durch Übertragungsfehler (wie z.B. Bitfehler) entstehen. Wird für ein Datenpaket keine Bestätigung empfangen, werden die unbestätigten Nutzdaten erneut (als ein oder mehrere Pakete). Auf diese Weise wird Zuverlässigkeit bei der Übertragung erzielt.
Paketverlusten im Netz läßt sich bekanntermaßen auch durch sogenannte Vorwärtsfehlerkorrektur (Forward Error Correction, FEC) begegnen. Dann werden nicht nur die zu übertragenden Nutzdaten übermittelt, sondern zusätzlich werden Redundanzinformationen gesendet. Im einfachsten Fall könnte jedes Paket immer mehrfach gesendet werden; es genügt dann, dass eine Kopie des Pakets ankommt, um die enthaltenen Nutzdaten zurückzugewinnen. Im allgemeinen verwendet man jedoch komplexere Verfahren, um die zu übertragenden Redundanzinformationen zu berechnen. Beispiele sind Parity FEC (Exklusiv-Oder-Verknüpfung über eine Folge von Paketen) und Vandermond-Matrizen. Bei solchen Verfahren werden aus zur Übertragung von k Paketen mit Nutzdaten n (mit n > k) Pakete gesendet. Die n-k zusätzlichen Pakete werden nach mathematischen Verfahren so berechnet, dass sich die Nutzdaten beim Empfänger rekonstruieren lassen, wenn z.B. beliebige k der n Pakete ankommen.
Diese Verfahren lassen sich auch für die Kommunikation über ETCP anwenden. Die Server-Einrichtung ergänzt die von der Datenquelle empfangenen Nutzdaten um Redundanzinformationen entsprechend eines dieser Verfahren und sendet die so angereicherten Daten zur Client-Einrichtung. Diese kann einzelne Paketverluste korrigieren. Durch diesen Ansatz steigt die Wahrscheinlichkeit, dass alle Informationen trotz Paketverlusten im Netz korrekt empfangen werden, und somit werden Bestätigungen (ACKs oder NACKs) seltener benötigt, im Idealfall kann ganz auf sie verzichtet werden. Oder sie können zumindest auf die einmalige Bestätigung des gesamten Inhalts reduziert werden oder eben auch Teile des Inhalts (negativ) bestätigen. Siehe auch die Ausführnugen zu ACKs und NACKs unter II.
Ein wesentlicher Parameter der Vorwärtsfehlerkorrektur ist – neben dem eingesetzten (mathematischen) Verfahren der Redundanzanteil. Darunter verstehen den Anteil der zusätzlich übertragenen Informationen an den eigentlichen Nutzdaten: Werden 10 KB (oder 10 Pakete) Nutzdaten übermittelt und 2 KB (bzw. 2 Pakete) Redundanzinformationen übertragen, so sprechen wir von 20% Redundanz(-anteil).
Der Redundanzanteil kann einmalig festgelegt werden, er kann aber auch dynamisch an das beobachtete Übertragungsverhalten (die "Dienstgüte" des Netzes, beispielsweise gemessen in relativen Paketverlusten) angepasst werden. So können etwa ACKs oder NACKs oder auch Anfragen Informationen über die zuletzt von der Client-Einrichtung beobachtete Netzqualität enthalten und der Server-Einrichtung damit Hinweise für zukünftige Übertragungen geben. Werden beispielsweise 10% Paketverluste von der Client-Einrichtung beobachtet und gemeldet, kann die Server-Einrichtung die Nutzdaten künftig mit z.B. 15% Redundanz anreichern, um die Wahrscheinlichkeit zu erhöhen, dass alle Nutzdaten beim der Client-Einrichtung rekonstruiert werden können.
FEC-Verfahren ergänzen also die übertragenen Informationen um Redundanzen, um – je nach gewähltem FEC-Verfahren – eine begrenzte Anzahl von Paketverlusten ausgleichen zu können. Je nach Eigenschaften der Übertragungsnetze können die Paketverluste unterschiedlicher Natur sein: es können einzelne Pakete verloren gehen oder und mehrere aufeinander folgende Pakete ("Bursts"). Diese Verlustcharakteristik hat jedoch wiederum Einfluss auf die Effektivität eines FEC-Verfahrens. Wird beispielsweise 20% Redundanz so eingesetzt, dass jeweils aus 12 aufeinander folgenden Paketen nur 10 empfangen werden müssen, um die Nutzdaten empfängerseitig zu rekonstruieren, so schützt dies gegen (regelmäßig auftretende) einzelne Pakete von z.B. 10%. Gehen hingegen drei aufeinanderfolgende Pakete in einer 12-Paket-Sequenz verloren, so lassen sich die Nutzdaten nicht rekonstruieren. Wenn Pakete in Bursts verloren gehen, sind ergänzende Maßnahmen notwendig, wie z.B. Interleaving, d.h. das verschränkte Versenden von Datenpaketen. Hierbei werden dann nicht, um bei obigen Beispiel zu bleiben, die 12 Pakete einer Sequenz am Stück gesendet, sondern mit Paketen aus anderen Sequenzen abgewechselt. Betrachtet man etwa 5 Sequenzen A bis E, die jeweils aus den Paketen A1, A2, ..., A12 bzw. B1, B2, ..., B12 usw. bestehen, so kann eine verschränkte Übertragung dann bedeuten, dass die Pakete etwa in folgender Reihenfolge übertragen werden: A1, B1, C1, D1, E1, A2, B2, C2, D2, E2, A3, B3, C3, D, E3, ..., A12, B12, C12, D12, E12. Gehen jetzt drei oder auch fünf aufeinanderfolgende Pakete verloren, so trifft dies im Ergebnis aufgrund der Verschränkung nur jeweils maximal ein Paket aus jeder Sequenz – und die Nutzdaten alle Sequenzen können aus den redundanten Informationen rekonstruiert werden.
Natürlich sind beliebige Formen der Verschränkung möglich; diese können den jeweils beobachteten lassen sich beispielsweise an die zu erwartentenden und/oder gemessenen Übertragungscharakteristika anpassen.
IV. Einsatz vorausschauender Übertragung:
Ein weiterer Problembereich bei der Minimierung der Nutzung der rückwärtigen Übertragungsrichtung ist die Tatsache, dass viele Anwendungen im Internet – insbesnodere der Zugriff auf Webserver – nicht in Form einer einzigen Anfrage erfolgt. Eine auf einem Webserver gespeicherte Webseite enthält beispielsweise oftmals eine Vielzahl von Objekten – Frames, Bilder, Skripte usw. –, die in die umgebende Seite (den Container) eingebettet sind.
Eine Anfrage vom Heim-PC eines Nutzers wird zunächst nur diesen Container (ggf. schon mit einigem Inhalt gefüllt) liefern. In dem Container selbst sind Verweise auf die weiteren Objekte enthalten, die zur Darstellung der Seite für den Nutzer angefordert werden müssen. Der Browser auf dem Heim-PC des Nutzers stellt nach Erhalt des Containers folgerichtig eine Reihe weiterer Anfragen, deren Beantwortung dann sukzessive die weiteren Inhalte liefern. Dieser Vorgang kann iterativ und/oder rekursiv fortgesetzt werden, bis alle zur Darstellung der angefragten Webseite erforderlichen Inhalte übertragen worden sind.
Entsprechende Erfordernisse lassen sich auch bei anderen Anwendungen beobachten: etwa beim entfernten Zugriff auf Dateien (wo die Blöcke einzeln angefragt werden können), auf Emails (wo sukzessive die verschiedenen Mails der Mailbox angerufen werden) usw.
Entscheidend ist in allen Fällen, dass die Anwendung eines Nutzers mehrere Anfragen stellen muss (wobei sie potentiell auf die Ergebnisse der vorhergehenden Anfragen angewiesen ist und auf diese warten muss), um aus Sicht des Nutzers eine Aktion durchzuführen (das Abrufen _einer_ Webseite, das Herunterladen _einer_ Datei, das Aholen _einer_ Mailbox usw.).
Für alle jeweils sukzessiv zu stellenden Anfragen sind jeweils – nach der ersten Anfrage – Daten in die rückwärtige Übertragungsrichtung zu senden. Dies gilt es zu vermeiden oder zumindest zu minimieren.
Wenn die Anwendung eines Nutzers eine Anfrage stellt, so richtet sie diese zunächst an die Client-Einrichtung. Diese überprüft ggf. die Anfrage und leitet sie dann an die Server-Einrichtung weiter. Die Server-Einrichtung empfängt die Anfrage von der Anwendung des Nutzers (über die Client-Einrichtung) und leitet diese an die eigentliche Datenquelle weiter. Aus der Anfrage und/oder der/den ersten Antwort(en) von der Datenquelle auf die erste Anfrage unter Berücksichtigung der jeweiligen Anwendung kann die Server-Einrichtung dann Rückschlüsse ziehen, welche Anfrage die Anwendung des Nutzers als nächsten stellen wird. Diese Anfragen (im folgenden als "Vorab-Anfragen" bezeichnet) kann die Server-Einrichtung dann bereits ihrerseits an die Datenquelle(n) richten, bevor überhaupt weitere Anfragen von der Client-Einrichtung gestellt worden sind. Die Ergebnisse der Vorab-Anfragen kann die Server-Einrichtung dann (ggf. zusammen mit (Auszügen aus) dem Inhalt der jeweiligen Vorab-Anfragen) an die Client-Einrichtung senden. Die Client-Einrichtung speichert die Informationen zu den (Vorab-Anfragen und den) Anfrage-Ergebnisse lokal. Wenn die Anwendung des Nutzers weitere Anfragen stellt (bei denen es sich potentiell um die sukzessiven Anfragen zu der ersten Anfrage handelt), prüft die Client-Einrichtung – ggf. nach einer Wartezeit –, ob sie inzwischen Ergebnisse aus Vorab-Anfragen der Server-Einrichtung bekommen hat, die zu der von der Anwendung des Nutzers gestellten Anfrage passen (z.B. durch Vergleichen der angefragten Informationen, im Web etwa des URLs). Ist dies bereits geschehen, so leitet die Client-Einrichtung die Anfrage nicht weiter, sondern beantwortet die Anfrage selbst unter Verwendung der vorher von der Server-Einrichtung empfangenen Ergebnisse (leitet diese also potentiell unmodifiziert weiter). Liegt noch kein Ergebnis aus einer Vorab-Anfrage der Server-Einrichtung bei der Client-Einrichtung vor, so kann sie (a) noch einige Zeit warten, ob die angefragten Informationen noch von der Server-Einrichtung geliefert werden, (b) eine Fehlermeldung oder anderen (selbst generierten) Inhalt zurückgeben oder (c) sofort oder nach einer Wartezeit (siehe a) die neue Anfrage an die Server-Einrichtung weiterleiten.
Wenn die Server-Einrichtung die sukzessiven Anfragen der Anwendung korrekt "vorhersagt", müssen in diesem Szenario keine weiteren Anfragen außer der ersten Anfrage in rückwärtiger Übertragungrichtung gesendet werden.
Beispiel: Zugriff auf einen Web-Server.
Ein Web-Browser stellt eine Anfrage nach einer Webseite. Die Client-Einrichtung leitet diese erste Anfrage weiter an die Server-Einrichtung und diese sendet sie wiederum an die Datenquelle. Die Antwort von der Datenquelle mit den Ergebnissen der ersten Anfrage wird von der Server-Einrichtung an die Client-Einrichtung und von letzterer an die Anwendung weitergeleitet. Außerdem analysiert die Server-Einrichtung das empfangene HMTL-Dokument auf eingebettete Objekte (etwa Bilder, Inhalte von Frames). Alle diese Objekte fragt die Server-Einrichtung parallel und/oder sequentiell bei der Datenquelle bzw. den Datenquellen an und leitet die Antworten auf diese Vorab-Anfragen ebenfalls an die Client-Einrichtung weiter. Die Antworten auf die Vorab-Anfragen werden ebenfalls auf weitere eingebettete Objekte analysiert und diese dann ebenfalls vorab angefragt, die Ergebnisse weitergeleitet usw. Die Client-Einrichtung speichert alle Ergebnisse der Vorab-Anfragen. Sobald die Anwendung (hier der Web-Browser) die Antwort auf die erste Anfrage erhält, interpretiert auch er diese und beginnt, sukzessive die eingebetteten Objekte anzufragen. Die Client-Einrichtung leitet diese Folge-Anfragen nicht weiter, sondern speichert sie zwischen und beantwortet sie, sobald sie die Ergebnisse der jeweiligen Vorab-Anfrage von der Server-Einrichtung bekommen hat.
Siehe auch DE 100 39 900 und deutsche Patentanmeldung 102 520 17.8.
V. Datenverschlüsselung:
Der gesamte Informationsaustausch zwischen Server-Einrichtung und Client-Einrichtung kann im wesentlichen verschlüsselt ablaufen. So wird vermieden, dass Dritte Zugang zu den ausgetauschten Informationen erlangen können.
Zur Verschlüsselung ist eine Identifikation und Authentisierung des Nutzers (z.B. auf Basis eines Nutzernamen und Kennwortes, auf Basis einer PIN oder auf Basis eines Schlüsselpaares (geheimer + öffentlicher Schlüssel) des Nutzers erforderlich.
Einige der heute im (z.B. im Web) gebräuchlichen Verschlüsselungsverfahren nutzen einen bidirektionalen Datenaustausch zwischen den beteiligten Systemen (hier: Client- und Server-Einrichtung), um einen oder beide Kommunikationspartner zu authentifizieren und einen gemeinsam Schlüssel für den anschließenden Informationsaustausch zu etablieren.
Um möglichst die rückwärtige Übertragungsrichtung möglichst wenig zu nutzen, sollte eine Authentisierung nur zu Beginn der Kommunikation zwischen Client- und Server-Einrichtung stattfinden. Ggf. kann diese nach (konfigurierbar) langer Zeit wiederholt werden. Aus dieser Phase ergibt sich die Identität der Client-Einrichtung (und die des Nutzers) und ein Authentifikationsmerkmal zur weiteren Nutzung für den Informationsaustausch.
Dieses Authentifikationsmerkmal kann dann verwendet werden, um der Client-Einrichtung einen Schlüssel zur Entschlüsselung der für den Nutzer bestimmten Nutzdaten mitzuteilen. Wenn dies in Richtung von der Server-Einrichtung zur Client-Einrichtung geschieht und keine Aushandlung stattfindet, sondern der Schlüssel einfach nur mitgeteilt wird (und für die Client-Einrichtung erkennbar wird, ab wann er anzuwenden ist), wird die rückwärtige Übertragungsrichtung nicht benötigt. Es muss "sichergestellt" werden, dass der Schlüssel von der Client-Einrichtung auch wirklich empfangen wird. Das ist praktisch durch Vorwärtsfehlerkorrektur (wie oben beschrieben) zu erzielen, z.B. einfach durch wiederholtes Senden.
Nach erfolgtem Schlüsselaustausch können Server- (und ggf. auch Client-Einrichtung) damit beginnen, die übertragenen Nutzdaten (und ggf. Steuerinformationen) mit dem neuen Schlüssel zu verschlüsseln.
Die Datenübertragung auf de Strecke von der Client-Einrichtung zum Heim-PC des Nutzers kann ebenfalls verschlüsselt sein, muss es aber nicht, falls hier die Abhörgefahr als gering bzw. nicht gegeben angesehen wird.
VI. Datenkomprimierung:
Nutzdaten können für die Übertragung vor allem von der Server- zur Client-Einrichtung (aber auch in umgekehrter Richtung) komprimiert werden, um möglichst wenig Übertragungskapazität zu nutzen.
Die Kompression erfolgt in der sendenden Einrichtung (z.B. in der Server-Einrichtung), die entsprechende Dekompression in der empfangenden (in diesem Fall in der Client-Einrichtung).
Die Kompression wird dynamisch während der Übertragung durch die jeweils sendende Einrichtung durchgeführt. Es ist denkbar, die Kompression in Abhängigkeit vom übertragenen Informationstyp (z.B. Datei-Typ, MIME-Typ usw.) und von der Anwendung (Dateizugriff, E-Mail, WWW) ein- oder auszuschalten.
Die Kommunikation mit der Datenquelle und mit der Anwendung auf dem Heim-PC erfolgt jeweils unkomprimiert.
Header Compression
Während die oben angesprochene Kompression nur auf die Nutzdaten abzielt, kann es wichtig sein, darüber hinaus auch Protokollinformationen zu komprimieren. Bei einer solchen Kompression spricht man auch von Header-Kompression, weil nicht die Nutzdaten, sondern die Header der übertragenen Pakete komprimiert werden.
Auch die Header-Kompression läuft zwischen der Client-Einrichtung und der Server-Einrichtung ab. Sie wird jedoch nicht auf der Basis allgemeingültiger Kompressionsverfahren (wie etwa Lempel-Ziv) realisiert (dazu sind die Header-Information im allgemeinen zu kurz), sondern wird vielmehr protokollspezifisch umgesetzt.
Das bedeutet konkret, dass für ein Protokoll oder (meistens) eine Kombination von Protokollen Header-Kompressionsverfahren entwickelt werden. Diese machen sich im allgemeinen zunutze, dass ein Großteil der Header-Informationen sich zwischen zwei aufeinanderfolgenden Paketen nicht ändert (z.B. bleiben die IP-Adressen oftmals gleich) oder auf eine vorhersagbare An und Weise ändert (z.B. erhöhen sich Sequenznummern oftmals um eins oder einen anderen konstanten Wert). Tatsächlich werden dann nicht die ganzen Header, sondern nur Abweichungen von vorhergesagten Werten übertragen. Bei Sender und Empfänger wird jeweils (z.B. pro Verbindung) ein Kontext aufgebaut, aus dem dann die restlichen Werte ergänzt werden.
Für Header-Kompression ist es demzufolge wichtig, dass Sender und Empfänger (also z.B. Server- und Client-Einrichtung) jeweils die gleiche Vorstellung über den aktuellen Zustand ihrer Kontexte haben, damit die Ergänzungen korrekt vorgenommen und die Pakete richtig rekonstruiert werden.
Wenn beide Übertragungsrichtungen gleichermaßen (oder zumindest mit gleicher Regelmäßigkeit) genutzt werden können, können sich Sender und Empfänger immer wieder abgleichen. Wird hingegen, wie für diese Efindung von zentraler Bedeutung, im wesentlichen unidirektional von der Server-Einrichtung zur Client-Einrichtung gesendet, so muss die Server-Einrichtung die Client-Einrichtung in regelmäßigen Abständen über die aktuellen Kompressionskontexte informieren. Die Client-Einrichtung muss in komprimierter Form empfangene Pakete aufbewahren. Dann kann sie bei einer Aktualisierung der Kontexte die Pakete ggf. erneut dekomprimieren, falls sie eine zuvor fehlerhafte Dekompression feststellt.
Im Rahmen einer solchen Kontext-Aktualisierung kann nicht nur der aktuelle Zustand des Kontext, sondern auch der von der letzten Übertragung übermittelt werden, um es dem Empfänger zu ermöglichen, evtl. Fehler nachträglich zu korrigieren und die potentiell fehlerhaften Pakete erneut zu dekomprimieren.
Offensichtlich ist es vorteilhaft, wenn ein solcher Kompressions-/Dekompressionsalgorithmus dafür Sorge tragen kann, dass ggf. fehlerhaft dekomprimierte Pakete als fehlerhaft erkannt und dann beim Empfänger nicht weiter verarbeitet werden.
Header-Kompression kann auf allen Ebenen eingesetzt werden, also u.a. für IP, UDP, TCP, ETCP, HTTP usw.
VII. Anmelden und Abmelden:
Ein wesentlicher Punkt für die Minimierung der Nutzung der rückwärtigen Übertragungsrichtung ist das Reduzieren des zur Anmeldung eines Nutzers erforderlichen Informationsaustauschs. Bei der regulären Einwahl in das Internet oder bei der Anmeldung für sonstige Dienste (inkl. Internet-über-Satellit, WLAN-Zugang in Hot-Spots usw.) ist die Authentisierung des Nutzers beim Anmelden für den Dienst. Aus der Anmeldung wird geschlossen, dass der Nutzer von nun an "online" verfügbar ist; ebenso werden bei Bedarf Informationen zur späteren Vergebührung der Nutzung des jeweiligen Dienstes abgeleitet. Die Anmeldeprozedur erfordert im allgemeinen mindestens einen Nachrichtenaustausch (während dessen auch Parameter für den Dienst, etwa die IP-Adresse, Kompressionsverfahren, Schlüssel zur Verschlüsselung der ausgetauschten Daten usw., ausgehandelt werden können. Die Abmeldeprozedur erfolgt ebenfalls durch einen Nachrichtenaustausch und/oder (im Falle von Wählver bindungen z.B. im ISDN/PSTN/Mobilfunknetz durch einfaches Auflegen) und/oder nach einem Timeout (wenn etwa für eine bestimmte Zeitspanne keine Informationen übertragen worden sind).
Zur Reduzierung der Nutzung des Rückkanal ist dessen Nutzung zum Zwecke der An- und Abmeldung zu minimieren.
Offensichtlich ist mindestens eine einmalige Anmeldung des Nutzers beim Dienstanbieter erforderlich. Diese kann entweder durch Nachrichtenaustausch über das Netz erfolgen und/oder durch eine vorherige Absprache (etwa über Telefon, durch Vertragsunterzeichnung, durch Kommunikation per Briefpost, per Fax usw.). Eine solche Anmeldung kann auch implizit über andere Dienstanbieter geschehen (etwa bei kostenpflichtigen Einwahlnummern, bei denen dann die Abrechnung über die Telefonrechnung erfolgt, aber sonst keine explizite Vertragsvereinbarung zwischen Dienstanbieter und -nutzer nötig ist.
Gerade bei kostenpflichtigen Diensten ist eine Form der Authentifikation des Nutzers erforderlich. Diese kann, wie eben bereits skizziert, auf der Basis einer expliziten Vereinbarung mit dem Dienstanbieter (im Rahmen der Erfindung dem Betreiber einer Server-Einrichtung) geschehen oder durch einen Dritten (etwa der DTAG im Falle der Nutzung von gebührenpflichtigen Telefonnummern) geschehen.
Die Anmeldung kann, nach initialer Bekanntmachung des Nutzers (wie oben skizziert) im einfachsten Fall durch ein beliebiges (Steuer-)Signal geschehen, dass den Nutzer (a) eindeutig identifiziert und (b) die Anmeldeabsicht enthält. Ein ähnliches Signal kann ebenso zum späteren Abmelden verwendet werden. Im Idealfall wird ein Signal verwendet, dass für den Nutzer keine Kosten verursacht, also die rückwärtige Übertragungsrichtung nicht in einer kostenpflichtigen Art und Weise nutzt.
Je nachdem, wieviel Informationen in einem derartigen Steuersignal transportiert werden können, ist neben der An- und Abmeldung auch der Austausch weiterer Parameter möglich. Reicht das Steuersignal hierzu nicht aus, muss in regelmäßigen oder unregelmäßigen Abständen ein Informationsaustausch unter Nutzung der rückwärtigen Übertragungsrichtung stattfinden. Dieser Austausch kann aber weitaus seltener sein (etwa einmal pro Tag oder einmal pro Woche) als das An- und Abmelden (z.B. mehrfach pro Tag oder Stunde).
Entscheidend ist, dass die in einem solchen Verfahren eingesetzten Server- und Client-Einrichtungen auch nach dem Abmelden Informationen über ihre Kommunikationsbeziehung halten, um diese beim Erhalt eines einfachen (Anmelde-)Steuersignals wieder aktivieren zu können – um sie beim Erhalt eines einfachen (Abmelde-)Steuersignals wieder deaktivieren zu können.
Es sind eine Reihe von Mechanismen für derart einfache Steuersignale denkbar. Bedingung ist, dass sie im Kontext des fraglichen Dienstes einen Nutzer identifizieren und die Absicht (anmelden oder abmelden) mitteilen können.
Hierzu kann beispielsweise das kurzzeitige Anrufen einer bestimmten Telefonnummer dienen (wobei die Gegenstelle den Anruf nicht annimmt, so dass keine Kosten entstehen). Die Identifikation des Nutzers kann aufgrund der Anruferkennung (Calling Party ID) erfolgen, das An- und Abmelden kann durch die angerufene Nummer (Called Party ID) signalisiert werden.
Entsprechende Formen lassen sich auch in anderen Netzen nutzen.
Diese Form der schnellen An- und Abmeldens lässt sich für viele der im folgenden skizzierten Verfahren verwenden.
VIII. Empfang/Bestätigung für Instant-Messages:
Instant Messages (Kurznachrichten) werden heute in Ergänzung zum Telefon und zu elektronischer Post (E-Mail) eingesetzt. Sie sind den aus dem GSM-Netz bekannten Kurznachrichten (Short Message Service, SMS) vergleichbar. Instant-Messages unterscheiden sich von E-Mail vor allem dadurch, dass sich nicht einfach nur in einer Mailbox abgelegt werden und dort auf den Abruf durch den Empfänger warten. Vielmehr machen Instant-Messages den Empfänger unmittelbar auf sich aufmerksam: sie werden sofort zugestellt und dem Empfänger auch sofort präsentiert. Durch eine Folge von ausgestauschten Instant-Messages lässt sich auch ein Dialog zwischen zwei oder mehr Personen realisieren.
Für die effektive Nutzung von Instant-Messages ist es offensichtlich wichtig, dass der Empfänger diese auch sofort empfangen kann – bzw. der Absender zu erkennen vermag, ob der Empfänger gerade empfangsbereit ist. Bei SMS und Mobiltelefonen ist dieser Mechanismus nur eingeschränkt verwirklicht, aber es wird davon ausgegangen, dass der Empfänger sein Mobiltelefon i.d.R. eingeschaltet haben wird. Sonst wird die Kurznachricht zwischengespeichert.
Bei der Nutzung von Kurznachrichten im Internet, zu dem die Nutzer eben nicht notwendigerweise permanent Zugang haben, ist es umso wichtiger, einem Absender mitzuteilen, welche der potentiellen Empfänger gerade "online" (d.h. prinzipiell empfangsbereit) sind, damit abgesandte Kurznachrichten diesen auch sofort erreichen. Wenn der Empfänger nicht "online" ist, wird dies angezeigt, und der Absender braucht ihm gar nicht erst eine solche Nachricht zu schreiben. Wenn der Empfänger "online" ist, wird dies ebenfalls dem Absender angezeigt, und dieser kann davon ausgehen, dass seine Kurznachricht sofort zugestellt wird. Die Anzeige, ob jemand aus einer bestimmten Personengruppe (Freunde, "Buddies") "online" ist, wird auch als Präsenz ("Presence", "personal presence") bezeichnet. Eine Liste von Bekannte mit Präsenzinformationen bezeichnet man auch als "Buddy List" (zumindest bei einem kommerziellen Anbieter). Neben dem binären "online"/"nicht online" können auch weitere Informationen angegeben werden: kurze Textmeldungen (z.B. "Bin beim Mittagessen") oder auch Details zur Erreichbarkeit ("telefoniere gerade", "bin in einer Besprechung", "bitte nicht stören" usw.) können autorisierten Interessenten mitgeteilt werden.
Verschiedene Interner-Dienst-Anbieter wie etwa MSN oder AOL bieten seit geraumer Zeit die Möglichkeit, sich permanent über die Präsenz seiner Mitarbeiter, Freunde, Bekannten usw. zu informieren und ihnen, wenn sie denn "online" sind, Kurzmitteilungen, zukommen zu lassen.
Für alle diese Verfahren ist es erforderlich, dass der Nutzer jeweils "online" ist, um seinen Status anzupassen und auch Kurznachrichten zu empfangen. Danit fallen potentiell Kosten für die Internet-Einwahl an.
Das oben unter VII. skizzierte Signal zum An- und Abmelden kann genau hier zum Einsatz kommen. Nutzer können sich durch ein solches Anmelden als "online" registrieren lassen und dann Instant-Messages empfangen. Die Instant-Messages werden nicht über den regulären Internet-Zugang, sondern über Satellit versendet. Der Empfänger wird benachrichtigt, sobald die Instant-Message angekommen ist. Ebenso werden, sobald der Nutzer angemeldet ist, die Statusinformationen über seine Freunde und Bekannten per Satellit verteilt.
Aufgrund der jeweils geringen Informationsmenge können die zu übertragenden Informationen problemlos mehrfach versendet oder nach den unter III. skizzierten Verfahren gegen Paketverluste geschützt werden.
IX. Mail-Forwarding/Mail-Notification-Forwarding:
E-Mail stellt weniger hohe Anforderungen an die sofortige Zustellung von Nachrichten als Instant-Messaging. Dennoch verlässt man sich heute i.a. darauf, dass E-Mail zeitnah zugestellt werden. Ebenso interessiert sich der potentielle Empfänger dafür, wann er neue E-Mail(s) erhalten hat. Da es kein asynchrones Benachrichtigungssystem wie bei Instant-Messaging gibt, muss der Nutzer (z.B. manuell oder automatisiert durch seinen E-Mail-Client) regelmäßig seine Mailbox (z.B. beim Internet-Service-Provider) abfragen. Für jede dieser Abfragen muss sich sich der Nutzer kurz in das Internet einwählen (so er über keine Standleitung verfügt), was wiederum Kommunikationskosten verursacht.
Daher wurde in verschiedenen Systemen ein Benachrichtigungsdienst realisiert, der kurze Benachrichtigungen über neue Mails via Satellit an die Nutzer verteilt ("You have got Mail"), die ggf. noch weitere Informationen (Anzahl der neuen Mails und/oder Absender und/oder Betreff usw.) enthalten können. In einer Erweiterung werden dann die gesamten E-Mails an die Nutzer ausgeliefert. Dies kann besonders bei grossen E-Mails (die sonst über potentiell langsame terrestrische Leitungen übertragen werden müssten) vorteilhaft sein.
Bei der Verteilung von E-Mails oder Benachrichtigungen über neue E-Mails weiß jedoch das Sendesystem i.a. nicht, wann der Rechner des Nutzers eingeschaltet und empfangsbereit ist. Damit besteht das Risiko, dass die vom Sender übertragenen Informationen ihren Empfänger gar nicht erst erreichen oder aber mehrfach übertragen werden müssen, um zum Empfänger zu gelangen. Gerade das Versendung von grossen E-Mails verschwendet hier teure Übertragungskapazität.
Dieser Dienst lässt sich unter Nutzung eines wie des unter VII. vorgestellten Signals verbessern. Eine derartige "kostenlose Anmeldung" des Nutzers gibt dem Sendesystem (der Server- Einrichtung) die Möglichkeit, E-Mails oder Benachrichtigungen nur dann zu versenden, wenn die Empfanssystem (die Client-Einrichtung) empfangsbereit ist.
Diese Information lässt sich darüber hinaus auch gewinnen, wenn der Nutzer gerade "online" ist.
Ergänzend kann ein weiteres Signal von der Client- zur Server-Einrichtung genutzt werden, um den Erhalt einer Nachricht zu bestätigen. Alternativ oder ergänzend kann eine Client-Einrichtung auch den Nichterhalt einer Nachricht signalisieren.
X. Abbonement-Zustellungen/gezielte Zustellungen allgemein:
Eine Reihe von (IP-basierten) Broadcast-Diensten werden heute angeboten, um Webseiten, Dateien, Ticker oder andere Daten (inkl. Audio/Video) an große Gruppen von Empfängern zu verteilen. Hierzu folgt die Übertragung meist einem (internen) Ablaufplan einer Server-Einrichtung, die vorab festgelegt oder dynamisch erstellt werden kann. Zu einem sol ermittelten Zeitpunkt wird dann eine Broadcast-Übertragung initiiert. Alle Client-Einrichtungen, die an dieser Broadcast-Gruppe interessiert und zu dem Zeitpunkt eingeschaltet und empfangsbereit sind, empfangen die per Broadcast versendeten Daten. Andere Client-Einrichtungen verpassen die "Ausstrahlung". Letzteres bedeutet, dass die Daten potentiell erneut übertragen werden müssen, falls die verbleibenden Client-Einrichtungen die Informationen auch noch erhalten sollen oder zumindest möglichst viele Client-Einrichtungen erreicht werden sollen.
Das Erreichen aller Empfänger ist besonders in (offenen oder geschlossenen) Benutzergruppen von Bedeutung, wenn die Server-Einrichtung über eine Liste aller intendierten Empfänger besitzt und (ggf. über spätere Rückmeldungen von den Client-Einrichtungen) prüfen kann, welche der Client-Einrichtungen die Informationen bereits erfolgreich empfangen haben – und welche Client-Einrichtungen die Informationen noch nicht erhalten haben.
Außerdem ist oftmals eine obere Grenze für die Verteilung angegeben, d.h. ein Ende-Zeitpunkt, bis zu dem die Informationen spätestens allen Empfängern vorliegen sollen.
In den vorstehend genannten Fällen muss die Server-Einrichung jeweils eine Entscheidung treffen, wann sie die Informationsverteilung per Broadcast anstoßen soll: für die initiale Übertragung wie auch für Wiederholungen. Diese Entscheidung kann im allgemeinem in Abhängigkeit von der Last des Servers und der (voraussichtlichen) Auslastung des Übertragungsmediums (so diese bekannt ist) getroffen werden. Insbesondere ist es aber wünschenswert, dass die Server-Einrichtung weiß, wann die Client-Einrichtungen empfangsbereit sind, insbesondere wenn es nur noch um Sendewiederholungen für eine oder einige wenige verbleibende Client-Einrichtungen geht.
Das oben skizzierte (kostenfreie) An- und Abmelden eines Nutzers (bzw. der entsprechenden Client-Einrichtung) über bestimmte Steuersignale lässt sich auch hier dafür nutzen, der Server-Einrichtung Hinweise zu geben. Sie kann nun, im Falle einer Benutzergruppe, an Hand der Liste der intendierten Empfänger und der Anmeldeinformationen überprüfen, wieviele und welche Client-Einrichtungen zu einem Zeitpunkt erreicht werden können und beispielsweise anhand eines konfigurierbaren Grenzwertes (z.B. absolut: "mindestens 10 Empfänger" oder relativ: "mindestens 25% der verbleibenden Empfänger") entscheiden, wann die erneute Übertragung beginnen soll. Die oben genannten und weitere Parameter können hier natürlich ebenso berücksichtigt werden, neben Server- und Netzlast insbesondere auch die verbleibende Zeit bis zum Ende-Zeitpunkt.
Hierbei können deterministische Werte berücksichtigt werden, wie beispielsweise:

1. Der Nutzer ist gerade "online".
2. Der Nutzer ist zwar nicht "online", hat sich aber über ein entsprechendes Steuersignal angemeldet.
3. Der Nutzer ist "offline".

Ebenso können heuristische Werte herangezogen werden, beispielsweise:

4. Der Nutzer war gerade "online".
5. Der Nutzer hat sich gerade erst über ein Steuersignal abgemeldet.
6. Normalerweise ist der Nutzer jetzt "online".
7. Normalerweise ist mindestens ein Teil der Benutzergruppe jetzt erreichbar.

Die Übertragung erfolgt auch hier in allen Fällen per Multicast (bzw. Broadcast), so dass auch Client-Einrichtungen profitieren können, die zwar empfangsbereit sind, aber ihre Empfangsbereitschaft nicht oder noch nicht mitgeteilt haben und/oder mitteilen konnten.
Diese Verfahren können auch im Zusammenhang mit E-Mail oder Instant-Messaging verwendet werden.
XI. Aggregieren von Client-Requests:
Wie oben beschrieben, können Client-Einrichtungen einerseits mitteilen, ob sie "online" oder zumindest empfangsbereit sind, und sie können unter Verwendung der oben skizzierten Mechanismen auch bestätigen, dass sie bestimmte Informationen erhalten haben bzw. dass sie diese nicht oder nur unvollständig erhalten haben.
Darüber hinaus können Client-Einrichtungen über den Rückkanal Anfragen nach bestimmten Informationen (z.B. Webseite, E-Mail-Abruf usw.) stellen. Die Server-Einrichtung kann eine solche Anfrage (ggf. nach Weiterleitung an z.B. einen Web-Server oder eine andere Informationsquelle) sofort beantworten; diese Antwort wird dann direkt an ausschließlich diese einen Client-Einrichtung übertragen.
Alternativ kann die Server-Einrichtung auch mehrere Anfragen sammeln und diese dann erst gemeinsam beantworten. Die Kriterien zum Sammeln können konfigurierbar sein und beispielsweise folgende Merkmale umfassen: minimale Anzahl der Anfragen und/oder maximale Wartezeit für die erste Anfrage (ggf. in Abhängigkeit von der Zahl der Anfragen), und/oder angefragte Information (z.B. Ressource, Webseite, Datei usw.).
Nachdem so die Anfragen von mehreren Client-Einrichtungen gesammelt worden sind, kann die Server-Einrichtung die Anfragen alle gemeinsam beantworten. Die Antwort wird dann nicht individuell an jede Client-Einrichtung versendet, sondern statt dessen per Multicas/Broadcast an alle Client-Einrichtungen, die die Anfrage gestellt haben. Hierzu kann entweder eine feste Adresse genutzt werden, es kann eine Adresse in Abhängigkeit von der ansgefragten Information abgeleitet werden (etwa unter Verwendung eines aus dem gesuchten URL einer Webseite generierter Hash-Wert), und/oder es kann eine dynamische Adresse generiert und den anfragenden Client-Einrichtungen explizit mitgeteilt werden.
Optional kann dabei, etwa durch Nutzung deterministischer Multicast-Adressen, auch Client-Einrichtungen der Empfang ermöglicht werden, die in der Anfrage-Sammlung noch gar nicht auftauchen (weil sie ihre Anfrage noch gar nicht gestellt hatten). Diese Client-Einrichtungen könnten vor dem Versenden einer Abfrage sich für den Empfang von Daten auf einer deterministisch generierten Adresse vorbereiten (etwa einer entsprechenden Multicast-Gruppe beitreten). Die dann dort empfangenen Informationen werden von der Client-Einrichtungen einfach zunächst gespeichert und dann mit den eigenen Anfragen verglichen. Die jeweils zu einer Anfrage passenden Informationen werden dann an die jeweils anfragende Anwendung (z.B. den Web-Browser) weitergegeben.
Client-Einrichtungen können auch ohne explizite eigene Anfrage Informationen aus Antworten auf andere Anfragen empfangen und diese Speichern. Dann führen sie eine Form von Caching durch. Die so empfangenen Informationen werden lokal gespeichert. Stellt später eine Anwendung eine Anfrage nach einer vorab empfangenen und im Cache gespeicherten Information an die Client-Einrichtung, kann diese die Anfrage unmittelbar aus dem eigenen Cache beantworten.
Sowohl die Aggregation von Anfragen als auch das Caching können für alle Nutzer oder auch für bzw. innerhalb bestimmter (abgegrenzter) Nutzergruppen realisiert werden, bzw. je nach Art der angefragten Information auch in Kombination beider Varianten.
Bei der Verteilung von Antworten an mehrere Empfänger zur Optimierung der Nutzung der primären Übertragungsrichtung ist es wesentlich, dass die Server-Einrichtung nur solche Informationen allgemein (für alle bzw. verfügbar macht, die auch keine "Geheimnisse" des anfragenden Nutzers verraten (etwa Kontoinformationen, Kreditkartendaten, Bestellungen usw.). Ggf. ist also in der Server-Einrichtung z.B. je nach Art der angefragten Information und/oder des verwendeten Protokolls (z.B. TLS vs. TCP) und/oder anderer Parameter zu entscheiden, welche Anfragen/Informationen sich für Aggregation und/oder Caching eignen (und für welche Nutzergruppen) und welche Informationen ausschließlich dem Anfragenden über seine Client-Einrichtung zugänglich gemacht werden sollen.
Wenn sich Anfragen für die Aggregation eignen und/oder eine Aggregation durchgeführt wird, kann die Server-Einrichtung und/oder die Client-Einrichtung potentiell eine Mitteilung an die Anwendungen geben, wann (bzw. wann spätestens) Anfrage beantwortet wird. Diese Information könnte den Anwendungen auf geeignete Art und Weise (einem Web-Browser beispielsweise in Form einer Webseite) angezeigt werden. Eine solche Anzeige kann auch graphisch aufbereitet und/oder animiert sein (z.B. als Countdown die noch verbleibende (ggf. maximale) Wartezeit oder als "Progress Bar", wie er vom Download oder von der Installation von Windows-Anwendungen bekannt ist).
XII. Inverse Multiplexing:
In den bisherigen Beschreibungen ist im allgemeinen davon ausgegangen worden, dass die primäre Übertragungsrichtung (in Form der Übertragungsmediums 3 in 1) zur Übermittlung von Informationen von der Server-Einrichtung zur Client-Einrichtung genutzt wird – vor allem, weil es die Zielsetzung dieser Erfindung ist, die rückwärtige Übertragungsrichtung möglichst wenig zu nutzen.
Ist jedoch ein Nutzer "online", steht also die rückwärtige Übertragungsrichtung (in Form des Übertragungsmediums 4 in 1) ohnehin zur Verfügung, so ist diese in vielen Fällen auch bidirektional ausgebildet und kann zur bidirektionalen Informationsübertragung genutzt werden.
Dann kann es sinnvoll sein, Daten in der primären Übertragungsrichtung nicht nur über (3), sondern auch auch über (4) zu senden, um die zur Verfügung stehende Übertragungskapazität maximal auszunutzen.
Vor dem Hintergrund der vorliegenden Erfindung ist jedoch Folgendes wesentlich zu berücksichtigen. Bei den meisten kostenpflichtigen Einwahldiensten werden die Zugangssysteme (separate Router oder Software auf PCs) im allgemeinen so konfiguriert, dass sie eine Verbindung zum Internet (z.B. eine Telefonverbindung) automatisch abgebaut wird, wenn für eine (meist konfigurierbare oder automatisch bestimmte) Zeitdauer keine Daten mehr ausgetauscht worden sind. Dies geschieht, um Kosten zu sparen. Folglich muss eine Client-Einrichtung der Server-Einrichtung z.B. über ein Steuersignal (oder eine dauerhafte Konfiguration durch den Nutzer) mitteilen, ob sie eine Nutzung des Rückkanals auch in der primären Übertragungsrichtung (und damit einer potentiell längeren Nutzung des Rückkanals) wünschen.
Die Server-Einrichtung kann dann z.B. an Hand dieses Steuersignals entscheiden, ob sie den Rückkanal nutzen will oder nicht.
XIII. Abstraktion von IP-Adressen:
In den heutigen Internet-Zugangsdiensten vergeben die Internet-Service-Provider (ISPs) statische Adresse im allgemeinen nur an Geschäftskunden mit Standleitungen. Alle Anwender, die nicht über eine Standleitung zum ISP verfügen – hierunter fallen alle privaten Nutzer und Heimbüros –, erhalten im allgemeinen bei der "Einwahl" bzw. den Aufbau einer "Verbindung" zum Internet (hierzu zählen Telefon-/PSTN- und ISDN-Leitungen, DSL-Zugänge, Kabelanschlüsse u.a.) eine dynamische IP-Adresse zugewiesen. Diese wird sich im allgemeinen bei jeder Einwahl ändern.
Die meisten heutigen Internet-Anwendungen sind jedoch darauf ausgelegt, für die Dauer einer Kommunikationsbeziehung mit einer konstanten IP-Adresse zu arbeiten. Ändert sich die IP-Adresse, werden beispielsweise TCP-Verbindungen abgebrochen usw.
In einer Umgebung, in der ein Rückkanal bzw. eine rückwärtige Übertragungsrichtung möglichst wenig genutzt werden soll, wird sich also die IP-Adresse potentiell mehrfach ändern, während der Nutzer auf Ressourcen und Dienste im Internet zugreift.
Die Server-Einrichtung (etwa eines Diensterbringers beispielsweise eines Satellitendienstes) muss aber in der Lage sein, die Client-Einrichtung auch über mehrere Einwahlvorgänge mit potentiell wechselnden IP-Adressen hinweg zu identifizieren. Hierzu wird ein eigenständiger Bezeichner auf der Anwendungsebene eingeführt, der (z.B. nach initialer Authentisierung des Nutzers) für eine Kommunikationsbeziehung zwischen Client- und Server-Einrichtung verwendet wird. Dieser Bezeichner kann beispielsweise eine von der Server-Einrichtung zugewiesene IP-Multicast-Adresse, ein URL, eine beliege Ziffern- oder Zeichenkette sein.
Mit einem solchen Bezeichner kann sich ein Nutzer effizient ausweisen, sobald er den Rückkanal nach einem vorübergehenden Abbau erneut aufbaut und damit auch eine Assoziation zu der ggf. neu zugewiesenen IP-Adresse herstellen.
Durch einem solchen Bezeichner können auch Informationen gezielt an die Client-Einrichtung des Nutzers adressiert werden, wenn die Informationen beispielsweise per Satellit an diese gesendet werden.
Es kann je nach Ausgestaltung des Systems von Vorteil sein, mehrere Bezeichner pro Nutzer (bzw. Client-Einrichtung) zuzulassen. Solche Bezeichner können dann beispielsweise auch aus einem der verwendeten Kommunikationsnetze abgeleitet werden. Ein Beispiel hierfür wird im folgende Abschnitt XIV. beschrieben.
XIV. Zielrufnummern als Information:
Gerade wenn, wie heute weit verbreitet, das ISDN-, PSTN- oder GSM-Netz zur Einwahl ins Internet verwendet wird (bzw. eine solche Leitung unabhängig vom Internet-Zugang zur Verfügung steht, wie etwa bei DSL), bietet es sich an die von diesen Netzen unterstützten Rufnummern implizit zur Übermittlung von Informationen zu nutzen.
Zum Wählen der Rufnummer kann eine beliebige Telekommunikationseinrichtung, beispielsweise ein Modem, eine ISDN-Karte oder dergleichen, genutzt werden.
Die Rufnummern können dabei verschiedene Aufgaben wahrnehmen. Unter anderem sind folgende Anwendungsgebiete vorgesehen:

1. Die Rufnummer des Anrufenden (auch als Anruferkennung bezeichnet) steht zumindest bei Anrufen im Inland und abgeschalteter Rufnummernunterdrückung (also "Calling Line Identification Presentation", CLIP) dem Angerufenen zur Verfügung. Der Angerufene – z.B. ein mit der Server-Einrichtung über einen Kommunikationskanal oder direkt in Verbindung stehendes System – kann auf der Basis dieser Informationen eine Server-Einrichtung über eingehende Anrufe bestimmter Benutzer informieren. Dafür werden eine oder mehrere Rufnummern pro Nutzer (bzw. pro Client-Einrichtung) im System gespeichert. Die Rufnummer des Anrufenden stellt somit eine Authentisierung des Anrufers sicher, insbesondere weil das Telefonnetz gemeinhin als zuverlässige Quelle für die Anruferkennung gilt. Damit ist insbesondere eine Authentisierung ohne weiteren Informationsaustausch möglich, also eine kostenfreie Authentisierung.
2. Auf der Seite der Server-Einrichtung können mehrere Rufnummern zum Anrufen vorgesehen sein. Durch Auswahl der angerufenen Nummer lassen sich damit (in Verbindung mit der Anruferkennung) zusätzliche Informationen – kostenfrei (falls der Angerufene den Anruf ablehnt bzw. ihn nicht annimmt) – direkt oder indirekt zur Server-Einrichtung übermitteln. Beispielsweise kann eine Rufnummer für das Anmelden vorgesehen sein, eine andere für das Abmelden.

Damit lassen sich dann beispielsweise drei Zustände signalisieren:

– eine Client-Einrichtung ist "online" (wenn eine aktive Verbindung zum Internet besteht),
– eine Client-Einrichtung ist empfangsbereit aber nicht "online" (= "semi-online") (wenn zwar keine aktive Verbindung zum Internet besteht, aber sie über ein Steuersignal ihre Empfangsbereitschaft signalisiert hat,
– eine Client-Einrichtung ist "offline" (wenn keine aktive Verbindung zum Internet besteht und sie über ein Steuersignal signalisiert hat, dass sie nicht empfangsbereit ist,
– der Status einer Client-Einrichtung ist "unbekannt" (wenn keine aktive Verbindung zum Internet besteht und sie nach dem letzten Abbau einer solchen kein Steuersignal über ihren aktuellen Zustand gesendet hat).

3. Es lassen sich weitere anrufbare Nummern (oder Nummernerweiterungen) vorsehen, über die sich neben obigen Steuersignalen auch z.B. positive/negativer Bestätigungen oder weitere Zusatzinformationen getunnelt im eingehenden Anruf zur Auswertung durch die Server-Einrichtung übertragen lassen.
4. Es lassen sich, wenn das verwendete Kommunikationsmedium dies zulässt, auch weitere Informationen als Bestandteil eines Verbindungsaufbaus übermitteln, die dann serverseitig ausgewertet werden können.

Telefonnummern können auch grundsätzlich zur Authentisierung der Nutzer beitragen, wenn der Satellitendienstanbieter selbst einen Einwahlknoten bereithält und somit Zugriff auf ebendiese Informationen besitzt.
Analog zu Telefonanrufen können auch Rufnummern von z.B. SMS-Nachrichten aus dem Mobilfunknetz (oder auch aus dem Festnetz) genutzt werden: Anruferkennungen zur Authentisierung, angerufene Rufnummern zur Dienstewauswahl. Der Nachrichteninhalt kann in solchen Fällen weitere Informationen enthalten, z.B. den URL, der über ein Satelliten zu einem Empfänger gesendet werden soll.
XV. Datenablage auf Empfangsseite/Nutzung von extenem Speicher:
In Kombination mit einem der anderen Verfahren und Anordnungen, aber auch unabhängig von den anderen in diesem Dokument offenbarten Verfahren und Anordnungen, ist es oftmals sinnvoll, empfangene Daten oder Dateien, die zwischengespeichert oder ausgeliefert werden sollen, nicht lokal auf dem Empfangsgerät abzulegen bzw. nicht lokal auf dem Gerät abzulegen, auf dem die eingesetzte Empfangssoftware installiert und ausgeführt wird. Also nicht notwendiger weise direkt auf der Client-Einrichturtg.
Dies erlaubt unter anderem den Einsatz von Empfangsgeräten, die nur einen relativ kleinen internen Speicher und beispielsweise keine Festplatte oder nur einen kleinen zur Verfügung stehenden Festplattenbereich haben.
Übliche Empfangssoftware nutzt vorwiegend den internen Speicher des Empfangsgerätes (beispielsweise RAM und/oder Festplatte) zum Empfangen von üblicherweise in einzelne Datenpakete oder einen Bytestrom aufgeteilte Informationseinheiten (beispielsweise Dateien).
Dabei setzt die Empfangssoftware eine Informationseinheit (wie beispielsweise eine Datei) wieder zusammen. Dies kann, um einige Beispiele zu nennen, bei fehlerfreiem Empfang zum Beispiel unmittelbar nach dem einmaligen Senden der Fall sein; nach dem Auswerten von Forward Error Correction Paketen; oder auch erst nach einem mehrfachen Aussenden durch die Server-Einrichtung, wie bei einer Caroussel-artigen Übertragung).
Die so zusammengesetzten Informationseinheiten (beispielsweise Dateien) sollen nun oftmals wieder als Datei abgespeichert werden. Eine übliche Empfangssoftware würde diese Dateien lokal beispielsweise auf der Festplatte des lokalen Rechners ablegen oder zumindest zwischen speichern.
Für Empfangsgeräte mit nur kleinem internen Speicher gibt es die Möglichkeit dieses lokalen Abspeicherns nicht oder nur sehr eingeschränkt für einen Teil der empfangenen Informationseinheiten, Datenpakete oder Byteströme.
Daher bietet diese Erfindung die Möglichkeit zum Nutzen von Speicherbereichen (Externer Speicher) ausserhalb des Rechners, auf dem die Empfangssoftware eingesetzt wird.
Dieser Externe Speicher kann unter anderem eingesetzt werden zum:

1. Speichern von Teilen von Informationseinheiten a) unter anderem, wenn eine Informationseinheit wegen noch fehlender Teile noch nicht vollständig ist b) wenn mehrere Informationseinheiten zunächst vollständig empfangen werden sollen, bevor sie für die nutzenden Systeme sichtbar abgespeichert werden sollen.
2. Das Ablegen von vollständigen Informationseinheiten (oder mehreren Informationseinheiten) für die nutzenden Systeme. Also beispielsweise das Ablegen dieser Informationseinheiten beispielsweise als Bild-Dateien oder Video-Dateien für eine sich automatisch oder manuell anschließende Darstellung der Dateiinhalte durch weiterführende (nutzende) Systeme oder Funktionen der Empfangssoftware bzw. zusätzlicher Software auf dem Empfangsrechner. Anstelle einer Darstellung können aber auch ganz andere Funktionen durch die sich anschließenden (nutzenden) Systeme ausgeführt werden. Dies könnte beispielsweise das Archivieren und/oder Weiterverteilen der empfangenen Dateien umfassen. Die Ausgestaltung bzw. der Zugriff auf den externen Speicher kann vielfältig ausgeführt werden.

Bei dem externen Speicher kann es sich beispielsweise um RAM oder eine Festplatte auf einem anderen Rechner handeln, der über eine Netzwerkverbindung (LAN, WAN, ...) direkt oder indirekt mit dem Empfangsrechner verbunden ist.
Zum Zugriff auf diesen externen Speicher können unter anderem Standardprotokolle und Verfahren eingesetzt werden. Diese Alternative bietet den Vorteil, dass direkt auf dem externen Rechner (dem Rechner mit dem genutzten externen Speicher) eventuell keine zusätzliche oder zumindest keine spezielle Software zum Zugriff auf den externen Speicher installiert werden müßte. Hier könnte stattdessen eine potentiell bereits vorhandene Standardsoftware genutzt werden, die über entsprechende Konfigurationen (beispielsweise Benutzernamen, Passwörter zum Zugriffsschutz) eine Nutzung des externen Speichers durch den Empfangsrechner und die Empfangssoftware ermöglicht.
Als Standardprotokolle zum Zugriff auf den externen Rechner kann beispielsweise FTP (File Transfer Protokoll) eingesetzt werden. In diesem Fall wäre auf dem externen Rechner beispielsweise ein handelsüblicher und oftmals bereits mit normalen Betriebssystemem mitgelieferter FTP-Server installiert. Die Empfangssoftware greift in diesem Fall über eine oder mehrere parallele FTP Verbindungen auf den FTP-Server und den dortigen externen Speicher zu.
Beispielsweise bei Nutzung des Externen Speichers für den oben beschriebenen Fall 2. würden beispielsweise über die FTP-Verbindungen) vollständige Informationseinheiten (beispielsweise Dateien) auf den externen Rechner geschrieben werden.
Als weiteres Beispiel könnte auch für die unter 1. a) und b) beschriebenen Fälle der externe Speicher über FTP angesprochen werden, um beispielsweise, durch die nutzenden Anwendungen zunächst potentiell ungenutzt, Teile von Informationseinheiten oder noch nicht zur weiteren Nutzung vorgesehene vollständige Informationseinheiten zwischenzuspeichern.
Zur Steigerung des Durchsatzes (beispielsweise wegen der Menge der zu schreibenden Daten oder auch wegen einer ggf. hohen Anzahl an einzelnen zu behandelnden Informationseinheiten) kann es dabei nützlich oder sogar erforderlich sein, mehrere FTP Verbindungen parallel zu nutzen.
Dabei kann die Empfangssoftware bei entsprechender, von ihr vorgesehener Funktionalität, auch über FTP Verbindungen das Löschen oder Umbenennen von Informationseinheiten oder allgemeiner beispielsweise zur Realisierung des im externen Speicher gehaltenen Informationsumfangs also der Menge der Informationseinheiten oder Teilen von Informationsinhalten, beinhalten.
Bei Realisierung des beschriebenen Szenarios 1 a) und b) mit einem externen Speicher – also unter anderem dem Ablegen von Teilen (Fragmenten) von Informationseinheiten oder ganzen Informationseinheiten, die den nutzenden Anwendungen noch nicht zur Verfügung ge stellt werden sollen, kann es sich anbieten größere (größer als z.B. einzelne Paket) oder kleinere (kleiner als z.B. mehrere GByte große Informationseinheiten) Container-Dateien im externen Speicher anzulegen und zu verwalten.
Diese Container-Dateien bieten als Beispiel den Vorteil, dass eine Container-Datei ggf. viele kleinere Informationseinheiten umfasst und daher im Dateisystem auf dem externen Rechner nicht viele kleine einzelne Dateien angelegt werden müssen. Das Anlegen vieler kleiner Dateien ist, u.a. je nach verwendetem Rechner und Betriebssystem oft mit relativ viel Verwaltungs-/Speicheroverhead verbunden, so dass beispielsweise nur eine bestimmte Anzahl von Dateien insgesamt oder aufgrund der Systemperformance nur eine bestimmte Anzahl von Dateien beispielsweise pro Sekunde neu angelegt und/oder gelesen und/oder gelöscht werden können.
Der Vorteil von Container-Dateien gegenüber einzelnen Dateien auf den externen Rechnern wird gegebenfalls noch größer, wenn innerhalb der Container Dateien Fragmente von Informationseinheiten gespeichert werden (beispielsweise im Szenario 1 a)).
Zur Verwaltung der Container-Dateien werden oftmals Verwaltungsinformationen (quasi Inhaltsverzeichnisse) benötigt. Diese Informationen können gemeinsam mit den Informationeinheiten bzw. Fragmenten in die Container-Dateien geschrieben werden. Zum schnelleren Zugriff bietet sich unter anderen aber auch zusätzlich oder alternativ ein von den einzelnen Informationseinheiten bzw. Fragmenten losgelöster Verwaltungsinformationsbereich an. Dieser kann beispielsweise am Beginn von Container-Dateien und/oder in ausgewählten (Master/zentralen) Container-Dateien gespeichert werden. Alternativ bzw. zusätzlich könnten diese Verwaltungsinformationen oder ein Teil davon (ggf. als Cache) aber auch auf dem Empfangsrechner selbst und ggf. sogar im RAM bzw. innerhalb des Speicherbereiches der Empfangssoftware gespeichert werden, um beispielsweise besonders schnell oder beispielsweise ohne extra Zugriff auf den externen Rechner auf diese Informationen zugreifen zu können.
Wenn Fragmente in Container-Dateien gespeichert werden, kann es gegebenenfalls zu sehr verteilten Zugriffen auf Container Dateien kommen. Dies könnte beispielsweise der Fall sein, wenn eine Informationseinheit komplett empfangen wurde, die Informationen aber verteilt und nicht notwendiger Weise in der richtigen Reihenfolge in mehreren Container-Dateien gespeichert sind. In diesem Fall kann es beispielsweise zur Performancesteigerung nützlich sein, Daten aus mehreren Container-Dateien zu lesen. Dieses Lesen kann dabei beispielsweise parallel über mehrere FTP-Verbindungen erfolgen. Dabei könnte beispielsweise jeweils eine FTP-Verbindung zum Lesen von Daten aus einer Container-Datei genutzt werden – es sind aber auch andere Aufteilung wie das abwechselnde Lesen von Daten mehrerer Container-Dateien über eine FTP-Verbindung möglich.
Eine weitere Optiomierung der Performance und/oder des auf dem Empfangsgerät genutzten Speicherplatzes kann sich durch das parallel zum Lesen erfolgende Schreiben der aus Container-Dateien gelesen Daten ergeben. Dies könnte beispielsweise beim Zusammensetzen einer Informationsdatei aus Fragmenten aus einer oder mehreren Container-Dateien sinnvoll sein. Dabei wird beispielsweise aus einer oder mehreren FTP Verbindungen als einer oder mehreren Container-Dateien gelesen und die so zusammengesetzte Informationseinheit über eine weitere FTP-Verbindung parallel in den externen Speicher geschrieben – also ohne zwanghaft (insbesondere sehr große Informationseinheiten) auch nur kurzzeitig vollständig im Empfangsgerät zwischenspeichern zu müssen.
Das parallele Lesen und Schreiben aus einer oder mehreren Container-Dateien kann zugleich auch zu einem ggf. notwendigen Defragmentieren von Container-Dateien genutzt werden. Dabei wird beispielsweise aus einer oder mehreren Container-Dateien gelesen und mit den gelesenen Informationen zugleich eine neue Container-Datei erstellt und in den externen Speicher geschrieben. Dabei kann diese neue Container-Datei auch eine Container-Datei sein, die eine bestehende ersetzt.
Die Anordnung und Mittel zwischen dem Empfangsrechner und dem externen Rechner sowie die verwendeten Verfahren sind hier beispielhaft für einen Zugriff über das FTP-Protokoll beschrieben. Es können als Bestandteil dieser Erfindung aber auch andere Protokolle und Zugriffsmethoden Anwendung finden. Dazu gehören insbesondere auch Standardprotokolle wie HTTP, NFS (Network File System), Windows File-System Shares (beispielsweise basierend auf SMB Small Message Blocks und/oder realisiert durch SAMBA Filesystemfreigaben beispielsweise auf Unix-basierten externen Rechnern).
Eine weitere Optimierung laesst sich erzielen, wenn in der Client-Einrichtung ein Caching für eine oder mehrere Container-Dateien oder von Teilen einer oder mehrerer Container-Dateien erfolgt. Die Größe des Caches kann dabei dynamisch oder konfigurierbar an die Menge des für dieses Zweck bzw. ingesamt frei zur Verfügung stehenden Speichers der Client-Einrichtung angepasst werden.
Die Nutzung des externen Speichers lässt sich dabei in ganz unterschiedlichen Empfangssystemen und Empfangssoftware einsetzen. Dazu gehört als Beispiel auch das Übertragen und/oder Zwischenspeichern von Dateien über IP Multicast, E-Mails, E-Mail Notifications, vorab-übertragene Webseiten, vorausschauender Übertragung allgemein oder von Webseiten im Speziellen, usw.
XVII. Verteiltes Caching bei Client-Einrichtungen:
Die unter XV. beschriebene Szenarien gehen davon aus, daß sich ein oder ggf, mehrere Systeme zur Speicherung von Informationen einer Client-Einrichtung als externer Speicher zuordnen lassen. Dies erfordert jedoch immer das Vorhandensein eines solchen leistungsfähigen externen Systems.
Eine Weiterentwicklung der Erfindung geht davon aus, dass nicht nur ein oder mehrere dedizierte Systeme als externe Speicher zu verwenden. Insbesondere stehen solche Systeme bei mobilen Anwendungen (etwa mit PDA, Mobiltelefonen aber auch Laptops) im allgemeinen gar nicht zur Verfügung.
Dennoch ist ein mobiler Nutzer darauf angewiesen, per Multicast/Broadcast verteilte Informationen abzuspeichern, um sie bei Bedarf verfügbar zu haben. Dabei treten mindestens die folgenden praktischen Probleme auf, die durch die beschriebene Erfindung gelöst werden:

1. Das per Broadcast verteilte (und für den jeweiligen Nutzer interessante) Informationsvolumen übersteigt deutlich die Speicherkapazität seines Endgerätes (das u.a. die Client-Einrichtung enthält). Damit können nicht alle relevanten Informationen nach Empfang auch gespeichert werden, sondern es muss eine Auswahl stattfinden. Diese Auswahl kann sich an den Präferenzen des Nutzer, an seinem Verhalten usw. orientieren und automatisch oder manuell vorgenommen werden.
2. Die Verteilung von Informationen per Broadcast findet im allgemeinen nicht kontinuierlich, sondern nur in bestimmten (potentiell aber nicht zwingend vordefinierten) Zeiträumen statt (etwa alle 20 Minuten für 2 Minutes, täglich um 13 Uhr usw.). Damit muss ein Interessent potentiell geraume Zeit warten, bevor die von ihm gewünschten Informationen (erneut) verteilt werden, um Zugang zu den Informationen zu erhalten. Die Wartezeit kann entweder dadurch begründet sein, dass die Informationen vorher noch nicht gesendet wurden und/oder überhaupt zur Verfügung standen (diesem Fall lässt sich außer einer interaktiven Anforderung bei einer Server-Einrichtung kaum begegnen); oder sie kann daraus resultieren, dass der Nutzer (bzw. dessen Client-Einrichtung mindestens Teile des Informationsübertragung verpasst hat).
3. Ein Nutzer kann eine bzw. einen Teil einer Informationsübertragung beispielsweise verpassen, wenn sein Endgerät zu mindestens einem Zeitpunkt während der Übertragung nicht eingeschaltet ist und/oder sich nicht im Empfangsbereich des Senders befindet und/oder Übertragungsstörungen (etwa Paketverluste) vorliegen (die auch nicht durch FEC-Verfahren ausgeglichen werden konnten) und/oder das Endgerät nicht genügend Speicherkapasität (freie oder insgesamt) zum Zeitpunkt der Übertragung aufwies. Weitere Gründe sind möglich.

Als Ergebnis einer verpassten oder unvollständigen Übertragung kann das Endgerät die Informationen nicht oder nicht vollständig darstellen. Nach dem Stand der Technik müsste der Nutzer auf eine erneute Übertragung warten oder eine solche durch eine explizite Anfrage an einen Cache und/oder eine Server-Einrichtung oder die Datenquelle initiieren. Dazu ist es aber Voraussetzung, dass die Client-Einrichtung in der Lage ist, Anfragen an die Server-Einrichtung oder eines der anderen eben genannten Systeme zu stellen. Diese Voraussetzung kann jedoch nicht gegeben sein, wenn keine rückwärtige Übertragungsrichtung (also kein Rückkanal) ausgebildet ist oder dieser zu einem bestimmten Zeitpunkt nicht, nur selten oder eingeschränkt zur Verfügung steht (etwa wenn nicht zu jedem Zeitpunkt gesendet werden kann, wenn erst manuell Verbindungen etwa zum Mobiltelefon oder einer anderen Kommunikationseinrichtung hergestellt werden müssen, eine Satellitenrückkanal bereitgestellt werden müsste usw). Oder aber die Voraussetzung kann nur zu hohen Kosten gegeben sein, etwa wenn der Rückkanal über ein (teures) Mobiltelefon (über GPRS, UMTS, GSM) hergestellt werden müsste.
Darüber hinaus kann es auch seitens der Server-Einrichtung unerwünscht sein, explizite Anfragen von Client-Einrichtungen (beliebig) zuzulassen. Server-Einrichtungen können beispielsweise nur Anfragen nach bestimmten Ressourcen und/oder zu bestimmten Zeiten und/oder von bestimmten Nutzern/Nutzergruppen und/oder von bestimmten Orten aus usw. zulassen wollen. Gründe für derartige Beschränkungen können in der Vermeidung von Überlastungen der Server-Einrichtungen und/oder der Übertragungswege (z.B. die primäre Übertragungsrichtung) und/oder der Tarifgestaltung für die Nutzer und/oder die rechtlichen Rahmenbedingungen des Einsatzes usw. darstellen.
Die vorliegende Erfindung sieht eine Anordnung vor, die es gestattet gesuchte Informationen von verschiedenen Client-Einrichtungen über lokale Kommunikationsnetze zwischen den Client-Einrichtungen zu erfragen, ohne dabei auf einen Rückkanal zu einem oder mehreren dedizierten Caches, zu einer Server-Einrichtung oder zu einer Quelle angewiesen zu sein.
2 stellt eine Anordnung dar, wie sie dem Stand der Technik entspricht. Client-Einrichtungen empfangen Informationen per Broadcast von einer Server-Einrichtung und speichern diese für den späteren Abruf durch den Nutzer. Es besteht (zu dem gezeigten Zeitpunkt oder grundsätzlich) kein Rückkanal zur Server-Einrichtung – und damit hat eine Client-Einrichtung auch keine Möglichkeit, Informationen nachträglich anzufordern. In diesem konkreten Beispiel werden die mobilen Empfänger über terrestrischen Digitalfunk (DVB-T) mit Informationen versorgt. Es sind aber auch andere Netze wie DVB-S, GSM, UMTS, GPRS, DVB-C, WLAN; Bluetooth, Infrarot (IrDA), Richtfunk oder andere IP-basierte und nicht IP-basierte Netztechnologien einzeln oder in Kombination denkbar.
3 zeigt eine erfindungsgemäße Anordnung, in der die Client-Einrichtungen der Empfänger nicht nur Informationen von den Server-Einrichtungen empfangen können, sondern gleichzeitig miteinander über dasselbe bzw. dieselben Netze oder ein anderes Netz kommunizieren können. Als zweites Netz kommen alle der oben genannten Netze in Frage. Das erste Netz (das Distributionsnetz) und das zweite Netz (das lokale Koordinationsnetz) können also auf denselben oder auf unterschiedlichen Netztechnologien aufgebaut sein.
Da die erfindungsgemäßen Client-Einrichtungen in der erfindungsgemäßen Anordnung die Möglichkeit haben, direkt miteinander zu kommunizieren, können sie untereinander Informationen bereitstellen.
Der Grundgedanke ist, dass (wenn beispielsweise genügend Client-Einrichtungen im Einsatz sind und/oder zusätzliche Client-Einrichtungen speziell für diesen Zweck eingesetzt werden) nicht jede Client-Einrichtung alle Informationen speichern muss. Statt dessen kann der Speicher einer Client-Einrichtung in mehrere Bereiche unterteilt werden.
In einem oder mehreren Hauptspeicherbereichen speichert eine Client-Einrichtung zunächst von den empfangenen Informationen nur diejenigen, die für ihren Nutzer von unmittelbarem Interesse sind. Ergänzend kann die Client-Einrichtung in einer oder mehreren anderen Speicherbereichen zufällig oder nach einem deterministischen Regelalgorithmus Informationen bis zu einem bestimmten (vom Benutzer konfigurierten) Volumen speichern, die zwar nicht für den Nutzer von zentralem Interesse sind, die aber potentiell anderen Nutzern auf Anfrage angeboten werden können.
Die einzelnen Haupt- und weiteren Speicherbereiche können beispielsweise thematisch, nach Ort, Zeit und vielen anderen Kriterien gegliedert sein. Auch können Größe und Aufteilung an Hand von Inhalten, Nutzerpräferenzen, Zeit, Ort, Kontext usw. aufgeteilt sein.
Eine solche Aufteilung auf verschiedene Client-Einrichtungen kann auch von einer Server-Einrichtung bereits vorgesehen werden, z.B. indem verschiedene Broadcast-Kanäle verwendet werden, auf denen jeweils andere Informationseinheiten übertragen werden. Eine Client-Einrichtungen empfängt dann – je nach Konfiguration und/oder Leistungsfähigkeit – Informationen von einem oder mehrere solchen Kanälen und speichert diese.
Jede Informationseinheit, die auf einer Client-Einrichtung angespeichert wird, wird um Informationen über die Informationseinheit selbst ergänzt (Meta-Daten). Hierzu können u.a. ein Bezeichner für die Informationseinheit (etwa ein URL im Falle einer Web-Ressorce), ein Verfallsdatum, die Größe, der Anteil an der gesamten Information (Anfang, Ende, Mittelteil, alles), Sicherheitseinstellungen und Zugriffsrechte sowie weitere Informationen zur lokalen Verwaltung und zur Kommunikation mit anderen Client-Einrichtungen zählen.
Wenn ein Nutzer jetzt eine Information (z.B. eine Webseite) betrachten will, prüft zunächst die Client-Einrichtung des Nutzers selbst, ob sie die gesuchte Information lokal im Speicher vorrätig hat. Ist dies der Fall, liefert sie die Information selbst.
Fehlen Teile der gesuchten Information, so fragt die Client-Einrichtung die anderen zu diesem Zeitpunkt im ihrer "Reichweite" (netztopologische Umgebung, etwa selbes WLAN, selbes IP-Subnetz, erreichbar per Multicast) befindlichen anderen Client-Einrichtung nach (den Teilen) der gesuchten Information. Alle Client-Einrichtungen die die gesuchten Teile oder oder die vollständige Information gespeichert haben (und diese der anfragenden Client-Einrichtungen zur Verfügung stellen wollen und entsprechend etwaiger Zugriffsrechte auch dürfen), melden sich daraufhin bei der anfragenden Client-Einrichtung: Sie teilen mit, welche der gesuchten Informationen sie anbieten können, und die Client-Einrichtung wählt dann in einem zweiten Schritt aus, welche Informationen sie von wem empfangen möchte. Oder die antwortenden Client-Einrichtungen übermitteln der anfragenden Client-Einrichtung sofort die gesuchten Informationseinheiten. Diese beiden Vorgehensweisen lassen sich auch – z.B. in Abhängig von der Menge der gesuchten Informationen und/oder anderer Parameter – kombinieren.
Die anfragende Client-Einrichtung empfängt dann die gesuchten Informationsteile von einer oder mehreren antwortenden Client-Einrichtungen und kombiniert diese Antworten bei Bedarf miteinander und/oder mit den bereits bei ihr lokal verfügbaren Informationseinheiten, um die gesuchte Information vollständig zu rekonstrurieren und dem Benutzer direkt oder mittelbar über eine Anwendung (z.B. einen Web-Browser) zur Verfügung zu stellen.
Analog geht die Client-Einrichtung vor, wenn sie gar keinen Bestandteil der gesuchten Information besitzt.
Die Anfragen der anfragenden Client-Einrichtung können direkt an eine andere (bekannte) Client-Einrichtung gestellt werden (per Unicast) oder per Multicast/Broadcast/Anycast an alle anderen Client-Einrichtungen.
Ebenso können die Antworten von einer Client-Einrichtung, die über die angefragten Informationseinheiten verfügt, per Unicast nur an die anfragende Client-Einrichtung gesendet werden oder per Multicast an potentiell mehrere Interessenten. Dabei können die Interessenten selbst und/oder das Vorhandensein mehrerer Interessenten dem Sender bekannt sein oder nicht. Auch hier lässt sich eine Aggregation von Anfragen wie oben beschrieben (diesmal jedoch in einer Client-Einrichtung) realisieren und entsprechend auch ein Caching der Antworten.
Gelingt es der Client-Einrichtung nicht, die gesuchte Information vollständig zu rekonstruieren, so kann sie zumindest die empfangenen Teile speichern und ist bei der nächsten Übertragung nicht mehr darauf angewiesen, die Information vollständig zu empfangen – es genügen dann die noch fehlenden Teile.
Diese Erfindung lässt sich nahezu beliebig mit den oben skizzierten Ideen kombinieren. Insbesondere sei hier auf zwei Möglichkeiten eingegangen, die Kombination mit anderen ist jedoch ebenso möglich:

1. Verschiedene Client-Einrichtungen können zusammenarbeiten, um Übetragungsfehler (z.B. Paketverluste), die bei einigen, nicht aber bei allen Client-Einrichtungen aufgetreten sind, auszugleichen: fehlen beispielsweise Teile einer gerade übertragenen Datei, so kann eine Client-Einrichtung die anderen nach genau diesen fehlenden Informationen fragen und die empfangene Datei so vervolltständigen.
2. Der Empfang und das gegenseiten Zurverfügungstellen von Informationen kann insbesondere auch mit der Aggregation von Anfragen auf den Server-Einrichtungen und dem Empfangen der Antworten auf Anfragen anderer Client-Einrichtungen kombiniert werden. Client-Einrichtungen können sich untereinander koordinieren und/oder (teilweise oder ganz) deterministisch und/oder zufällig entscheiden, welche der Antworten sie jeweils speichern, um diese dann später selbst nutzen, aber auch anderen Client-Einrichtungen auf lokale Anfrage zur Verfügung stellen zu können.

Schließlich ist es denkbar, dass eine Client-Einrichtung, bevor sie ein lokales Koordinationsnetz verlässt, die selbst gesammelten Informationen per Unicast/Multicast/Broadcast an andere Client-Einrchtung weitergibt oder zumindest mitteilt, dass sie demnächst das lokale Koordinationsnetz verlassen wird und über welche Informationen sie verfügt, so dass potentielle Interessenten und/oder "Backups" und/oder neu hinzugekommen Client-Einrichtungen diese Informationen übernehmen und für zukünftige Anfragen aufbewahren können.
Die in der vorstehenden Beschreibung und der Zeichnung offenbarten Merkmale der Erfindung können sowohl einzeln als auch in beliebiger Kombination für die Verwirklichung der Erfindung in ihren verschiedenen Ausführungsformen von Bedeutung sein.

Claims

Verfahren zum Übertragen von elektronischen Daten zwischen einem Server und einem Client über mindestens ein Übertragungsprotokoll, wobei – eine Übertragungsstrecke vom Server zum Client in mindestens zwei Kommunikationsabschnitte unterteilt wird, – die Unterteilung mindestens durch einem Server-seitigen Zwischensystem und einem Client-seitigen Zwischensystem vorgenommen wird, – auf einem Streckenabschnitt vom Server zum Server-seitigen Zwischensystem und auf einem Streckenabschnitt vom Client-seitigen Zwischensystem zum Client jeweils dasselbe Protokoll zum Einsatz kommt, – auf dem Streckenabschnitt vom Server-seitigen zum Client-seitigen Zwischensystem mindestens ein anderes, für die Eigenschaften dieses Streckenabschnitts optimiertes Protokoll zum Einsatz kommt, dadurch gekennzeichnet, daß ein Rückkanal von dem Client-seitigen Zwischensystem zum Server-seitigen Zwischensystem für die Dauer der Datenübertragung vom Server-Zwischensystem zum Client-Zwischensystem ungenutzt bleibt.