DE60132298T2

DE60132298T2 - System und Verfahren zur Datenübertragung

Info

Publication number: DE60132298T2
Application number: DE60132298T
Authority: DE
Inventors: Pertti Elonen; liro Pietilä
Original assignee: Contastic Oy
Current assignee: Contastic Oy
Priority date: 2001-03-20
Filing date: 2001-11-30
Publication date: 2009-01-02
Anticipated expiration: 2021-12-01
Also published as: DE60132298D1; US20020184371A1; EP1244269A2; US7188178B2; ATE383705T1; EP1244269A3; EP1244269B1; FI111587B; FI20010566L; FI20010566A0

Description

Die Erfindung bezieht sich allgemein auf das Übertragen von Daten in einem Paketdatennetzwerk. Insbesondere bezieht sich die Erfindung auf das Übertragen von Daten, die aktualisiert sein können, von einem Server an einen Client.
Der Ausdruck "Client" bezieht sich in dieser Beschreibung und in den anhängenden Ansprüchen auf eine Vorrichtung oder eine Anwendung (Programm), die einen Server über ein Datennetzwerk verbindet und typischerweise den Server auffordert, gewisse Informationen zu übersenden. Der Ausdruck "Server" bezieht sich auf eine Vorrichtung oder Anwendung, die auf Verbindungsanfragen von Clients wartet und auf die Anfragen durch Übersenden der angeforderten Informationen antwortet. Der Ausdruck "Echtzeitdienst" bezieht sich auf Dienste, bei denen Information, die in einem Server sitzt, immer wieder einmal aktualisiert wird und die aktualisierte Information an einen Client geliefert wird. Server und Client sind miteinander typischerweise über ein Paketdatennetzwerk verbunden, beispielsweise über das Internet. Information wird typischerweise von einem Server an einen Client unter Verwendung des Hypertext Transfer Protocol (HTTP) übertragen und der Client ist typischerweise ein Browser.
Echtzeitinformation bezieht sich auf Information, die in einem Server sitzt und immer wieder einmal aktualisiert wird.
Echtzeitdienste verbreiten sich immer weiter und Beispiele solcher Dienste sind Nachrichten und Aktienmarktinformationen. Es gibt zwei grundlegende Alternativen dazu, einen Client über die Änderungen (oder Aktualisierungen) in den Informationen informiert zu halten. Die erste Alternative ist Client-initiiert: Der Client ist dafür eingerichtet, die Information wiederholt anzufordern. Da der Client kein Verfahren hat, zu wissen, wann die Information im Server aktualisiert wird, mag er dazu auffordern, unveränderte Information zu übertragen. Dies verursacht unnötige Informationsübertragungen. Darüber hinaus wird aktualisierte Information typischerweise nicht sofort nach der Aktualisierung an einen Client (und an einen Anwender) geliefert.
Die zweite Alternative ist Server-initiiert. Ein Client fordert ein Informationsstück einmal an und danach löst die Informationsaktualisierung auf dem Server den Server aus, um die aktualisierte Information an einen Client zu schieben. Diese Alternativ erfordert typischerweise auf der Client-Seite getrennte Programmmodule. Diese Alternativen werden unten detaillierter diskutiert, aber bereits diese kurze Einführung zeigt, dass es beim Implementieren von Echtzeitdiensten Probleme gibt.
Ein übliches Protokoll zum Übertragen von Daten in Paketdatennetzwerken und insbesondere in IP(Internet Protocol)-Netzwerken ist HTTP. HTTP verwendet das Transfer Control Protocol (TCP), welches einen zuverlässigen Datentransfer unter Verwendung von Bestätigungen empfangener Datenpakete bereitstellt und bei Bedarf Wiederübertragung von Datenpaketen vorsieht. Zum Übertragen von Information unter Verwendung von HTTP zwischen einem Server und einem Client wird typischerweise eine TCP-Verbindung gebildet. HTTP-Nachrichten werden dann unter Verwendung der etablierten TCP-Verbindung übertragen.
Eine HTTP-Verbindung besteht im Grunde aus einer HTTP-Anforderung und einer HTTP-Antwort. Ein Client sendet eine HTTP-Anforderung, die typischerweise einen URL (Universalen Ressourcen Lokalisator) anzeigt und der Server antwortet durch Übersenden von auf diesen URL bezogenen Daten in einer HTTP-Antwort. Danach präsentiert der Client, insbesondere wenn er ein Browser ist, die empfangenen Daten einem Benutzer.
Ein Beispiel einer ersten Alternative zum Bereitstellen von Echtzeitdiensten an einen Anwender ist in 1 präsentiert. In diesem Beispiel wird das HTTP-Protokoll verwendet, um Echtzeitinformation von einem Server 100 an einen Client 110 zu übertragen. Der Client 110 ist ein Browser in einem Computer. Es wird typischerweise eine TCP-Verbindung zwischen dem Server 100 und dem Client 110 geöffnet, so dass HTTP-Nachrichten zwischen ihnen übertragen werden können. In 1 ist gezeigt, wie der Client 110 wiederholt eine HTTP-Anforderung an den Server 100 sendet. Diese HTTP-Anforderungen 120a, 120b, 120c sind typischerweise identisch. Der Server 100 antwortet auf diese HTTP-Anforderungen 120a, 120b, 120c mit HTTP-Antworten 130, 131, 132. Jedes HTTP-Anforderungs-/HTTP-Antwortpaar bildet eine HTTP-Verbindung 140a, 140b, 140c. Die Inhalte dieser HTTP-Antworten hängen von der auf dem Server sitzenden Echtzeitinformation ab. Falls die Echtzeitinformation nicht während des Empfangs der vorigen HTTP-Anforderung (beispielsweise 120b) vom Client 110 aktualisiert worden ist, sind zumindest zwei sequentielle HTTP-Antworten (beispielsweise 131 und 132) typischerweise identisch. Alle HTTP-Anforderungen und -Antworten, die in 1 präsentiert sind, können unter Verwendung einer TCP-Verbindung übertragen werden, mit anderen Worten können die HTTP-Verbindungen 140a, 140b und 140c eine TCP-Verbindung verwenden. Ein Browser frischt typischerweise die gesamte WWW-Seite auf, beispielsweise wenn er eine HTTP-Antwort 103, 131, 132 empfängt.
Der Hauptvorteil des Client-initiierten Echtzeitdienstes ist, dass er übliche Techniken verwendet. Die HTTP-Verbindungen 140a, 140b, 140c werden von allen Browsern unterstützt, sie sind bereits eingerichtet, TCP-Funktionalität zu verwenden, die typischerweise vom Betriebssystem von Computern bereitgestellt wird. Client-initiierte Echtzeitdienste werden somit durch jegliche Browser unterstützt. Der Hauptnachteil dieses Ansatzes ist, dass der Client nicht automatisch aktualisierte Informationen erhält. Die HTTP-Anforderung 120a, 120b, 120c muss oft gesendet werden, um aktualisierte Informationen am Client innerhalb einer akzeptablen Verzögerung zu erhalten und dies verursacht typischerweise, dass viele unaktualisierte Informationen nutzlos übersendet werden.
Ein Beispiel der zweiten Alternative des Bereitstellens von Echtzeitdiensten durch das Schieben (Pushen) von aktualisierten Informationen ist die Verwendung von Streaming-(Strom-)Techniken. Bei Streaming-Techniken wird nur eine Anforderung von einem Client an einen Server gesendet, mit der Informationsübertragung zu beginnen. Als Antwort auf diese Anforderung sendet der Server an den Client Informationsaktualisierungen über einen gewissen Zeitraum. Die Länge dieses Zeitraums kann vorbestimmt sein oder kann so bestimmt werden, dass er solange andauert, wie eine TCP-Verbindung, beispielsweise eine sich auf den Echtzeitdienst beziehende, zwischen dem Client und dem Server offen ist. Unter Verwendung der TCP-Verbindung kann der Server aktualisierte Informationen an den Client senden. Der Hauptnachteil dieses Ansatzes liegt darin, dass es üblicherweise ein getrenntes Programmmodul geben muss, das eine TCP-Verbindung etablieren kann und Informationen unter Verwendung von TCP übertragen kann. Typischerweise wird dies unter Verwendung von "Sockets" durchgeführt, die von einem Betriebssystem bereitgestellt werden.
Zusätzlich ist das Dokument von Fielding, R. et al ("Hypertext Transfer protocol, HTTP/1.1, RFC 2616", IETF Standard, Internet Engineering Task Force, IETF, CH, 1. Juni 1999) als Stand der Technik bekannt, der ein Hypertext Transfer Protocol offenbart und insbesondere das als HTTP/1.1 bezeichnete Protokoll zum Übersenden von Antworten von einem Server auf von einem Client in gewisser Weise gesendeten Anforderungen. Es offenbart auch eine stückweise Transfercodierung, um den Hauptteil einer Nachricht zu modifizieren, um sie als eine Reihe von Teilen zu übertragen, jedes mit seinem eigenen Größenindikator.
Eine Aufgabe der Erfindung ist es, ein flexibles Datenübertragungsverfahren und ein entsprechendes System und Computerprogrammprodukt zu präsentieren. Eine weitere Aufgabe der Erfindung ist es, ein Datenübertragungsverfahren zu präsentieren, das Echtzeitdienste ermöglicht, die Server-initiierte Informationsaktualisierungen unter Verwendung von Standard-Browsern und Standarddaten-Übertragungsprotokollen verwenden. Eine zusätzliche Aufgabe der Erfindung ist es, eine Übertragung von aktualisierbaren Informationen von einem Server an einen Client so zu gestatten, dass der Client nicht kontinuierlich Daten vom Server abfragen muss, um davon überzeugt zu werden, ob die Daten im Server aktualisiert wurden oder nicht.
Diese und andere Aufgaben der Erfindung werden gelöst durch Übersenden, an einen Client, in Antwort auf eine Anforderung zum Übersenden gewisser Informationsentitäten, einer ersten Antwortportion, wobei die erste Antwortportion dem Client erlaubt, weitere Antwortportionen zu akzeptieren.
Die Erfindung bezieht sich auf ein Verfahren zum Übertragen von Daten von einem Client unter Verwendung einer gewissen Paketdatenverbindung, wie in Anspruch 1 beansprucht.
Die Erfindung bezieht sich auf ein System zum Übertragen von Daten unter Verwendung von Paketdatenverbindungen, wie in Anspruch 18 beansprucht.
Die Erfindung bezieht sich auf ein Computerprogrammprodukt zum Übertragen von Daten unter Verwendung von Paketdatenverbindungen, wie in Anspruch 22 beansprucht.
Die angehängten abhängigen Ansprüche beschreiben einige bevorzugte Ausführungsformen der Erfindung. In einem abhängigen Anspruch spezifizierte Merkmale können weiterhin mit Merkmalen, die in einem anderen abhängigen Anspruch spezifiziert sind, kombiniert werden, um weitere Ausführungsformen der Erfindung zu erzeugen.
In einem Verfahren gemäß der Erfindung veranlasst die erste Antwortportion, die von einem Server an einen Client gesendet wird, einen Client dazu, weitere Antwortportionen zu akzeptieren und typischerweise auf sie zu warten. Dies ermöglicht es dem Server, beispielsweise nachdem die Informationsentität, die der Client angefordert hat, im Server aktualisiert worden ist, die aktualisierte Informationsentität oder typischerweise einen aktualisierten Teil der Informationsentität an den Client zu senden. Während der Client auf weitere Antwortportionen wartet, akzeptiert er die aktualisierte Information tragende Antwortportion. Die Erfindung wird vorteilhafter Weise zum Übertragen aktualisierter Informationen verwendet, aber ihre Anwendung ist nicht auf diesen spezifischen Fall beschränkt. Es ist alternativ möglich, unter Verwendung eines Verfahrens gemäß der Erfindung jegliche Informationsentität Stück für Stück an einen Client zu senden, anstatt die gesamte Informationsentität unter Verwendung einer einzelnen Antwortnachricht zu senden. Die Zeiträume zwischen dem Senden sequentieller weiterer Antwortportionen muss nicht gleich sein, sie können verschiedene Werte aufweisen.
Die zweiten Antwortportionen umfassen alle typischerweise einen Computersprachenvorspann, ein Informationsfragment der Informationsentität und Computersprache-Anweisungen zum Verarbeiten des Informationsfragments im Clientprogramm. Die Computersprache kann beispielsweise solch eine Scriptsprache sein, welche typische Client-Software, beispielsweise Browser, unterstützen. Eine Scriptsprache ist eine einfache Programmiersprache zum Schreiben von Scripten. Ein Script ist eine Liste von Befehlen, die von einem Computer ohne Anwenderinteraktion ausgeführt werden können. Die Computersprachinstruktionen können ein Script sein. Alternativ kann die Computersprache eine Sprache sein, die verwendet wird, um Informationen Struktur zu verleihen, indem gewisse Informationselemente und ihre Werte definiert werden. Die erweiterbare Markierungssprache (XML, Extensible Markup Language) ist ein Beispiel einer solchen Computersprache. In diesem Fall sind die Computersprachanweisungen typischerweise einige wohldefinierte Tags, durch deren Verwendung ein gewisser Wert für ein gewisses Informationselement deklariert wird.
In einigen Fällen kann ein Client-Programm festlegen, eine Paketdatenverbindung zu schließen oder kann festlegen, dass es keine weiteren zu empfangenden Daten gibt, falls für einen gewissen Zeitraum keine Daten übertragen werden. Der letztere Fall gilt für einige Browser. Daher ist in einem Verfahren gemäß der Erfindung der Zeitraum zwischen zwei aufeinanderfolgenden Antwortportionen vorteilhafter Weise auf einen gewissen Maximalwert beschränkt. Auf diese Weise wird beispielsweise ein Client, der ein Browser ist, eine HTTP-Verbindung oder eine TCP-Verbindung, die sich auf die Übertragung der angeforderten Informationsentität bezieht, nicht schließen.
Vorteilhafter Weise wird nur ein aktualisierter Teil der Informationsentität an den Client übertragen. Dies kann beispielsweise geschehen, indem unter Verwendung einer Computersprache definiert wird, dass diese Informationsentität aus verschiedenen Informationselementen gebildet wird. Eine Antwortportion, die nach der Informationsaktualisierung gesendet wird, kann in diesem Fall ein Informationselement identifizieren und einen neuen Wert für das Informationselement nennen. In der Praxis gibt es verschiedene Scriptsprachen, die mit Browsern verwendet werden, die diese Funktionalität unterstützen. Beispiele solcher sind Dynamic HTML, VBScript, JScript und JavaScript.
Ein Vorteil der Erfindung besteht darin, dass, wenn geeignete Scriptsprachen verwendet werden, keinerlei zusätzliche Software (wie etwa Java Applets) oder irgendeine Modifikation an beispielsweise existierenden Browsern in den Clients notwendig sind. Ein Client, der unter Verwendung gewisser Standarddatenübertragungsprotokolle kommuniziert, kann einfach ein Verfahren gemäß der Erfindung verwenden. Wenn beispielsweise das verwendete Standarddatenübertragungsprotokoll HTTP ist, ist typischerweise jeder Browser in der Lage, Echtzeitinformationen gemäß der Erfindung zu empfangen, wenn die zweiten Antwortportionen ein geeignete Scriptsprache umfassen. Wenn die Client-Software ein Browser ist, erfordert die Erfindung in einer Client Vorrichtungsunterstützung beispielsweise nicht, dass Java Applets oder andere Software-Komponenten auszuführen sind, die manchmal verwendet werden, um die Funktionalität eines Browsers zu verbessern. Alternativ, falls erwünscht, ist es einfach möglich, spezifische Clientprogramme zu programmieren, die angelieferte Informationen anzeigen oder verarbeiten, unter Verwendung eines Verfahrens gemäß der Erfindung.
Ein weiterer Vorteil der Erfindung ist, dass, da Standarddatenübertragungsprotokolle hinreichen, um ein Datentransferverfahren gemäß der Erfindung zu implementieren, es keinen Bedarf dafür gibt, spezifische Einstellungen an beispielsweise Firewalls oder Netzwerken vorzunehmen, über welche die Datentransferverbindungen gehen. Die Antwortportionen sind beispielsweise einfache TCP-Pakete, die textuelle HTML Informationen tragen oder die einige einfache Computersprachbefehle oder Tags im HTML-Format tragen. eine Firewall gestattet es typischerweise dieser Art von Nachrichten, hindurchzugehen. Bei Lösungen des Stands der Technik, bei denen gewisse Server-initiierte Push-Verfahren verwendet werden, enthalten die zu übertragenden Daten typischerweise einige aktive Komponenten, die auf dem Client auszuführen sind. ActiveX Komponenten oder Java Applets sind Beispiele solcher aktiver Komponenten. Es ist beispielsweise schwierig, in einer Firewall sicherzustellen, dass solche aktiven Komponenten kein Sicherheitsrisiko in einem Lokalnetzwerk darstellen und daher mag es sein, dass Datenpakete, welche solche Komponenten führen, in einer Firewall verworfen werden.
Die Erfindung wird nun detaillierter unter Bezugnahme auf die beigefügten Zeichnungen beschrieben, in denen:
1 ein Beispiel eines Client-initiierten Echtzeitdienstes gemäß dem Stand der Technik illustriert,
2 ein Beispiel eines Flussdiagramms eines Verfahrens gemäß einer ersten bevorzugten Ausführungsform der Erfindung illustriert,
3 als ein Beispiel eine Nachrichtensequenz, die sich auf ein Verfahren gemäß einer zweiten bevorzugten Ausführungsform der Erfindung bezieht, illustriert,
4 schematisch ein Beispiel eines Systems gemäß der Erfindung und seine Verwendung illustriert, und
5a–5e Flussdiagramme von Verfahren illustriert, die in einem System gemäß der Erfindung verwendet werden können.
1 wird oben in Verbindung mit Bezugnahme auf Lösungen des Stands der Technik diskutiert.
2 illustriert als ein Beispiel ein Flussdiagramm eines Verfahrens 200 zum Übertragen von Information gemäß einer ersten bevorzugten Ausführungsform der Erfindung. In Schritt 201 wird eine Anforderung, die einem gewissen Datenübertragungsprotokoll entspricht und eine gewisse Informationsentität I spezifiziert, empfangen. In Schritt 202 wird zu einem ersten Zeitpunkt t₁ eine erste Antwortportion R₁, typischerweise unter Verwendung eines ersten Informationsfragmentes I₁, das sich auf die Informationsentität I bezieht, an den Client gesendet. Die erste Antwortportion R₁ ist so, dass sie den Client dazu veranlasst, zumindest eine zweite Antwortportion zu erwarten. Solch eine zweite Antwortportion enthält typischerweise ein zweites Informationsfragment I₂, das sich auf die Informationsentität I bezieht. Beispiele von solchen Antwortportionen R₁ werden unten detaillierter in Verbindung mit anderen bevorzugten Ausführungsformen der Erfindung beschrieben.
Nach Übersenden der ersten Antwortportion R₁(I₁) wird in Schritt 203 überprüft, ob die Informationsentität I, die typischerweise in einem Server sitzt, aktualisiert wird. Falls die Informationsentität nach t1 aktualisiert worden ist, wird in Schritt 204 eine zweite Antwortportion R_2,1(I₂) zum Zeitpunkt t_2,1 gesendet. Diese zweite Antwort R_2,1 umfasst ein Informationsfragment I₂, das sich auf die Informationsentität I bezieht. Dieses Informationsfragment kann beispielsweise entweder die gesamte aktualisierte Informationsentität I oder der Teil der Informationsentität I sein, der aktualisiert worden ist. Die zweite Antwortportion R_2,1 umfasst auch einige Computersprachinstruktionen zum Verarbeiten des Informationsfragments I₂. Sie kann weiterhin Computersprachvorspänne umfassen. Ein Zähler i wird in Schritt 204 aus Gründen der Klarheit inkrementiert. Solch ein Zähler wird nicht notwendigerweise in einem Verfahren gemäß der Erfindung verwendet.
Falls die Informationsentität I nach t₁ nicht aktualisiert worden ist, wird in Schritt 205 überprüft, ob die seit t₁ verstrichene Zeit gleich oder größer einem gewissen vorgegebenen Maximalzeitraum T_max ist. Ein typischer Wert für den Maximalzeitraum ist 30–120 Sekunden, er kann aber von einer Sekunde bis zu einigen Minuten reichen. Falls solch ein Zeitraum noch nicht verstrichen ist, werden die Schritte 203 und 205 wiederholt, bis eine der Überprüfungen wahr wird. Falls solch ein Zeitraum seit t₁ bereits verstrichen ist, wenn Schritt 205 durchgeführt wird, wird in Schritt 206 eine dritte Antwortportion R_3,1 zum Zeitpunkt t_3,1 übersendet. Da die Informationsentität I seit t₁ nicht aktualisiert worden ist, ist es nicht notwendig, irgendwelche Informationsfragmente in dieser Antwortportion zu übersenden. Der Zweck des Sendens dieser Antwortportion R_3,1 besteht darin, sicherzustellen, dass ein Client bereit bleibt, weitere zweite Antwortportionen R_2,i zu akzeptieren. Ein Zähler k wird in Schritt 206 aus Gründen der Klarheit inkrementiert. Solch ein Zähler wird nicht notwendigerweise in einem Verfahren gemäß der Erfindung verwendet.
Die zweite Antwortportion R_2,1 ist die frühest übersendete Antwort einer Mehrzahl von zweiten Antwortportionen R_2,i. Die Anzahl dieser zweiten Antwortportionen R_2,i hängt typischerweise von der Dauer des Informationstransfers ab. Der Informationstransfer kann beispielsweise durch einen Client gestoppt werden, der eine Datentransferverbindung schließt, beispielsweise eine TCP-Verbindung unter Verwendung derer die Antwortportionen, beispielsweise HTTP-Nachrichtenportionen, zum Client geliefert werden.
Nach Senden der frühesten der zweiten Antwortportionen R_2,1 oder der frühesten der dritten Antwortportionen R_3,1 wird in Schritt 207 überprüft, ob die Informationsentität I, die typischerweise im Server sitzt, seit t_2,i-1 aktualisiert worden ist. Falls die Informationsentität nach t_2,i-1 aktualisiert worden ist, wird eine weitere zweite Antwortportion R_2,i(Ij + 1) in Schritt 208 zum Zeitpunkt t_2,i gesendet. Der Zähler i wird im selben Schritt um Eins erhöht. Die Antwortportion R_2,i umfasst ein Informationsfragment I_j+1, das sich auf die Informationsentität I bezieht. Falls die Informationsentität I nach t_2,i-1 nicht aktualisiert worden ist, wird im Schritt 209 überprüft, ob die seit t_2,i-1 oder t_3,k-1 verstrichene Zeit gleich oder größer einem gewissen vorgegebenen maximalen Zeitraum T_max ist. Falls solch ein Zeitraum noch nicht verstrichen ist, werden die Schritte 207 und 209 wiederholt, bis eine der Überprüfungen wahr ist. Falls solch ein Zeitraum seit t_2,i-1 oder t_3,k-1 bereits verstrichen ist, wenn die Überprüfung in Schritt 209 durchgeführt wird, wird eine weitere dritte Antwortportion R_3,k in Schritt 210 gesendet. Ähnlich dem Schritt 205 ist es für diese dritte Antwortportion R_3,1 nicht notwendig, jegliche Informationsfragmente in den Antwortportionen R_3,k in Schritt 210 zu übersenden.
Nach Schritt 208 oder 210 setzt sich das Verfahren 200 in Schritt 207 fort. Die Schritte 207–210 werden solange wiederholt, wie das Verfahren 200 ausgeführt wird. Typischerweise enthält die sich ergebende Abfolge von Nachrichten zweite und dritte Antwortportionen, die miteinander verwoben sind. Es ist möglich, dass die sich ergebende Sequenz von Nachrichten nach der ersten Antwortportion nur zweite Antwortportionen enthält, dies ist der Fall typischerweise, wenn entweder die Informationsentität I oft aktualisiert wird oder wenn es keine Notwendigkeit gibt, Nachrichten zu übertragen, so dass der Zeitraum zwischen zwei aufeinanderfolgenden Antwortportionen maximal einen gewissen Wert hat. Im letzteren Fall werden typischerweise keine dritten Antwortportionen gesendet. Die Zeitintervallprüfungen in den Schritten 205 und 209 können verschiedene Werte für das Maximalintervall verwenden, 2 zeigt denselben T_max Wert in beiden Schritten 205 und 209 als Beispiel.
Das Informationsfragment I₁ in der ersten Antwortportionen in Schritt 202 kann die aktuelle Informationsentität I oder ein Teil der aktuellen Informationsentität I sein. Falls I₁ nur Teil der Informationsentität I ist, ist es möglich, dass in einigen zweiten Antwortportionen R_2,i, die in den Schritten 204 und 208 gesendet werden, weitere Informationsfragmente enthalten sind, die sich auf die Informationsentität I beziehen, zum Zeitpunkt t₁ übertragen werden. Alternativ ist es möglich, dass eine erste Antwortportion R₁ nur beispielsweise einen Identifikator enthält, der beispielsweise einen Namen der Informationsentität I anzeigt. Weiterhin muss R₁ keinen Teil der tatsächlich angeforderten Informationsentität I enthalten; in diesem Fall bezieht sich I₁ auf ein nicht existierendes Informationsfragment oder ein leeres Informationsfragment.
Im Folgenden, wenn weitere bevorzugte Ausführungsformen der Erfindung beschrieben werden, wird HTTP als Beispiel eines Standarddatenübertragungsprotokolls verwendet und die TCP-Verbindung wird als ein Beispiel einer Paketdatenverbindung verwendet. Die untenstehend präsentierten Ideen sind jedoch nicht auf die Verwendung von HTTP oder TCP beschränkt.
Tabelle 1 illustriert Beispiele von Inhalten von TCP-Nachrichten, die in einem Verfahren gemäß der zweiten bevorzugten Ausführungsform der Erfindung übersendet werden können. Eine HTTP-Anforderung, die beispielsweise in Schritt 201 empfangen werden kann, wird zuerst präsentiert. Eine erste Antwortportion R₁, die am Beginn einer HTTP-Antwortnachricht liegen kann, wird in der nächsten Spalte von Tabelle 1 präsentiert. Alternativen für eine zweite Antwortportion R_2,i und Alternativen für eine dritte Antwortportion R_3,k sind ebenfalls in Tabelle 1 illustriert.
Die in Tabelle 1 illustrierte erste Antwortportion R₁ ist der Anfang einer HTTP-Antwort, enthält aber keinen Inhaltslängenparameter. Dieser Inhaltslängenparameter zeigt typischerweise die Länge der Informationsentität an, die der Server an einen Client sendet, in einer oder mehreren HTTP-Antworten. Typischerweise ignoriert ein Browser jegliche Nachrichten, die sich auf eine gewisse HTTP-Anforderung beziehen, nachdem er eine Informationsmenge empfangen hat, die einem Inhaltslängenparameter entspricht, der am Anfang einer HTTP-Antwort spezifiziert worden ist. Vorteilhafter Weise ist der Inhaltslängenparameter in einer HTTP-Erstantwortportion R₁ nicht vorhanden, so dass der Inhaltslängenparameterwert durch die erste Antwortportion unbekannt gelassen wird. Alternativ ist es möglich, den Inhaltslängenparameter in einer ersten HTTP-Antwortportion (oder einen entsprechenden Parameter im ersten Bereich einer anderen Datentransferprotokollantwort) zu haben und so einen großen Wert für diese Inhaltslängenparameter auszuwählen, dass nicht erwartet werden kann, dass die sich auf eine Mehrzahl von zweiten Antwortportionen beziehende Datenmenge (und möglicherweise dritte Antwortportionen) dieser Verbindung den ausgewählten Wert übersteigt. Falls ein Wert für einen Inhaltslängenparameter oder für einen entsprechenden Parameter in einer ersten Portion einer Antwort in einem Verfahren gemäß der Erfindung angegeben wird, übersteigt sein Wert die Datenmenge, die sich auf diese erste Portion einer Antwort bezieht. Ein Beispiel eines Werts für den Inhaltslängenparameter in einer HTTP R₁ ist 10000000. Dies bedeutet, dass ein Client (Browser) erwartet, dass die HTTP-Antwort 10000000 Bytes enthält.
Die Fragezeichen und Pünktchen zwischen dem HTML Script-Tags <script> und </script> im Inhalte der Antwortportion R_2,i zeigen gewisse Scriptsprache-spezifischen Anweisungen an. Ein Beispiel für JavaScript wird unten angegeben.
Tabelle 2 illustriert Beispiele von Inhalten von TCP-Nachrichten, die in einem Verfahren gemäß einer dritten bevorzugten Ausführungsform der Erfindung übersendet werden können. In dieser dritten bevorzugten Ausführungsform werden Rahmen, die Elemente von HTML-Seiten sind, verwendet. eine HTML Seite, die hier als Beispiel gegeben wird, hat einen ersten Rahmen, dessen Name feedsource ist und der gesendete Nachrichten unter Verwendung eines Verfahrens gemäß der Erfindung empfängt. Die HTML Seite weist einen zweiten Rahmen auf, dessen Name feedtarget ist und der sich auf das Zeigen der empfangenen, in diesem Beispiel periodisch aktualisierten Information einem Anwender bezieht.
3 illustriert als ein Beispiel einer Nachrichtensequenz zwischen einem Client 110, welcher ein Browser ist, und einem Server 300; diese Nachrichtenabfolge bezieht sich auf eine dritte bevorzugte Ausführungsform der Erfindung. In 3 präsentierte Nachrichten sind HTTP-Nachrichten oder Portionen von HTTP-Nachrichten, von denen Beispiele in Tabelle 2 vorgestellt werden und die typischerweise unter Verwendung einer einzelnen TCP-Verbindung übertragen werden.
Die erste initiierende Anforderung 301 ist eine HTTP-Anforderung, die ein HTML-Dokument feedframe.htm spezifiziert. Dieses HTML-Dokument wird einem Client in der ersten initiierenden Antwort 302 geliefert, welches eine HTTP-Antwort ist, die zwei Rahmen anzeigt (feedsource, feedtarget) und Quellen (/feed.rtscript und /feedtarget.htm), wo ein Inhalt für diese Rahmen geholt werden kann. Nach Empfangen der HTTP-Antwort 302 sendet der Client eine zweite initiierende Anforderung 303, welche eine HTTP-Anforderung ist, die das HTML Dokument feedtarget.htm spezifiziert. Als Antwort auf die Nachricht 303 sendet der Server eine zweite initiierende Antwort 304, welche eine HTTP-Antwort ist, die den Namen t1 für ein Feld des Typs text in einem Formular spezifiziert, dessen Name f1 ist. Wie in Tabelle 2 zu sehen, enthalten die HTTP-Antworten 302 und 304 den Inhaltslängenparameter und einen Wert für diesen Parameter. 3 illustriert, wie die Nachrichtenpaare 301, 302 und 303, 304 zwei HTTP-Verbindungen 140d, 140e bilden.
Die Anforderung 305, welche eine die Quelle feed.rtscript spezifizierende HTTP-Anforderung ist, startet eine Nachrichtenabfolge gemäß der Erfindung. Als eine Antwort auf diese Anforderung 305 sendet der Server zuerst eine erste Antwortportion 306. Diese erste Antwortportion 306 ist der Anfang einer HTTP-Antwortnachricht. Sie deklariert, mit dem <HTML> Tag, dass ein HTML-Dokument übertragen wird. Der Hauptteil (Body) des HTML-Dokuments ist leer und zwischen den Scripttext wird der Wert 0 für das Feld t1 in Formular f1 in einem Rahmen [1] definiert (der sich auf die feedtarget.htm bezieht), in einem Hauptfenster. Die zweite Antwortportion R_2,1 307 definiert Wert 1 für denselben Eingabeparameter und die zweite Antwortportion R_2,2 308 definiert Wert 2 für den Eingabeparameter. In Tabelle 2 werden keine weiteren Antwortportionen illustriert, aber 3 illustriert eine dritte Antwortportion R_3,1 309, welche typischerweise der in Tabelle 1 präsentierten Alternative für die dritte Antwortportion R_3,i ähnelt. Nach dieser dritten Antwortportion wird eine weitere zweite Antwortportion R_2,3 310 an den Client gesendet. Es ist möglich, dass darauffolgend dritte Antwortportionen an einen Client gesendet werden (wie beispielsweise aus 2 ersichtlich), obwohl dies in 3 nicht illustriert wird.
In einer vierten bevorzugten Ausführungsform der Erfindung ist die Computersprache XML. Typischerweise braucht zum Zeitpunkt des Schreibens dieser Patentanmeldung ein Browser eine ActiveX-Komponente oder ein Java-Applet zum Verarbeiten von XML Informationen. Es ist jedoch möglich, dass zukünftige Browser selbst in der Lage sind, XML zu prozessieren, ohne irgendwelche zusätzliche Komponente. Tabelle 3 illustriert Beispiele von HTTP-Nachrichten, die XML enthalten. In diesem Beispiel werden die Werte von Feldern t1 und t2 in einem XML Dokument durch Übersenden zweiter Antworten R_2,i aktualisiert. In Tabelle 3 enthält die erste Antwort nur HTTP-Vorspänne und die zweiten Antworten umfassen XML-Elemente.
Tabelle 4 illustriert Beispiele von Nachrichten, wenn die erste Antwortportion R₁ anzeigt, dass ein XML Dokument übertragen wird. Hier enthält die erste Antwortportion HTTP-Antwortvorspanninformationen und Beginnvorspänne eines XML Dokuments. Die zweiten Antwortportionen umfassen XML Elemente.
4 illustriert als Beispiel ein System 400 gemäß der Erfindung. Das System 400 umfasst

– Mittel 410 zum Etablieren von Paketdatenverbindungen, und
– Mittel 420 zum Empfangen von Anfragen, wobei eine Anforderung eine Informationsentität anzeigt, die gemäß einem Datenübertragungsprotokoll ist und sich auf eine gewisse Paketdatenverbindung bezieht, und es ist dadurch gekennzeichnet, dass es weiterhin umfasst
– Mittel 430 zum Übersenden als Antwort auf die Anforderung, unter Verwendung einer anforderungsspezifischen Paketdatenverbindung und einer anforderungsspezifischen ersten Zeitinstanz, einer ersten Portion einer Antwort gemäß dem Datenübertragungsprotokoll, wobei der Client nach Empfang der ersten Portion weiterhin zumindest eine zweite Portion einer Antwort akzeptiert, und
– Mittel 440 zum Übersenden, als eine Antwort auf eine Anforderung unter Verwendung der anforderungsspezifischen Paketdatenverbindung zu nachfolgenden anforderungsspezifischen zweiten Zeitpunkten, einer Mehrzahl von zweiten Portionen einer Antwort, wobei jede der zweiten Portionen ein Informationsfragment der Informationsentität und Computersprache-Instruktionen zum Verarbeiten des Informationsfragmentes umfasst.

Das System 400 kann weiterhin umfassen Mittel 450 zum Übersenden als eine Antwort auf eine Anforderung unter Verwendung der anforderungsspezifischen Paketdatenverbindung zu nachfolgenden anforderungsspezifischen dritten Zeitpunkten, einer Mehrzahl von dritten Portionen einer Antwort, wobei die dritten Portionen keine Informationsfragmente der Informationsentität enthalten. Weiterhin kann das System 400 weiter Mittel 460 zum Empfang von aktualisierten Informationen umfassen, beispielsweise für einen Informationsserver 401. Wie in 4 illustriert, kann ein Informationsserver 401 mit einer Mehrzahl von Datenübertragungsservern 402a, 402b, 402c gemäß der Erfindung verbunden sein, in denen allen ein System 400 implementiert ist. Wie 4 illustriert, überträgt jeder der Datenübertragungsserver 402 typischerweise Daten an eine Mehrzahl von Clients 403.
Das System 400 wird typischerweise als eine Kombination von Software und Hardware implementiert: Es ist typischerweise ein Computerprogramm oder ein Satz von Computerprogrammen, die unter Verwendung eines geeigneten oder geeigneter Mikroprozessor(en) und Speichermittel ausgeführt werden. Für einen tatsächlichen Datentransfer zwischen einem Server und einem lokalen Netzwerk, mit dem ein Server typischerweise verbunden ist, kann jegliche Netzwerkschnittstelle verwendet werden.
5a illustriert ein Beispiel dafür, wie Mittel 420 zum Empfangen einer Anforderung und Mittel 403 zum Senden einer ersten Antwortportion zum Betrieb angeordnet werden können. Wenn das System 400 unbeschäftigt ist, kann es auf Ereignisse warten (Schritt 501). Wenn eine Anforderung von einem Client unter Verwendung beispielsweise eines TCP-Stacks empfangen wird, wird an einem Punkt der Verarbeitung der die Anforderung enthaltenen TCP-Nachricht ein Clientanforderungsereignis erzeugt. Dieses Ereignis wird in Schritt 502 empfangen. Danach wird Clientreferenzinformation (beispielsweise ein TCP Socket für Clientverbindung) typischerweise in einer, Informationen über Clients enthaltenden Liste in Schritt 503 gespeichert. In Schritt 504 wird eine erste Antwortportion R₁ an den neuen Client gesendet. In Schritt 505 wird Information über die Clientspezifische Zeit, wenn eine Antwortportion jüngstens an einen spezifischen Client gesendet wurde, aktualisiert. Diese Information kann in der, Informationen über Clients enthaltenden Liste gespeichert werden.
5b illustriert ein Beispiel, wie Mittel 460 zum Empfang aktualisierter Informationen arbeiten können. Aktualisierte Informationen werden in Schritt 511 empfangen und werden typischerweise im Schritt 512 in Speichermitteln in einem Server 403 gespeichert, und danach wird in Schritt 513 ein Ereignis erzeugt, das anderen Teilen des Systems 400 anzeigt, dass aktualisierte Informationen empfangen worden sind.
5c illustriert ein Beispiel, wie Mittel 440 zum Senden zweiter Antwortportionen angeordnet werden können zu arbeiten, wenn aktualisierte Informationen in den zweiten Antwortportionen gesendet werden. In Schritt 521 wird ein Ereignis empfangen, das anzeigt, dass aktualisierte Informationen empfangen werden. In den Schritten 522 und 523 wird die, Informationen über Clients enthaltende Liste verarbeitet. Für jeden Client wird aktualisierte Information in einer zweiten Antwortportion übersendet (Schritt 524). Nachdem das Senden begonnen hat, wird die Client-Zeitinformation aktualisiert (Schritt 525). Nachdem die zweite Antwortportion gesendet worden ist, wird ein Ereignis erzeugt, das anzeigt, dass Aktualisierungsdaten an einen spezifischen Client geschickt worden sind.
5d illustriert ein Beispiel, wie Mittel 450 zum Senden dritter Antwortportionen arbeiten können. In Schritt 531 wird ein Timer-Notifikationsereignis empfangen. Diese Notifikation ist eine Notifikation, die sich auf einen Timer Tc bezieht, der allen existierenden Datenübertragungsverbindungen zu Clients gemein ist. Client-spezifische Timer sind eine Alternative, erfordern aber typischerweise mehr Computer-Ressourcen als die Verwendung eines gemeinsamen Timers. Wenn ein gemeinsamer Timer verwendet wird, wird die Clientliste nach Empfang der Zeitnotifikation verarbeitet (Schritt 532 und 533). Falls der Zeitraum vom jüngsten Zeitpunkt, wenn an einen spezifischen Client eine Antwortportion gesendet wurde, bis zu dem Zeitpunkt, wenn der gemeinsame Timer Tc als nächstes notifiziert, kleiner ist als ein vorgegebenes Limit Tmax (Schritt 534), wird der nächste Client in der Clientliste prozessiert. Dies bedeutet, dass, wenn dieser Client nach der nächsten Tc Notifikation überprüft wird, es sehr wahrscheinlich noch Zeit gibt, eine dritte Antwortportion zu senden. Alternativ wird eine dritte Antwortportion an den Client in Schritten 535 und 536 gesendet, ähnlich wie eine zweite Antwortportion in den Schritten 524 und 525 gesendet wird. Um sicherzustellen, dass der Zeitraum zwischen zwei aufeinanderfolgenden Antwortportionen, die an einen spezifischen Client gesendet werden, Tmax nicht übersteigt, sollte der Zeitraum Tc, der sich auf den gemeinsamen Timer bezieht, klar kleiner als Tmax sein.
5e führt die Illustration der Beispiele in 5c und 5d fort. Es ist möglich, dass neue aktualisierte Informationen empfangenen werden, während die Clientliste in den Schritten 524–525 oder 535–536 prozessiert wird. Das in 5e illustrierte Flussdiagramm ist Client-spezifisch, da sich das Daten-gesendet-Ereignis auf einen bestimmten Client bezieht. Wenn das Daten-gesendet-Ereignis in Schritt 541 empfangen wird, wird in Schritt 542 überprüft, ob Information aktualisiert worden ist seit der Clientzeit (d. h. seit jüngstens, da die Clientzeit in Schritt 525 oder Schritt 536 aktualisiert worden ist). Falls Informationen aktualisiert worden sind, werden dann in den Schritten 544 und 545, die identisch sind zu den Schritten 524 und 525, die aktualisierten Informationen in einer zweiten Antwortportion an diesen Client gesendet.

Obenstehend wird HTTP viele Male als Beispiel eines Standard-Datenübertragungsprotokolls verwendet und eine TCP-Verbindung wird viele Male als ein Beispiel einer Paketdatenverbindung verwendet. Die unten vorgestellten Ideen sind jedoch nicht auf die Verwendung auf HTTP oder TCP beschränkt. Sie gelten auch für ein Datentransferverfahren oder Protokoll ähnlich HTTP, wo eine typischerweise von einem Server empfangene Anforderung eine an einen Browser zu sendende Antwort verursacht und in der Antwort, ein Parameter vorliegen kann, aber nicht muss, der die Menge an Daten in der Antwort anzeigt. Ähnlich kann die Paketdatenverbindung jegliche Paketdatenverbindung sein. TABELLE 1 Beispiele von Nachrichteninhalten in einer zweiten bevorzugten Ausführungsform

Nachricht	Inhalt
Anforderung	GET /realtimeinfo HTTP/1.0\r\n Accept: /\r\n Accept-Language: en\r\n User-Agent: RealTimeScriptingClient\r\n Connection: Keep-Alive\r\n \r\n
Erste Antwortportion R₁	HTTP/1.0 200 OK\r\n Server: RealTimeServer\r\n Content-Type: text/html\r\n \r\n
Zweite Antwortportion R_2,i	<script>...???...</script>\r\n oder <script language="some...script">...???...</script>\r\n
Dritte Antwortportion R_3,k	\r\n oder <script></script>\r\n oder <script/>\r\n

TABELLE 2 Beispiele von Nachrichten einer dritten bevorzugten Ausführungsform

Nachricht	Inhalt
Eine erste initiierende Anforderung 301	GET /feedframe.htm HTTP/1.0\r\n Accept: /\r\n Accept-Language: en\r\n User-Agent: RealTimeScriptingClient\r\n Connection: keep-alive\r\n r\n
Eine erste initiierende Antwort 302	HTTP/1.0 200 OK\r\n Server: SomeServer\r\n Content-Type: text/html\r\n Connection: keep-alive\r\n Content-Length: 140\r\n r\n <Html> <Frameset rows="64, *"> <Frame name="feedsource" src="/feed.rtscript"> <Frame name="feedtarget" src="/feedtarget.htm"> </Frameset> </Html>
Eine zweite initiierende Anforderung 303	GET /feedtarget.htm HTTP/1.0\r\n Accept: /\r\n Accept-Language: en\r\n User-Agent: RealTimeScriptingClient\r\n Connection: keep-Alive\r\n r\n
Eine zweite initiierende Antwort 304	HTTP/1.0 200 OK\r\n Server: SomeServer\r\n Content-Type: text/html\r\n Connection: keep-alive\r\n Content-Length: 87\r\n r\n <Html><Body> <Form name="f1"> <Input type="text" name="t1" value=""> </Form> </Body></Html>
Anforderung 305	GET /feed.rtscript HTTP/1.0\r\n Accept: /\r\n Accept-Language: en\r\n User-Agent: RealTimeScriptingClient\r\n Connection: keep-alive\r\n \r\n
Antwortportion R₁(I₁) 306	HTTP/1.0 200 OK\r\n Server: Real TimeServer\r\n Content-Type: text/html\r\n <HTML> <BODY> </BODY> <Script>window.parent.frames[1].document.f1.t1.value='0'; </Script>
R_2,1(I₂) 307	<Script>window.parent.frames[1].document.f1.t1.value='1'; </Script\r\n
R_2,2(I₃) 308	<Script>window.parent.frames[1].document.f1.t1.value='2'; </Script>\r\n

TABELLE 3 Beispiele von Netzen einer vierten bevorzugten Ausführungsform

Nachricht	Inhalt
Anforderung	GET /xmlfeed.rtscripr HTTP/1.0\r\n Accept: /\r\n Accept-Language: en\r\n User-Agent: RealTimeScritingClient\r\n Connection: keep-Alive\r\n \r\n
R₁	HTTP/1.0 200 OK\r\n Server: RealTimeServer\r\n Content-Type: text/xml\r\n \r\n
R_2.1(I₂)	<cell><field>t1</field><value>234</value><cell>\r\n <cell><field>t2</field><value>123</value><cell>\r\n
R_2.2(I₃)	<cell><field>t1</field><value>237</value><cell>\r\n
R_3.1	\r\n
R_2.3(I₄)	<cell><field>t2</field><value>119</value><cell>\r\n

TABELLE 4 Zweite Beispiele von Nachrichten in einer vierten bevorzugten Ausführungsform

Nachricht	Inhalt
Anforderung	GET /xmlfeed.rtscript HTTP/1.0\r\n Accept: /\ Accept-Language: en\r\n User-Agent: RealTimeScriptingClient\r\n Connection: Keep-Alive\r\n \r\n
R₁(I₁)	HTTP/1.0 200 OK\r\n Server: RealTimeServer\r\n Content-Type: text/xml\r\n \r\n <?xml version="1.0"?>somexmldocument>\r\n
R_2.1(I₂)	<cell><field>t1</field><value>234</value><cell>\r\n <cell><field>t2</field><value>123</value><cell>\r\n
R_2.2(I₃)	<cell><field>t1</field><value>237</value><cell>\r\n
R_3.1	\r\n
R_2.3(I_i)	<cell><field>t2</field><value>119</value><cell>\r\n

Claims

Verfahren (200) zum Übertragen von Daten aus einem Server an einen Client unter Verwendung einer HTTP-Verbindung, wobei das Verfahren die Schritte umfasst: – Senden (201) nur einer Anforderung (305) von Client an den Server, wobei die Anforderung gemäß HTTP-Übertragungsprotokoll ist und eine gewisse Informationsentität (I) im Server spezifiziert, wonach es nicht erforderlich ist, dass der Client eine weitere Anforderung stellt, um die besagte gewisse Informationsentität im Server zu spezifizieren, und wobei die besagte gewisse Informationsentität zumindest teilweise kontinuierlich nach Senden der einen Anforderung aktualisiert wird; – Senden (202), unter Verwendung der HTTP-Verbindung, zu einem ersten Zeitpunkt vom Server zum Client einer ersten Antwortportion (R₁, 306), die ein erstes Informationsfragment umfasst, das sich auf die besagte Informationsentität bezieht, gemäß dem HTTP-Übertragungsprotokoll, wobei die erste Reaktionsportion weiterhin alle Vorspanninformationen der Gesamtantwort umfasst, welche die erste Antwortportion und nachfolgende zweite Antwortportionen einschließt, und einen Hauptteil einer Web-Seite, welche eine gewisse Informationsentität zeigt, und der Client nach Empfang der ersten Antwortportion dafür eingerichtet ist, weiterhin zumindest eine nachfolgende zweite Antwortportion zu akzeptieren, und – Senden (204, 208), unter Verwendung der HTTP-Verbindung, zu nachfolgenden zweiten Zeitpunkten vom Server an den Client einer Mehrzahl von zweiten Antwortportionen (R_2,i, 307, 308, 310), wobei jede dieser zweiten Portionen nur ein Informationsfragment eines aktualisierten Teils der Informationsentität und ein Skript zum Prozessieren des Informationsfragmentes von einem aktualisierten Teil der Informationsentität umfasst, wobei – der Zeitraum zwischen dem ersten Zeitpunkt und dem frühesten zweiten Zeitpunkt (205) maximal eine gewisse erste vorgegebene Zeitperiode beträgt, und – ein Zeitraum zwischen zwei aufeinanderfolgenden zweiten Zeitpunkten (209) maximal ein gewisser zweiter vorgegebener Zeitraum ist.
Verfahren gemäß Anspruch 1, weiter umfassend den Schritt: – Senden (206, 211), unter Verwendung der HTTP-Verbindung, zu nachfolgenden dritten Zeitpunkten vom Server an den Client einer Mehrzahl von dritten Antwortportionen (R_3,k, 309), wobei die dritten Portionen keine Informationsfragmente enthalten, die spezifisch für die Informationsentität sind.
Verfahren gemäß Anspruch 2, wobei zumindest eine der dritten Portionen nur Computersprachen-Anweisungen ohne das Informationsfragment enthält.
Verfahren gemäß Anspruch 2, wobei zumindest eine der dritten Portionen nur Zeilenumbruch- und/oder Zeilenvorschub-Zeichen enthält.
Verfahren gemäß Anspruch 2, wobei – der Zeitraum zwischen dem ersten Zeitpunkt und dem frühesten zweiten Zeitpunkt (205) maximal ein gewisser erster vorgegebener Zeitraum ist, und – ein Zeitraum zwischen zwei aufeinanderfolgenden Zeitpunkten der zweiten und dritten Zeitpunkte maximal ein gewisser zweiter vorgegebener Zeitraum ist (210).
Verfahren gemäß einem der vorstehenden Ansprüche, wobei die erste Portion nicht die Gesamtgröße der nachfolgenden zweiten Antwortportionen spezifiziert.
Verfahren gemäß einem der vorstehenden Ansprüche, wobei das Informationsfragment in zumindest einer der zweiten Portionen ein Informationsfragment ist, das sich auf eine Änderung in der angeforderten Informationsentität bezieht, wobei die Änderung nach dem ersten Zeitpunkt vorgenommen wird.
Verfahren gemäß einem der vorstehenden Ansprüche, wobei die Anforderung eine Hypertext-Transferprotokollanforderung ist und die Antwort, von der die erste Portion einen Teil bildet, eine Hypertext-Transferprotokollantwort ist.
Verfahren gemäß Anspruch 8, wobei die erste Portion den Inhaltslängenfeldwert unbekannt belässt.
Verfahren gemäß einem der vorstehenden Ansprüche, wobei die Computersprache eine Scriptsprache ist, Scripttags die Computersprachen-Anweisungen bilden und der Client ein Browser-Programm ist.
Verfahren gemäß einem der vorstehenden Ansprüche, wobei der Client ein Browser-Programm ist.
Verfahren gemäß einem der vorstehenden Ansprüche, wobei das Script eine Scriptsprache ist.
Verfahren gemäß Anspruch 12, wobei die Scriptsprache JavaScript, VBScript oder JScript ist.
Verfahren gemäß Anspruch 12, wobei die Scriptsprachetags die Computersprachen-Anweisungen bilden.
Verfahren gemäß einem der vorstehenden Ansprüche, wobei das Script erweiterbare Markierungs-Sprache (XML) ist.
Verfahren gemäß einem der Ansprüche 1 bis 9, wobei erweiterbare Markierungssprachenelemente Computersprachen-Anweisungen und die Informationsfragmente bilden.
Verfahren gemäß einem der vorstehenden Ansprüche, wobei die erste Portion Startvorspänne eines erweiterbaren Markierungssprachendokuments umfasst.
System (400) zum Übertragen von Daten aus einem Server an einen Client unter Verwendung einer HTTP-Verbindung, wobei das System am Server umfasst: – Mittel (410) zum Herstellen der HTTP-Verbindung, – Mittel (420) zum Empfangen von Anforderungen vom Client, wobei nur eine Anforderung eine gewisse Informationsentität im Server spezifiziert, wobei die Anforderung gemäß einem HTTP-Protokoll ist und sich auf die HTTP-Verbindung bezieht, wonach es nicht erforderlich ist, dass der Client eine andere Anforderung macht, um die gewisse Informationsentität im Server zu spezifizieren, und wobei die gewisse Informationsentität zumindest teilweise nach Senden der einen Anforderung kontinuierlich aktualisiert wird, – Mittel (430) zum Senden, als Antwort auf eine Anforderung unter Verwendung einer anforderungsspezifischen HTTP-Verbindung und zu einem anforderungsspezifischen ersten Zeitpunkt, vom Server an den Client, einer ersten Antwortportion gemäß dem HTTP-Protokoll, wobei die erste Portion ein erstes Informationsfragment umfasst, das sich auf die Informationsentität bezieht und die erste Antwortportion weiterhin alle Vorspanninformationen der gesamten Antwort umfasst, welche die erste Antwortportion und nachfolgende zweite Antwortportionen beinhaltet, und einen Hauptteil einer Web-Seite, welche eine gewisse Informationsentität zeigt, und wobei der Client nach Empfang der ersten Antwortportion dafür eingerichtet ist, weiterhin zumindest eine nachfolgende zweite Antwortportion zu akzeptieren, und – Mittel (440) zum Senden, als eine Antwort auf eine Anforderung unter Verwendung der anforderungsspezifischen HTTP-Verbindung zu nachfolgenden anforderungsspezifischen zweiten Zeitpunkten aus dem Server an den Client, einer Mehrzahl von zweiten Antwortportionen, wobei jede der zweiten Antwortportionen nur ein Informationsfragment eines aktualisierten Teils der Informationsentität und ein Script zum Verarbeiten des Informationsfragments des aktualisierten Teils der Informationsentität umfasst, wobei das System (400) dafür ausgelegt ist, die zweiten Antworten zu senden, die sich auf eine gewisse Anforderung beziehen, so dass – der Zeitraum zwischen dem anforderungsspezifischen ersten Zeitpunkt und dem frühesten anforderungsspezifischen zweiten Zeitpunkt maximal ein gewisser erster vorgegebener Zeitraum ist (205), und – ein Zeitraum zwischen zwei aufeinanderfolgenden anforderungsspezifischen zweiten Zeitpunkten maximal ein gewisser zweiter vorgegebener Zeitraum (209) ist.
System gemäß Anspruch 18, weiterhin umfassend Mittel (405) zum Senden, als eine Antwort auf eine Anforderung, unter Verwendung der anforderungsspezifischen HTTP-Verbindung, zu aufeinanderfolgenden anforderungsspezifischen dritten Zeitpunkten aus dem Server an den Client, einer Mehrzahl von dritten Antwortportionen, wobei die dritten Portionen keine Informationsfragmente der Informationsentität enthalten.
System gemäß Anspruch 19, wobei es dafür ausgelegt ist, die sich auf eine gewisse Anforderung beziehenden zweiten und dritten Portionen so zu senden, dass – der Zeitraum zwischen dem anforderungsspezifischen ersten Zeitpunkt und dem frühesten anforderungsspezifischen zweiten Zeitpunkt maximal ein gewisser erster vorgegebener Zeitraum ist, und – ein Zeitraum zwischen zwei aufeinanderfolgenden Zeitpunkten der anforderungsspezifischen zweiten und dritten Zeitpunkte maximal ein gewisser zweiter vorgegebener Zeitraum ist.
System gemäß Anspruch 18, wobei das System sich im Server befindet.
Computerprogrammprodukt (400) zum Übertragen von Daten aus einem Server an einen Client unter Verwendung einer HTTP-Verbindung, wobei das Computerprogrammprodukt Computercodemittel (420, 430, 440) umfasst, um, wenn auf dem Server ausgeführt: – Anforderungen vom Client zu empfangen, wo nur eine, eine gewisse Informationsentität (I) im Server spezifizierende Anforderung, wobei die Anforderung gemäß einem HTTP-Protokoll erfolgt und sich auf die HTTP-Verbindung bezieht, wonach es nicht notwendig ist, dass der Client eine andere Anforderung machen muss, um die gewisse Informationsentität im Server zu spezifizieren und wobei die gewisse Informationsentität zumindest teilweise kontinuierlich nach Senden der einen Anforderung aktualisiert wird, – als Antwort auf eine Anforderung, unter Verwendung einer anforderungsspezifischen HTTP-Verbindung und zu einem anforderungsspezifischen ersten Zeitpunkt vom Server an den Client, eine erste Antwortportion gemäß dem HTTP-Protokoll zu senden, wobei die erste Portion ein erstes Informationsfragment umfasst, das sich auf die Informationsentität bezieht, wobei die erste Antwortportion weiterhin alle Vorspanninformationen der gesamten Antwort umfasst, welche die erste Antwortportion und nachfolgende zweite Antwortportionen beinhaltet, und einen Hauptteil einer Web-Seite, welche eine gewisse Informationsentität zeigt, und der Client nach Empfang der ersten Antwortportion dafür ausgelegt ist, weiterhin zumindest eine nachfolgende zweite Antwortportion zu akzeptieren, und – als eine Antwort auf eine Anforderung unter Verwendung der anforderungsspezifischen HTTP-Verbindung zu nachfolgenden anforderungsspezifischen zweiten Zeitpunkten vom Server zum Client eine Mehrzahl von zweiten Antwortportionen zu senden, wobei jede der zweiten Portionen nur ein Informationsfragment eines aktualisierten Teils der Informationsentität und ein Script zum Bearbeiten des Informationsfragmentes des aktualisierten Teils der Informationsentität umfasst, – die sich auf eine gewisse Anforderung beziehenden zweiten Antworten so zu senden, dass – der Zeitraum zwischen dem anforderungsspezifischen ersten Zeitpunkt und dem frühesten anforderungsspezifischen zweiten Zeitpunkt maximal ein gewisser erster vorgegebener Zeitraum ist (205), und – ein Zeitraum zwischen zwei aufeinanderfolgenden anforderungsspezifischen zweiten Zeitpunkten maximal ein gewisser zweiter vorgegebener Zeitraum ist (209).
Das Computerprogrammprodukt nach Anspruch 22 speicherndes, computerlesbares Medium.