DE602004002603T2

DE602004002603T2 - Empfangsbestätigung für einen Inhalt zu einer HTTP/TCP Vorrichtung

Info

Publication number: DE602004002603T2
Application number: DE602004002603T
Authority: DE
Inventors: James BT32 3LT Clarke; M. John BT9 7JL Coughlan
Original assignee: Openwave Systems Inc
Current assignee: Great Elm Group Inc
Priority date: 2003-02-28
Filing date: 2004-02-27
Publication date: 2007-08-16
Anticipated expiration: 2024-02-28
Also published as: US7911994B2; ATE341890T1; DE602004002603D1; US20040205231A1; EP1453275B1; US8542582B2; EP1453275A1; US20100042739A1

Description

GEBIET DER ERFINDUNG
Diese Erfindung betrifft das Gebiet der drahtlosen Kommunikation. Insbesondere betrifft diese Erfindung die Bestätigung der Zuführung von Daten von einem Proxy oder einem Server eines drahtlosen Betreibernetzwerkes zu einem Client ohne eine spezifische Meldung von dem Client.
ALLGEMEINER STAND DER TECHNIK
Der elektronische Handel (E-Commerce) ist in der heutigen Gesellschaft immer wichtiger geworden. Die Leute tätigen mithilfe ihrer Computer (PCs), Laptops, PDAs (Personal Digital Assistants), Mobiltelefone usw. Einkäufe im Internet. Die Leute können insbesondere Text, Symbole, Videos, Musik und anderen immateriellen Inhalt kaufen, der bei Bedarf zu ihrer mobilen Kommunikationseinrichtung geliefert wird. In der Regel wird die Anforderung des Inhalts und die Antwort mithilfe von HTTP (Hypertext Transfer Protocol) gesendet.
In der Regel wird die HTTP-Antwort zwischen Systemen übertragen, die TCP (Transfer Control Protocol) implementieren. Wenn eine auf HTTP basierende Anwendung Daten der HTTP-Antwort mithilfe eines aus einer Anzahl von Schreibbefehlen in einen von einem Betriebssystem bereitgestellten TCP-Socket schreibt, werden die Daten in einem TCP-Sendepuffer für diesen Socket abgelegt, und der Schreibbefehl kehrt zurück. Im Allgemeinen gibt die Tatsache, dass der Schreibbefehl zurückgekehrt ist, lediglich an, dass die Daten in den TCP-Sendepuffer geschrieben worden sind, und ein zurückkehrender Schreibbefehl bestätigt nicht, dass die Daten an den TCP-Empfangsstapelspeicher gesendet worden sind.
Nach dem Erhalt der Daten überträgt der TCP-Empfänger eine oder mehrere Rückmeldungen an den Sender, um den erfolgten Empfang der Datensegmente anzuzeigen. Der TCP-Empfänger sendet eine Endrückmeldung, die auch als letztes ACK-Signal bezeichnet wird und den Empfang des Endsegments der Daten anzeigt, an den TCP-Sender. Die standardmäßige TCP-Socket-API (Application Program Interface) schickt jedoch keine Meldung über den Empfang des letzten ACK-Signals an die sendende Anwendung, um den erfolgten Empfang der Daten durch den TCP-Empfänger zu bestätigen.
Bei der bisherigen Technik ist es nicht möglich, auf HTTP-Ebene festzustellen, ob die HTTP-Antwort erfolgreich auf der anfordernden Seite, d.h. bei dem HTTP-Client, angekommen ist. HTTP enthält in der Regel keine Funktionen, mit deren Hilfe ein HTTP-Client dem Server oder einem Proxy, der die HTTP-Antwort sendet, den Empfang der HTTP-Antwort bestätigen kann. Wenn jedoch ein Kommunikationsnetzbetreiber dem Benutzer für den Empfang der Daten oder des Inhalts in der HTTP-Antwort Gebühren berechnen will, dann ist die Möglichkeit festzustellen, dass die HTTP-Antwort erfolgreich angekommen ist, für die ordnungsgemäße kundenbezogene Gebührenerfasssung für derartige Dienstleistungen wichtig.
Mindestens zwei potenzielle Lösungen für das obige Problem erweisen sich als nicht zufriedenstellend. Eine Lösung schlägt vor, HTTP so zu erweitern, dass es Funktionen unterstützt, über die der Client den erfolgten Empfang der HTTP-Antwort anzeigen kann. Solche zusätzlichen Funktionalitäten müssten von den relevanten Normfestsetzungsinstitutionen erfolgreich akzeptiert werden, um sicherzustellen, dass die zukünftigen HTTP-kompatiblen Einrichtungen die zusätzlichen Funktionalitäten unterstützen.
Eine weitere potenzielle Lösung besteht darin, den TCP-Stapelspeicher so zu modifizieren, dass er die letzte Übertragungsrückmeldung der HTTP-Antwort auffängt, und die standardmäßige TCP-API so zu erweitern, dass der TCP-Stapelspeicher der auf HTTP basierenden, sendenden Anwendung den Datenempfang anzeigen kann. Da die meisten TCP-Speicher jedoch mit einem Betriebssystem verschickt werden, ist es schwierig, wenn nicht gar praktisch unmöglich, die TCP-Stapelspeicher zu modifizieren. Das Erzeugen eines separaten TCP-Stapelspeichers zusätzlich zu den mit dem Betriebssystem von einem Diensteanbieter verschickten TCP-Stapelspeichern ist darüber hinaus zeitaufwändig sowie praktisch unmöglich. Die Patentanmeldung US 2001/003164 lehrt ein Verfahren für das sichere Abschalten, bei dem festgestellt wird, ob der TCP-Sendepuffer leer ist, um sicherzustellen, dass alle abgehenden Daten vor dem Ausschalten von dem Empfänger empfangen worden sind.
KURZFASSUNG
Es werden ein Verfahren nach Anspruch 1 und eine Vorrichtung nach Anspruch 13 offengelegt. Eine Ausführungsform des Verfahrens umfasst das Bestimmen, wann eine vorgegebene Menge Daten aus einem Sendepuffer entfernt worden ist, und das Senden einer Bestätigung, wenn die vorgegebene Menge Daten aus dem Sendepuffer entfernt worden ist.
Bei einer bestimmten Ausführungsform der vorliegenden Erfindung implementiert der Sende-Socket ein TCP (Transport Control Protocol).
Andere Merkmale der vorliegenden Erfindung ergeben sich aus den beiliegenden Zeichnungen und aus der nachfolgenden ausführlichen Beschreibung.
KURZE BESCHREIBUNG DER ZEICHNUNGEN
Die vorliegende Erfindung wird in den Figuren der beiliegenden Zeichnungen, in denen gleiche Bezugszeichen ähnliche Elemente anzeigen, im Sinne von Beispielen und nicht im Sinne von Einschränkungen dargestellt.
1 stellt eine Ausführungsform eines drahtlosen Kommunikationssystems dar, das eine Bestätigung für die Zuführung von Daten bereitstellt,
2 stellt ein Ablaufdiagramm einer Ausführungsform eines Prozesses dar, in dem die Zuführung von Daten von einem Betreibernetzwerk zu einer Client-Einrichtung bestätigt wird, und
3 stellt eine beispielhafte Ausführungsform eines drahtlosen Kommunikationssystems dar.
AUSFÜHRLICHE BESCHREIBUNG
In der nachfolgenden Beschreibung werden zahlreiche spezifische Einzelheiten erläutert. Es versteht sich jedoch, dass Ausführungsformen der Erfindung auch ohne diese spezifischen Einzelheiten in die Praxis umgesetzt werden können. In anderen Fällen sind allgemein bekannte Schaltungen, Strukturen und Techniken nicht ausführlich gezeigt worden, um die Verständlichkeit dieser Beschreibung nicht zu beeinträchtigen.
Die Erwähnung von „einer Ausführungsform" in der Beschreibung bedeutet, dass eine bestimmte Funktion, ein bestimmter Aufbau oder ein bestimmtes Merkmal, die im Zusammenhang mit der Ausführungsform beschrieben worden sind, in mindestens einer Ausführungsform der Erfindung enthalten sind. Der an verschiedenen Stellen in der Beschreibung vorkommende Ausdruck „bei einer Ausführungsform" bezieht sich nicht unbedingt in jedem Fall auf die gleiche Ausführungsform.
Einige Abschnitte der nachfolgenden ausführlichen Beschreibung werden als Algorithmen und symbolische Darstellungen der Operationen an Datenbits in einem Computerspeicher dargestellt. Bei diesen algorithmischen Beschreibungen und Darstellungen handelt es sich um die Werkzeuge, die von Fachleuten im Bereich Datenverarbeitung dazu verwendet werden, den Gegenstand ihrer Arbeit anderen Fachleuten auf die effektivste Art und Weise nahezubringen. Ein Algorithmus wird hier und allgemein als selbstkonsistente Abfolge von Operationen verstanden, die zu einem gewünschten Ergebnis führt. Bei diesen Operationen handelt es sich um jene, die physische Manipulationen physikalischer Größen erfordern. In der Regel liegen diese Größen in Form von elektrischen oder magnetischen Signalen vor, die gespeichert, übertragen, kombiniert, verglichen und anderweitig manipuliert werden können, dies ist jedoch nicht unbedingt der Fall. Es hat sich gelegentlich als praktisch erwiesen, diese Signale hauptsächlich zu allgemeinen Verwendungszwecken als Bits, Werte, Elemente, Symbole, Zeichen, Ausdrücke, Zahlen oder dergleichen zu bezeichnen.
Man sollte sich jedoch daran erinnern, dass all diese und ähnliche Begriffe mit den entsprechenden physikalischen Größen verbunden werden müssen und lediglich praktische Bezeichnungen darstellen, die für diese Größen verwendet werden. Soweit nicht in der nachfolgenden Erläuterung ausdrücklich etwas anderes angegeben ist, versteht es sich, dass sich in der gesamten Beschreibung Erläuterungen, die Begriffe wie „Verarbeiten" oder „Berechnen" oder „Rechnen" oder „Ermitteln" oder „Anzeigen" oder dergleichen verwenden, auf die Funktion und die Prozesse eines Computersystems oder einer ähnlichen elektronischen Recheneinrichtung beziehen, das/die Daten, die als physikalische (elektronische) Größen in den Registern und Speichern des Computersystems repräsentiert sind, zu anderen Daten manipuliert und transformiert, die auf ähnliche Weise als physikalische Größen in den Speichern oder Registern des Computersystems oder anderer derartiger Informationsspeicher-, Übertragungs- oder Anzeigeeinrichtungen repräsentiert sind.
Die vorliegende Erfindung betrifft ebenfalls eine Vorrichtung für das Durchführen der hier beschriebenen Operationen. Diese Vorrichtung kann speziell für die erforderlichen Zwecke konstruiert werden oder einen Mehrzweck-Computer umfassen, der von einem in dem Computer enthaltenen Computerprogramm gezielt aktiviert oder rekonfiguriert wird. Ein solches Computerprogramm kann in einem vom Computer lesbaren Speichermedium gespeichert werden, bei dem es sich unter anderem um eine beliebige Art von Diskette einschließlich Floppy-Disks, optischer Disketten, CD-ROMs und magnetooptischer Disketten, Festwertspeicher (ROMs), Direktzugriffspeicher (RAMs), EPROMs, EEPROMs, magnetischer oder optischer Karten oder beliebige Arten von Medien handelt, die sich für das Speichern elektronischer Anweisungen eignen und die jeweils mit einem Computersystembus gekoppelt sind.
Die hier dargestellten Prozesse und Displays betreffen an sich keinen bestimmten Computer beziehungsweise keine andere Vorrichtung. Es können verschiedene Mehrzwecksysteme mit Programmen gemäß den hierin enthaltenen Lehren verwendet werden, oder es kann sich als praktisch erweisen, eine stärker spezialisierte Vorrichtung zu konstruieren, die die beschriebenen Operationen durchführt. Der für zahlreiche dieser Systeme erforderliche Aufbau ergibt sich aus der nachfolgenden Beschreibung. Die vorlie gende Erfindung wird außerdem nicht unter Bezugnahme auf eine bestimmte Programmiersprache beschrieben. Es versteht sich, dass eine Vielzahl von Programmiersprachen für das Implementieren der hier beschriebenen Lehren der Erfindung verwendet werden kann.
Zu einem maschinenlesbaren Medium gehört jeder Mechanismus für das Speichern oder Übertragen von Informationen in einer von einer Maschine (z.B. einem Computer) lesbaren Form. Zu einem maschinenlesbaren Medium gehören beispielsweise Festwertspeicher (ROM), Direktzugriffsspeicher (RAM), magnetische Diskettenspeichermedien, optische Speichermedien, Flash-Speichereinrichtungen, elektrische, optische, akustische oder andere Formen von weitergeleiteten Signalen (z.B. Trägerwellen, Infrarotsignale, Digitalsignale usw.) usw.
1 stellt eine Ausführungsform eines drahtlosen Kommunikationssystems dar, das eine Bestätigung für die Zuführung von Daten bereitstellt. Das System 100 enthält eine Einrichtung 110 eines Betreibernetzwerkes, einen Sende-Socket 120 mit einem Sendepuffer 122 und einem Stapelspeicher 123, einen Empfangs-Socket 130 mit einem Empfangspuffer 132 und einem Stapelspeicher 133 und eine Client-Einrichtung 140. Die Einrichtung 110 kann einen Proxy oder einen Server enthalten. Deshalb wird die Einrichtung 110 in der nachfolgenden Beschreibung auch als Proxy/Server 110 bezeichnet. Bei der Client-Einrichtung 140 kann es sich um eine mobile Kommunikationseinrichtung wie beispielsweise ein Mobiltelefon, einen Mobilfunkempfänger, einen elektronischen Assistenten (PDA) usw. handeln.
Verschiedene Ausführungsformen des Systems 100 können unterschiedliche Protokolle für das Übertragen der Daten implementieren. Das System 100 kann beispielsweise eine Version eines TCP (Transmission Control Protocol) ohne spezifischen Rückmeldemechanismus implementieren. Dann kann es sich bei den Stapelspeichern 123 und 133 in dem System 100 um TCP-Stapelspeicher handeln. Zu Beispielen für Betriebssysteme, die TCP-Stapelspeicher bereitstellen, gehören Solaris von Sun Microsystems, Inc. (Santa Clara, Kalifornien, USA), AIX von der International Business Machine Corporation (Armonk, New York, USA) usw. TCP-Stapelspeicher stellen in der Regel eine standardmäßige API für das Verwalten und Verwenden von Sockets zur Verfügung.
Bei einer Ausführungsform sendet eine auf HTTP basierende Anwendung 112 der Einrichtung 110 des Betreibernetzwerkes Daten zu der Client-Einrichtung 140. Die auf HTTP basierende Anwendung 112 kann die Daten als Reaktion auf eine Anforderung von einer HTTP-Client-Anwendung 142 der Client-Einrichtung 140 senden.
Die auf HTTP basierende Anwendung 112 überträgt Daten durch Schreiben der Daten in einen Sende-Socket unter Verwendung eines entsprechenden API-Befehls, wie beispielsweise „Writen" oder „Write" für einen TCP-Socket. Der Vorgang des Schreibens der Daten in den Sende-Socket 120 führt dazu, dass die Daten in dem Sendepuffer 122 abgelegt und nicht direkt zu dem TCP-Empfangs-Socket 130 des Client 140 gesendet werden. Der TCP-Sende-Socket 120 ruft die Daten von dem Sendepuffer 122 ab und überträgt sie den im TCP definierten Regeln entsprechend über den TCP-Stapelspeicher 123 zu dem TCP-Empfangs-Socket 130 der Client-Einrichtung 140. Nach Empfang der Daten am Empfangs-TCP-Stapelspeicher 133 werden diese in dem TCP-Empfangspuffer 132 abgelegt, so dass die Daten für die HTTP-Client-Anwendung 142 zur Verfügung stehen. Dann sendet der TCP-Empfangs-Socket 130 Rückmeldungen zu dem TCP-Sende-Socket 120, um den Empfang der Daten anzuzeigen. Der TCP-Sende-Socket 120 kann die Daten den Regeln des TCP entsprechend dem TCP-Empfangs-Socket 130 zuführen, und zwar möglicherweise in Form mehrerer Segmente und möglicherweise mit wiederholten Übertragungen.
Bei einer Ausführungsform wird der TCP-Sendepuffer 122 überwacht, um zu ermitteln, wann der TCP-Sende-Socket 120 alle Daten aus dem TCP-Sendepuffer 122 entfernt hat. Der TCP-Sende-Socket 120 entfernt die Daten aus dem TCP-Sendepuffer 122, wenn sie dem TCP-Empfangs-Socket 130 erfolgreich zugeführt worden sind. Somit lässt sich dadurch, dass ermittelt wird, wann der TCP-Sende-Socket 120 den Sendepuffer 122 gelöscht hat, schlussfolgern, dass die Client-Einrichtung 140 die Daten erfolgreich empfangen hat.
Um zu ermitteln, wann der TCP-Sendepuffer 122 gelöscht worden ist, kann eine Bestätigungszuführanwendung des Proxy/Servers 110 die Größe des TCP-Sendepuffers 122 mithilfe von Socket-Optionen ermitteln. Die Bestätigungszuführanwendung kann ein Bestandteil der auf HTTP basierenden Anwendung 112 oder ein im Wesentlichen von dieser Anwendung 112 unabhängiges Software-Modul sein. Die Bestätigungszuführanwendung stellt einen Schwellwert, der auch als „Ebbemarke" bezeichnet wird, so ein, dass er gleich der Größe des TCP-Sendepuffers 122 ist. Daher definiert die „Ebbemarke" im Wesentlichen, wie viel Platz in dem Sendepuffer 122 sein muss, damit er als zum Schreiben verfügbar betrachtet werden kann. Die „Ebbemarke" des Sendepuffers wird mit dem Auswahl-Befehl der Socket-API so verwendet, dass der Auswahl-Befehl zu der auf HTTP basierenden Anwendung 112 zurückkehrt, wenn der verfügbare Platz des Sendepuffers 122 die „Ebbemarke" erreicht.
Wie oben erläutert werden die Daten, wenn sie in den Sende-Socket 120 geschrieben worden sind, in dem TCP-Sendepuffer 122 abgelegt. Dann gibt die auf dem Proxy/Server 110 laufende Bestätigungszuführanwendung einen Befehl für den Sende-Socket 120 aus: den Auswahl-Befehl der Socket-API. Bei einer Ausführungsform kehrt der Auswahl-Befehl zurück, wenn der verfügbare Platz im Sendepuffer die „Ebbemarke" des Sendepuffers erreicht. Da der Wert der „Ebbemarke" des Sendepuffers gleich der Größe des Sendepuffers 122 ist, kehrt der Auswahl-Befehl zurück, wenn der Sendepuffer 122 leer ist, und gibt dadurch an, dass die in den Sendepuffer 122 geschriebenen Daten dem Empfangs-TCP-Stapelspeicher 133 zugeführt worden sind.
2 stellt ein Ablaufdiagramm einer Ausführungsform eines Prozesses dar, in dem die Zuführung von Daten von einem Netzträger zu einer Client-Einrichtung bestätigt wird. Der Prozess wird von Ablauflogik durchgeführt, die Hardware (z.B. Schaltungen, spezielle dafür vorgesehene Logik usw.), Software (wie beispielsweise die oben erläuterte Bestätigungszuführanwendung), die auf einem Mehrzweck-Computersystem oder einer speziell dafür vorgesehenen Maschine (z.B. dem Proxy/Server in 1) läuft, oder eine Kombination aus beiden umfassen kann.
Die Ablauflogik ermittelt zunächst die Größe eines Sendepuffers eines Sende-Sockets (Ablaufblock 210). Die Ablauflogik stellt einen Schwellwert ein, der auch als „Ebbemarke" bezeichnet wird und gleich der Größe des Sendepuffers ist (Ablaufblock 220). Um Daten von dem Netzträger zu senden, schreibt die Ablauflogik die Daten in den Sendepuffer (Ablaufblock 230). Die Ablauflogik gibt einen Befehl für den Sende-Socket aus, so dass der Befehl zurückkehrt, wenn der verfügbare Platz in dem Sendepuffer den Schwellwert erreicht (Ablaufblock 240). Das Betreibernetzwerk implementiert TCP. Bei dem für den Sende-TCP-Socket ausgegebenen Befehl handelt es sich um einen Auswahl-Befehl der Socket-API.
Ein Vorteil der Verwendung eines bestehenden TCP-Socket-API-Befehls besteht darin, dass für Kompatibilität mit den bereits auf dem Markt existierenden TCP-Einrichtungen gesorgt wird. Die Verwendung des bestehenden TCP-Socket-API-Befehls reduziert außerdem den Überhang an Datenübertragung durch Vermeiden des Hinzufügens zusätzlicher Nachrichten zum Protokoll, um eine spezifische Rückmeldung zu unterstützen. Darüber hinaus erhöht sich durch die Verwendung des bestehenden TCP-Socket-API-Befehls das Verkehrsaufkommen im Netzwerk nicht, was besonders für die Mobilkommunikation von Bedeutung ist.
3 stellt eine beispielhafte Ausführungsform eines Mobilkommunikationssystems dar, bei dem die Erfindung implementiert werden kann. Das System 300 enthält ein drahtloses Betreibernetzwerk 310, einen Proxy/Server 315, eine Anzahl TCP-Sockets 320 und eine Anzahl mobiler Kommunikationseinrichtungen 330. Das drahtlose Netzwerk 310 sendet mithilfe eines der TCP-Sockets 320 Daten über den Proxy/Server 315 zu einer der mobilen Kommunikationseinrichtungen 330. Die TCP-Sockets 320 können bidirektional sein. Zu Erläuterungszwecken wird bei der nachfolgenden Beschreibung davon ausgegangen, dass die Daten zu der empfangenden mobilen Kommunikationseinrichtung 332 gesendet werden. Bei einer Ausführungsform baut die mobile Kommunikationseinrichtung 332 eine TCP-Verbindung mit dem Proxy/Server 315 auf. Infolgedessen wird an dem Proxy/Server-Ende 315 der Verbindung für den Proxy/Server 315 ein erster Socket erzeugt. Der Proxy/Server 315 kann den ersten Socket für das Senden oder das Empfangen von Daten von der mobilen Kommunikationseinrichtung 332 benutzen. Auf die gleiche Weise wird an dem anderen Ende der Verbindung ein zweiter Socket für die Empfangseinrichtung 332 erzeugt, die den zweiten Socket für das Senden oder das Empfangen von Daten von dem Proxy/Server 315 benutzen kann.
Um eine Bestätigung der Datenzufuhr zum Proxy/Server 315 zu ermöglichen, ermittelt eine auf dem Proxy/Server 315 laufende Bestätigungszuführanwendung zunächst die Größe des Sendepuffers eines der TCP-Sockets 320, der nachfolgend als Sende-Socket bezeichnet wird. Dann wird ein Schwellwert, der auch als „Ebbemarke" bezeichnet wird, so eingestellt, dass er gleich der Größe des Sendepuffers ist. Nach dem Schreiben der Daten in den Sendepuffer des Sende-Sockets gibt die Bestätigungszuführanwendung einen Befehl für den Sende-Socket aus. Bei dem ausgegebenen Befehl handelt es sich um einen Auswahl-Befehl der Socket-API.
Wenn der verfügbare Platz des Sendepuffers den Schwellwert erreicht, wird der Auswahl-Befehl zum Proxy/Server 315 zurückgeschickt. Da der Schwellwert gleich der Größe des Sendepuffers ist und der verfügbare Platz des Sendepuffers den Schwellwert erreicht, ist der Sendepuffer daher leer. Da der Sende-Socket Daten aus dem Sendepuffer entfernt, wenn die Rückmeldung über den Datenempfang von einem Empfangs-Socket empfangen worden ist, bei dem es sich um einen der TCP-Sockets 320 handelt, lässt sich aus dem leeren Sendepuffer ableiten, dass der Empfangs-Socket alle in den Sendepuffer geschriebenen Daten empfangen hat. Daher kann die Bestätigungszuführanwendung, wenn der Auswahl-Befehl zum Proxy/Server 315 zurückgeschickt wird, bestätigen, dass der Empfangs-Socket der mobilen Kommunikationseinrichtung 332 die Daten empfangen hat.
Die Fähigkeit, die Zuführung von Daten zu bestätigen, ermöglicht es dem drahtlosen Betreibernetzwerk 310, für die mobilen Kommunikationseinrichtungen 330 zuverlässigere Kommunikationsdienste zur Verfügung zu stellen. Des Weiteren unterstützt die Fähigkeit, die Zuführung von Daten zu bestätigen, den Netzwerkbetreiber dabei, den Benutzern der Client-Einrichtungen 330 die Daten für gelieferten Inhalt ordnungsgemäß in Rechnung zu stellen, was für die Kundenzufriedenheit wichtig ist.
Die vorliegende Erfindung wurde zwar unter Bezugnahme auf spezifische Ausführungsbeispiele beschrieben, es ist jedoch offensichtlich, dass verschiedene Modifikationen und Veränderungen an diesen Ausführungsformen vorgenommen werden können, ohne dass vom Schutzumfang der in den Ansprüchen dargelegten Erfindung abgewichen wird. Dementsprechend müssen die Beschreibung und die Zeichnungen im Sinne von Erläuterungen und nicht im Sinne von Einschränkungen betrachtet werden.

Claims

Verfahren zum Bestätigen der Zuführung einer HTTP-Antwort zu einer Empfangseinrichtung über einen Sende-Socket, das Folgendes umfasst: Empfangen (2) eines Auswahl-Befehls der Socket-API von einer Sendeeinrichtung (110) am Sende-Socket (120), wobei der Befehl einen vorgegebenen Schwellwert enthält, der gleich der Größe eines Sendepuffers (122) ist, und Zurückschicken (8) des Befehls an die Sendeeinrichtung, um die Zuführung der HTTP-Antwort zu bestätigen, wenn ein verfügbarer Platz im Sendepuffer (122) des Sende-Sockets den vorgegebenen Schwellwert erreicht.
Verfahren nach Anspruch 1, das des Weiteren das Bestimmen einer Größe des Sendepuffers (122) umfasst.
Verfahren nach Anspruch 1, das des Weiteren das Entfernen der Daten aus dem Sendepuffer (122) umfasst, nachdem die Daten einem Empfangs-Socket (130) der Empfangseinrichtung (140) zugeführt worden sind.
Verfahren nach Anspruch 3, das des Weiteren das Empfangen einer Rückmeldung vom Empfangs-Socket (130) umfasst, nachdem der Empfangs-Socket (130) die Daten empfangen hat.
Verfahren nach Anspruch 3, bei dem zu dem Sende- und dem Empfangs-Socket mindestens ein TCP-Socket (TCP = Transfer Control Protocol) gehört.
Verfahren nach Anspruch 1, bei dem die Sendeeinrichtung einen Server (110) umfasst.
Verfahren nach Anspruch 6, bei dem eine HTTP-Client-Anwendung (HTTP = Hypertext Transfer Protocol), die auf der Empfangseinrichtung (140) läuft (142), die Daten anfordert und eine auf HTTP basierende Anwendung (112), die auf dem Server (110) läuft, die Daten sendet.
Verfahren nach Anspruch 1, bei dem die Sendeeinrichtung einen Proxy (110) umfasst.
Verfahren nach Anspruch 1, bei dem die Empfangseinrichtung eine Mobilkommunikationseinrichtung (332) umfasst.
Verfahren nach Anspruch 1, das des Weiteren das Bestimmen umfasst, ob der verfügbare Platz in dem Sendepuffer als Reaktion auf den empfangenen Befehl den vorgegebenen Schwellwert erreicht.
Verfahren nach Anspruch 10, das des Weiteren das Überwachen des verfügbaren Platzes in dem Sendepuffer (122) umfasst.
Verfahren nach Anspruch 1, das des Weiteren Folgendes umfasst: Schreiben der Daten in den Sendepuffer, so dass sie von dem Sende-Socket extrahiert und zur Empfangseinrichtung gesendet werden, und Ausgeben eines Befehls an den Sende-Socket, damit dieser eine Bestätigung zurückschickt, wenn alle Daten aus dem Sendepuffer entfernt worden sind.
Vorrichtung, die Folgendes umfasst: eine Sendeeinrichtung (110), die mit einer Empfangseinrichtung (140) in einem Kommunikationsnetz gekoppelt ist, und einen Sende-Socket (120) einschließlich eines Sendepuffers (122), über den die Sendeeinrichtung (110) Daten an die Empfangseinrichtung (140) sendet, wobei der Sende-Socket von der Sendeeinrichtung einen Auswahl-Befehl der Socket-API empfängt (2), der einen vorgegebenen Schwellwert enthält, der gleich der Größe des Sendepuffers (122) ist, und des Weiteren den Befehl an die Sendeeinrichtung zurückschickt (8), um die Zuführung einer HTTP-Antwort zu bestätigen, wenn ein verfügbarer Platz im Sendepuffer den vorgegebenen Schwellwert erreicht.
Vorrichtung nach Anspruch 13, bei der die Empfangseinrichtung (140) mit einem Empfangs-Socket (130) gekoppelt ist und die Daten empfängt und der Empfangs-Socket (130) nach Empfang der Daten eine Rückmeldung an den Sende-Socket (120) sendet.
Vorrichtung nach Anspruch 14, bei der der Sende-Socket (120) die Daten aus dem Sendepuffer (122) entfernt, wenn er die Rückmeldung empfangen hat.
Vorrichtung nach Anspruch 13, bei der die Sendeeinrichtung Folgendes umfasst: einen Prozessor, ein Speichermedium, das Anweisungen speichert, die, wenn sie von dem Prozessor ausgeführt werden, dafür sorgen, dass der Prozessor mehrere Operationen durchführt, die Folgendes umfassen: Übertragen der Daten zu der Empfangseinrichtung über den Sende-Socket, der einen TCP-Socket (TCP = Transfer Control Protocol) umfasst, und Ausgeben des Befehls an den TCP-Socket.
Vorrichtung nach Anspruch 16, bei der die mehreren Operationen des Weiteren Folgendes umfassen: Bestimmen der Größe des TCP-Sendepuffers; und Einstellen des Schwellwertes, so dass er gleich der Größe des TCP-Sendepuffers ist.
Vorrichtung nach Anspruch 13, bei der die Sendeeinrichtung einen Server umfasst.
Vorrichtung nach Anspruch 13, bei der die Sendeeinrichtung einen Proxy umfasst.
Vorrichtung nach Anspruch 13, bei der die Empfangseinrichtung eine Mobilkommunikationseinrichtung umfasst.
Vorrichtung nach Anspruch 14, bei der zu dem Sende- und dem Empfangs-Socket mindestens ein TCP-Socket (TCP = Transfer Control Protocol) gehört.
Vorrichtung nach Anspruch 13, die des Weiteren Folgendes umfasst: Mittel zum Zuführen von Daten aus der Sendeeinrichtung zur Empfangseinrichtung über den Sende-Socket, Mittel zum Bestimmen, wann die vorgegebene Menge Daten aus dem Sendepuffer entfernt worden ist, und Mittel, die dafür sorgen, dass der Sende-Socket die Bestätigung zurückschickt.