Die vorliegende Erfindung bezieht sich im Allgemeinen auf Computernetzwerke und im Besonderen auf ein System und ein Verfahren zum Aufrechterhalten einer Netzwerkverbindung.

Bei bestimmten Netzwerkverbindungen, z.B. bei Verbindungen, die über HTTP-(Hypertext Transfer Protocol) hergestellt werden, kann es erwünscht sein, eine persistente Verbindung zwischen dem Client und dem Webserver aufrechtzuerhalten, um den zusätzliche Aufwand zu verringern, der mit der erneuten Herstellung der Verbindung verbunden ist. Allerdings können NAT-Gateways (Network Address Translation) und andere Ausrüstung, die sich entlang dem Verbindungsweg befinden, nach einer vordefinierten Zeitdauer die Verbindung in dem Fall beenden, dass die Verbindung in den Leerlauf übergeht.

Um das NAT-Gateway daran zu hindern, die Verbindung zu beenden, ist es bekannt, in regelmäßigen Zeitabständen so genannte "Keep-Alive"-Pakete vom Client zum Webserver zu senden. Solche Keep-Alive-Pakete enthalten keine wirklichen Transaktionsinformationen und haben keine Auswirkung auf den Status der Daten zwischen dem Client und dem Webserver, sondern sie werden lediglich verwendet, um das NAT-Gateway daran zu hindern, die Verbindung zu beenden. Typischerweise werden Keep-Alive-Pakete aggressiv gesendet, d.h. ohne Rücksicht auf die vom NAT-Gateway verwendeten eigentlichen Parameter, wodurch eine universelle Strategie zur Offenhaltung der Verbindung implementiert wird.

Allerdings sind diese Verfahren zur Aufrechterhaltung persistenter Verbindungen nach dem Stand der Technik nur für Kanäle ohne Bandbreitenbeschränkung ideal geeignet. Damit ist diese Strategie bei Medien mit eingeschränkter Bandbreitenverfügbarkeit wie zum Beispiel bei Drahtlosnetzwerkkanälen verschwenderisch im Umgang mit wertvoller Bandbreite. Dieses Verfahren nach dem Stand der Technik ist auch für batteriebetriebene Geräte unerwünscht, wo die aggressive Zustellung von Keep-Alive-Paketen zu einer beschleunigten Entladung der Batterie führen könnte.

US6006259 offenbart ein Netzwerk-Clustering-System, das seinen Komponentennachrichtendurchsatz durch eine adaptive Lastverteilung optimiert. Der Cluster sieht nach außen aus wie ein einzelnes Gerät und funktioniert als ein Vermittler wie z.B. ein Gateway, eine Firewall oder ein Router. Er besteht aus einer Anzahl identischer Mitglieder, von denen eines die Rolle eines Masters einnimmt. Alle Mitglieder, also Master und Nicht-Master, sind über physische Netzwerklinks verbunden. Der Master kann ein Mitglied trennen, wenn das Mitglied nicht innerhalb einer bestimmten Zeitspanne ein Keep-Alive-Signal an den Master sendet. Die Zeitspanne wird vom Master aus Informationen über den Paketverlust ermittelt, die aus den Keep-Alive-Signalen des Mitglieds gewonnen werden. Die Mitglieder sind damit vom Master abhängig, der die Keep-Alive-Signal-Periode ermittelt und diese zu ihnen kommuniziert.

Es ist eine Aufgabe, ein neuartiges System und Verfahren zum Aufrechterhalten einer Netzwerkverbindung bereitzustellen, wodurch zumindest einer der oben beschriebenen Nachteile des Stands der Technik vermindert oder überwunden wird.

Ein Aspekt der Erfindung umfasst die Bereitstellung eines elektronischen Geräts mit einer Netzwerkschnittstelle zur Kommunikation mit einem zweiten Gerät über eine Netzwerkverbindung, die über einen physischen Link abgewickelt wird, der Ausrüstung zum Beenden der Netzwerkverbindung enthält, wenn die Netzwerkverbindung entsprechend einem vordefinierten Timeout-Kriterium der Ausrüstung im Leerlauf bleibt, wobei das Gerät so eingerichtet ist, dass es Keep-Alive-Signale über die Verbindung sendet; dadurch gekennzeichnet, dass das elektronische Gerät über Mittel zum Senden der Keep-Alive-Signale entsprechend einer Vielzahl von unterschiedlichen Zeitintervallen verfügt, um das vordefinierte Timeout-Kriterium der Ausrüstung zu ermitteln.

Ein anderer Aspekt der Erfindung umfasst die Bereitstellung eines Verfahrens zum Ermitteln eines vordefinierten Timeout-Kriteriums in einem elektronischen Gerät mit einer Netzwerkschnittstelle zur Kommunikation mit einem zweiten Gerät über eine Netzwerkverbindung, die über einen physischen Link abgewickelt wird, der Ausrüstung zum Beenden der Netzwerkverbindung enthält, wenn die Netzwerkverbindung entsprechend einem vordefinierten Timeout-Kriterium der Ausrüstung im Leerlauf bleibt, wobei das Gerät so eingerichtet ist, dass es Keep-Alive-Signale über die Verbindung sendet, und das Verfahren dadurch gekennzeichnet ist, dass es das Senden von Keep-Alive-Signalen vom Gerät zur Ausrüstung entsprechend einer Vielzahl von unterschiedlichen Zeitintervallen umfasst, um das vordefinierte Timeout-Kriterium der Ausrüstung zu ermitteln.

Weitere Aspekte und Merkmale der vorliegenden Erfindung werden aus den beigefügten Ansprüchen deutlich.

Es erfolgt jetzt die Beschreibung der Erfindung, und zwar lediglich anhand von Beispielen und unter Bezug auf die beiliegenden Zeichnungen, welche folgende Bedeutung haben:

1 ist eine schematische Darstellung eines Systems zum Aufrechterhalten einer Netzwerkverbindung gemäß einer Ausführungsform der Erfindung;

2 ist ein Flussdiagramm zur Veranschaulichung eines Verfahrens zum Aufrechterhalten einer Netzwerkverbindung gemäß einer anderen Ausführungsform der Erfindung;

3 zeigt das System aus 1 während der Durchführung des Verfahrens aus 2;

4 zeigt eine Gruppe von Teilschritten zur Durchführung von einem der Schritte aus dem Verfahren von 2; und

5 zeigt das System aus 1 während der Durchführung des Verfahrens aus 2

Unter Bezug auf 1 wird ein System zum Aufrechterhalten einer persistenten Netzwerkverbindung allgemein mit 30 bezeichnet. In einer vorliegenden Ausführungsform umfasst das System 30 mindestens einen Client 34, der über einen Drahtlos-Link 42 eine Verbindung zu einem Service-Provider-Knoten 38 herstellt. Der Knoten 38 umfasst eine Drahtlos-Basisstation 46, die über den Link 42 und ein NAT-Gateway 50 mit dem Client 34 interagiert. Das Gateway 50 seinerseits ist über einen Backhaul 58 mit dem Internet 54 verbunden. Der Backhaul 58 kann eine T1-, T3- oder jede andere geeignete Verbindung sein, mit der sich Knoten 38 mit dem Internet 54 verbinden lässt. Das Internet 54 selbst ist über einen zweiten Backhaul 66 mit einem Webserver 62 verbunden.

In einer vorliegenden Ausführungsform handelt es sich beim Client 34 um ein batteriebetriebenes Gerät, dass auf der Rechnerumgebung und auf der Funktionalität eines drahtlosen PDA (Personal Digital Assistant) basiert. Es versteht sich jedoch, dass der Client 34 nicht batteriebetrieben sein muss und/oder die Konstruktion und Funktionalität von anderen elektronischen Geräten wie Mobiltelefonen, intelligenten Telefonen, Desktop-Computern oder Laptops mit drahtlosen 802.11- oder Bluetooth-Funktionen oder dergleichen einschließen kann.

Es sollte auch verständlich sein, dass mindestens ein Abschnitt der Verbindung zwischen Client 34 und Webserver 62 einer Bandbreitenbeschränkung unterliegt. Weil im System 30 der Link 42 eine Drahtlosverbindung ist, die eine eventuell Vielzahl von Clients 34 bedienen muss, unterliegt der Link 42 einer Bandbreitenbeschränkung in Bezug auf den Backhaul 58, auf den Backhaul 66 und auf die anderen Elemente, welche die Verbindung zwischen Client 34 und Webserver 62 bilden. Solche Bandbreitenbeschränkungen können damit die Geschwindigkeit beeinträchtigen, mit der ein Benutzer, der die Clients 34 bedient, auf das Internet 54 und den Webserver 62 zugreifen kann. Solche Beschränkungen werden besonders akut, wenn eine Vielzahl von Clients versucht, auf den Link 42 zuzugreifen. Außerdem ist die wohl überlegte Verwendung des Links 42 durch den Client 34 erwünscht, weil der Client 34 batteriebetrieben ist.

Das NAT-Gateway 50 basiert auf Standard-NAT-Technologie und ermöglicht somit einer großen Anzahl von Clients 34, die mit dem Knoten 38 verbunden sind, die Verbindung mit dem Internet 54 über eine öffentliche Internet-Protokoll-Adresse (IP-Adresse), die dem NAT-Gateway 50 zugewiesen ist. Entsprechend verfügt der Client 34 (und die anderen mit dem Knoten 38 verbundenen Clients) typischerweise über eine private 1P-Adresse, während das NAT-Gateway 50 eine öffentliche IP-Adresse hat, die für jede Partei im Internet 54 zugänglich ist. Wenn der Client 34 auf das Internet 54 zugreift, kommuniziert der Webserver 62 somit mit dem Client 34 über das Gateway 50, wobei das Gateway 50 während dieser Kommunikation die IP-Adressen "übersetzt". In einem Beispiel, das für die vorliegende Ausführungsform spezifisch ist, hat der Client 34 die private IP-Adresse "10.0.0.2", hat das Gateway 50 die private IP-Adresse 10.0.0.1 sowie die öffentliche IP-Adresse "50.0.0.1" und hat der Webserver die öffentliche IP-Adresse "62.0.0.1".

Wie bei bereits existierenden NAT-Gateways ist das Gateway 50 damit so konfiguriert, dass es automatisch im Leerlauf befindliche Verbindungen zwischen dem Client 34 und dem Internet 54 beendet, um die Ressourcen für das NAT-Gateway 50 freizugeben. Der Client 34 ist so konfiguriert, dass er eine Verbindung zwischen dem Client 34 und dem Webserver 62 ungeachtet der automatischen Beendigungsfunktion von Gateway 50 aufrechterhält. Insbesondere ist der Client 34 so konfiguriert, dass er während einer Leerlaufkommunikationsperiode entsprechend einem variablen Kriterium Keep-Alive-Pakete an den Webserver 50 sendet, wobei solche Keep-Alive-Pakete bewirken sollen, dass das Gateway 50 daran gehindert wird, die Verbindung zwischen dem Client 34 und dem Webserver 50 fallen zu lassen, ohne dass jedoch der Status der Daten im Client 34 oder im Webserver 62 geändert wird. Solche Keep-Alive-Pakete können jedes geeignete Paket sein, mit dem dieses Ergebnis erzielt wird, z.B. ein Nulloperationsbefehl, ein Befehl, der ein nicht-kritisches Fehlerergebnis im Server erzeugt, oder ein Befehl, der im Protokoll der Anwendungsebene als ein Keep-Alive-Mechanismus definiert ist. In einer vorliegenden Ausführungsform basiert das variable Kriterium auf einer Zeitspanne, zu der iterativ gelangt wird. Die Iterationen gelten dabei als vollständig, wenn eine Zeitspanne eingerichtet wurde, die im Wesentlichen nahe bei der maximalen Zeitdauer liegt, deren Verstreichen das NAT-Gateway 50 zulässt, bevor es die Verbindung zwischen dem Client 34 und dem Webserver 50 beendet. Weitere Details zum Client 34 und zu diesem Kriterium werden im Folgenden bereitgestellt.

Um die Erklärung bestimmter Einzelheiten dieser Implementierungen und von verschiedenen anderen Aspekten des Systems 30 zu erleichtern, wird nun Bezug auf 2 genommen, die ein Verfahren zum Aufrechterhalten einer Netzwerkverbindung zeigt, das allgemein mit 400 bezeichnet ist. Um die Erklärung des Verfahrens zu erleichtern, wird angenommen, dass das Verfahren 400 durch den Client 34 unter Verwendung des Systems 30 durchgeführt wird. Es sollte jedoch auch verständlich sein, dass der Client 34, das System 30 und/oder das Verfahren 400 variiert werden können und nicht exakt genauso wie hier beschrieben miteinander arbeiten müssen, und dass derartige Variationen innerhalb des Umfangs der Erfindung liegen.

Vor der Erläuterung des Verfahrens 400 wird angenommen, dass das NAT-Gateway 50 so konfiguriert ist, dass es Verbindungen fallen lässt, wenn eine Verbindung für mehr als fünfzehn Minuten im Leerlauf ist. (Allerdings liegen je nach Konfiguration des konkreten NAT-Gateways auch andere Zeitspannen im Umfang der Erfindung. Solche anderen Zeitspannen können größer als zwanzig Minuten, größer als dreißig Minuten oder größer als zehn Minuten sein.) Es wird auch angenommen, dass diese Timeout-Periode beim Aufrufen des Verfahrens 400 dem Client 34 unbekannt ist.

Beginnend mit Schritt 410 wird eine Gruppe von Standardkriterien geladen. Wie weiter unten erläutert wird, wird das geladene Standardkriterium vom Client 34 verwendet, um eine anfängliche Zeitspanne zu definieren, während der Keep-Alive-Pakete durch den Client 34 gesendet werden, um zu verhindern, dass das Gateway 50 eine Verbindung zwischen dem Client 34 und einer Instanz im Internet 54 fallen lässt, ohne jedoch dadurch den Status der Daten im Client 34 oder in dieser Instanz zu ändern. Im vorliegenden Beispiel wird angenommen, dass das Standardkriterium, das geladen wird, eine Zeitspanne von fünf Minuten ist. (Andere exemplarische Standardzeitspannen können sieben Minuten, zehn Minuten und zwölf Minuten sein.)

Als nächstes wird in Schritt 420 eine Verbindung hergestellt. Unter Fortführung des vorliegenden Beispiels wird angenommen, dass der Client 34 eine Verbindung mit dem Webserver 62 öffnet. Dieses Beispiel ist in 3 dargestellt, wo eine allgemein als 100 gekennzeichnete Verbindung durch eine punktierte Linie dargestellt ist. De Öffnung der Verbindung erfolgt in der üblichen Weise, zum Beispiel indem ein auf dem Client 34 befindlicher Webbrowser eine HTTP-Webseite öffnet, die sich auf dem Webserver 62 befindet. Die Herstellung der Verbindung 100 schließt damit ein, dass das NAT-Gateway 50 eine Zuordnung der privaten IP-Adresse des Clients 34 zur eigenen öffentlichen IP-Adresse des Gateways 50 vornimmt. Dies ist in 4 dargestellt, indem dort das Gateway 50 gegenüber dem Webserver 62 repräsentiert, dass die öffentliche IP-Adresse von Client 34 "50.0.0.1/8" ist, wobei "50.0.0.1" die eigene öffentliche IP-Adresse des Gateways 50 ist und "/8" den individuellen Port auf dem Gateway 50 repräsentiert, welcher der privaten IP-Adresse "10.0.0.2" von Client 34 zugeordnet wurde. Damit wird der über die Verbindung 100 abgewickelte Verkehr unter Verwendung dieser Zuordnung über das Gateway 50 geleitet. Sobald die Verbindung 100 geöffnet wurde, wird über sie in üblicher Weise Netzwerkverkehr gesendet. Allgemein muss betont werden, dass dies lediglich ein Beispiel ist und dass die Art und Weise, wie eine Verbindung hergestellt wird, keiner bestimmten Einschränkung unterliegt.

Als nächstes werden in Schritt 430 Keep-Alive-Signale entsprechend dem eingerichteten Kriterium gesendet. Da das Kriterium, das in Schritt 410 eingerichtet wird, eine Zeitspanne von fünf Minuten ist, werden in Schritt 430 alle fünf Minuten Keep-Alive-Signale vom Client 34 zum Webserver 62 gesendet. Da diese Keep-Alive-Signale durch das Gateway 50 geleitet werden, nimmt das Gateway 50 nur wahr, dass sich die Verbindung 100 für Fünfminutenzeitspannen im Leerlauf befindet. Da diese Fünfminutenzeitspanne kürzer ist als die fünfzehnminütige Timeout-Periode, die das Gateway 50 wartet, bevor es die Verbindung 100 beendet, wird das Gateway 50 die Verbindung 100 nicht beenden, und damit wird die Verbindung 100 persistent.

Das Verfahren 400 wird dann mit Schritt 440 fortgesetzt, wo ermittelt wird, ob die in Schritt 420 hergestellte Verbindung beendet wurde. Da das Fünfminutenintervall, in dem der Client 34 Keep-Alive-Signale zum Webserver 62 sendet, kürzer ist als die zuvor erwähnte fünfzehnminütige Timeout-Periode, wird die Verbindung 100 nicht beendet, und deshalb wird in Schritt 440 die Ermittlung mit "Nein" beantwortet, da die Verbindung 100 nicht beendet wurde, und das Verfahren 400 wird mit Schritt 450 fortgesetzt.

In Schritt 450 wird falls erforderlich eine Justierung für das in Schritt 430 verwendete Kriterium ermittelt. In einer vorliegenden Ausführungsform wird der Schritt 450 über eine Anzahl von Teilschritten durchgeführt, die in 4 allgemein mit 450 bezeichnet sind. In Schritt 451 wird ermittelt, ob die Verbindung jemals beendet worden ist. Wenn es eine vorherige Beendigung gegeben hat, dann wird das Verfahren mit Schritt 452 fortgesetzt, und das zuletzt bekannte gute Kriterium wird beibehalten, und damit erfolgt keine Justierung für das Kriterium. An dieser Stelle kehrt das Verfahren wieder zu Schritt 430 aus 2 zurück.

Wenn jedoch in Schritt 451 ermittelt wird, dass es zuvor keine Beendigung der Verbindung gegeben hat, dann wird das Verfahren mit Schritt 453 fortgesetzt, wo eine Justierung erfolgt, um die Zeit zwischen der Zustellung der Keep-Alive-Signale zu erhöhen. Damit wird in dem hier unter Bezug auf die Verbindung 100 erläuterten Beispiel in Schritt 451 ermittelt, dass die Verbindung niemals beendet wurde, und das Verfahren wird von Schritt 451 aus mit Schritt 453 fortgesetzt. In Schritt 453 wird das Kriterium justiert, um die Zeitdauer zwischen der Zustellung der Keep-Alive-Signale zu erhöhen. Die Dauer und/oder die Rate, mit der die Erhöhung in Schritt 453 durchgeführt wird, unterliegt keiner besonderen Einschränkung. Gemäß dem vorliegenden Beispiel wird angenommen, dass das Zeitintervall jedes Mal, wenn das Verfahren 400 zu Schritt 453 wechselt, um eine Minute erhöht wird. Dementsprechend wird bei diesem Zyklus durch das Verfahren 400 die Zeitspanne von fünf Minuten auf sechs Minuten erhöht.

Das Verfahren wechselt dann nach Schritt 453 wieder zurück zu Schritt 430, wo die Keep-Alive-Signale entsprechend dem Kriterium gesendet werden, das in Schritt 453 eingerichtet wurde. Da das in Schritt 453 eingerichtete Kriterium eine Zeitspanne von sechs Minuten ist, werden in Schritt 430 alle sechs Minuten vom Client 34 Keep-Alive-Signale zum Webserver 62 gesendet. Da diese Keep-Alive-Signale durch das Gateway 50 geleitet werden, nimmt das Gateway 50 nur wahr, dass sich die Verbindung 100 für Sechsminutenzeitspannen im Leerlauf befindet. Da diese Sechsminutenzeitspanne kürzer ist als die fünfzehnminütige Timeout-Periode, die das Gateway 50 wartet, bevor es die Verbindung 100 beendet, wird das Gateway 50 die Verbindung 100 nicht beenden, und damit wird die Verbindung 100 persistent.

Das Verfahren 400 wird damit mit weiteren Zyklen durch die Schritte 430, 440 und 450 (d.h. die Teilschritte 451 und 453) wie oben erwähnt fortgesetzt, bis das in Schritt 453 eingerichtete Kriterium letztlich das Zeitintervall außerhalb der Timeout-Periode von Gateway 50 justiert. Im konkreten Beispiel bedeutet das: Wenn in Schritt 453 eine Zeitspanne von sechzehn Minuten eingerichtet wird, dann wird beim nächsten Zyklus durch Schritt 430 das Keep-Alive-Signal außerhalb der fünfzehnminütigen Timeout-Periode gesendet, und deshalb wird die Verbindung 100 beendet.

Wenn das Verfahren 400 dieses Mal den Schritt 440 erreicht, wird ermittelt, dass die Verbindung 100 beendet wurde, und damit wird das Verfahren 400 von Schritt 440 aus mit Schritt 460 fortgesetzt, wo das zuletzt bekannte gute Kriterium geladen wird. Im vorliegenden Beispiel wird das zuletzt bekannte gute Kriterium, das zuvor in Schritt 453 eingerichtet wurde, das Zeitintervall von fünfzehn Minuten sein, und deshalb lädt der Client 34 in diesem Beispiel in Schritt 460 die Zeitspanne von fünfzehn Minuten als das Kriterium.

Das Verfahren 400 wird dann von Schritt 460 aus mit Schritt 420 fortgesetzt, wo die Verbindung hergestellt (d.h. erneut hergestellt) wird. Unter Fortsetzung des vorliegenden Beispiels wird angenommen, dass der Client 34 erneut eine Verbindung mit dem Webserver 62 öffnet. Dieses Beispiel ist in 5 dargestellt, wobei eine neue Verbindung durch eine allgemein mit 104 bezeichnete punktierte Linie dargestellt ist. Die Verbindung wird in der üblichen Weise geöffnet, zum Beispiel indem ein auf dem Client 34 befindlicher Webbrowser eine HTTP-Webseite öffnet, die sich auf dem Webserver 62 befindet. Die Herstellung der Verbindung 104 schließt somit ein, dass das NAT-Gateway 50 eine Zuordnung der privaten IP-Adresse des Clients 34 zur eigenen öffentlichen IP-Adresse des Gateways 50 vornimmt. Dies ist in 4 dargestellt, indem dort das Gateway 50 gegenüber dem Webserver 62 repräsentiert, dass die öffentliche IP-Adresse von Client 34 "50.0.0.1/9" ist, wobei "50.0.0.1" die eigene öffentliche IP-Adresse des Gateways 50 ist und "/9" den individuellen Port auf dem Gateway 50 repräsentiert, welcher der privaten IP-Adresse "10.0.0.2" von Client 34 zugeordnet wurde. Damit wird der über die Verbindung 104 abgewickelte Verkehr unter Verwendung dieser Zuordnung über das Gateway 50 geleitet. Sobald die Verbindung 104 geöffnet wurde, wird über sie in üblicher Weise Netzwerkverkehr gesendet.

Das Verfahren 400 wird dann mit Schritt 430 fortgesetzt, wo die Keep-Alive-Signale entsprechend dem in Schritt 460 eingerichteten Kriterium gesendet werden. Da das Kriterium, das in Schritt 460 eingerichtet wurde, eine Zeitspanne von fünfzehn Minuten ist, werden in Schritt 430 alle fünfzehn Minuten Keep-Alive-Signale vom Client 34 zum Webserver 62 gesendet. Da diese Keep-Alive-Signale durch das Gateway 50 geleitet werden, nimmt das Gateway 50 nur wahr, dass sich die Verbindung 104 für Fünfzehnminutenzeitspannen im Leerlauf befindet. Da diese Fünfzehnminutenzeitspanne entsprechend der fünfzehnminütige Timeout-Periode akzeptabel ist, die das Gateway 50 wartet, bevor es die Verbindung 104 beendet, wird das Gateway 50 die Verbindung 104 nicht beenden, und damit wird die Verbindung 104 persistent.

Das Verfahren 400 wird dann von Schritt 430 aus mit Schritt 440 fortgesetzt, wo ermittelt wird, ob die in Schritt 420 hergestellte Verbindung beendet wurde. Da das Fünfzehnminutenintervall, in dem der Client 34 Keep-Alive-Signale zum Webserver 62 sendet, akzeptabel ist im Hinblick auf die fünfzehnminütige Timeout-Periode, wird die Verbindung 104 nicht beendet, und deshalb wird in Schritt 440 die Ermittlung mit "Nein" beantwortet, da die Verbindung 104 nicht beendet wurde, und das Verfahren 400 wird mit Schritt 450 fortgesetzt.

In Schritt 450 wird falls erforderlich eine Justierung für das in Schritt 430 verwendete Kriterium ermittelt. Erinnern wir uns daran, dass in einer vorliegenden Ausführungsform der Schritt 450 über eine Anzahl von Teilschritten durchgeführt wird, die in 4 allgemein mit 450 bezeichnet sind. In Schritt 451 wird ermittelt, ob die Verbindung jemals beendet worden ist. Da die Verbindung zwischen dem Client 34 und dem Webserver 62 bereits einmal beendet wurde (d.h. weil die Verbindung 100 beendet wurde), wird das Verfahren mit Schritt 452 fortgesetzt, und das zuletzt bekannte gute Kriterium wird beibehalten, und damit erfolgt keine Justierung für das Kriterium. Im konkreten Beispiel wird – weil bekannt ist, dass das fünfzehnminütige Zeitintervall ein akzeptables Kriterium ist – dieses Kriterium beibehalten, und das Verfahren kehrt an dieser Stelle wieder zu Schritt 430 aus 2 zurück.

Wir sind zu Schritt 430 zurückgekehrt, wo die Keep-Alive-Signale entsprechend dem in Schritt 452 erhaltenen Kriterium gesendet werden. Da das Kriterium, das in Schritt 452 eingerichtet wurde, eine Zeitspanne von fünfzehn Minuten ist, werden in Schritt 430 die Keep-Alive-Signale alle fünfzehn Minuten vom Client 34 zum Webserver 62 gesendet. Da diese Keep-Alive-Signale durch das Gateway 50 geleitet werden, nimmt das Gateway 50 nur wahr, dass sich die Verbindung 104 für Fünfzehnminutenzeitspannen im Leerlauf befindet, also innerhalb der akzeptierten fünfzehnminütigen Timeout-Periode, die das Gateway 50 wartet, bevor es die Verbindung 100 beendet. Damit wird das Gateway 50 die Verbindung 104 nicht beenden, und damit wird die Verbindung 104 persistent. Das Verfahren 400 wird damit in Zyklen so lange fortgesetzt, wie es erforderlich ist, um eine Verbindung zwischen dem Client 34 und dem Webserver 62 während der Leerlaufperiode aufrechtzuerhalten.

Es sollte nun deutlich geworden sein, dass eine Änderung im Routing der Verbindung 104 (oder eine andere Änderung im physischen Link zwischen Client 34 und Webserver 62) zu einer Änderung der Timeout-Periode führen könnte – d.h. im Lauf der Zeit zu einer Verringerung von der Zeitspanne, die zuvor eingerichtet worden war, über die früheren Zyklen durch das Verfahren 400. Wenn beispielsweise ein anderer Router im Internet 54 in den Signalweg eingeschaltet wird, auf dem die Verbindung 104 abgewickelt wird, und wenn dieser Router im Leerlauf befindliche Verbindungen bereits nach zehn Minuten fallen lässt, dann kann das Verfahren 400 zu verschiedenen Zeiten zyklisch den Schritt 460 ausführen und dadurch kann die Verbindung zwischen dem Client 34 und dem Webserver 62 mehrere Male abgebaut und wiederhergestellt werden, bis in Schritt 460 das Kriterium zurück zu einem Zehnminutenintervall verringert wird. Es wird somit in Betracht gezogen, dass Schritt 460 Teilschritte einschließen kann, die damit fortfahren, das Kriterium auf immer kürzere Zeitspannen zu verkürzen, bis die kürzeste Timeout-Periode für jedes Ausrüstungselement im physischen Link zwischen dem Client 34 und dem Webserver 62 eingerichtet wurde, und in diesem Moment wird diese kürzeste Timeout-Periode in Schritt 430 verwendet. Auf diese Weise wird in Betracht gezogen, dass das in Schritt 430 verwendete Kriterium zu verschiedenen Zeiten entsprechend dem Timeout-Verhalten der Ausrüstung, die den physischen Link zwischen dem Client 34 und dem Webserver 62 bildet, verringert oder erhöht werden kann.

Es sollte auch verständlich geworden sein, dass in anderen Ausführungsformen der Erfindung normale fehlerhafte Verbindungs-Timeouts durch eine in geeigneter Weise modifizierte Version des Verfahrens 400 gehandhabt werden können. Eine solche modifizierte Version des Verfahrens 400 kann so konfiguriert sein, dass es auf solche fehlerhaften Verbindungs-Timeouts reagiert. Beispielsweise kann eine Form der Gewichtung oder Hysterese in einer in geeigneter Weise modifizierten Version des Verfahrens 400 eingesetzt werden, das dann Zeitintervalle für die Zustellung von Keep-Alive-Signalen bevorzugt, die sich für den Client 34 zuvor als effektiv erwiesen haben, um die Wahrscheinlichkeit zu verringern, dass die Verbindung 104 beendet wird.

Es sollte ebenso verständlich sein, dass die Raten, mit denen das Kriterium in Schritt 450 und Schritt 460 justiert wird, keiner besonderen Einschränkung unterliegen. Außerdem ist der Typ des verwendeten Kriteriums nicht in besonderer Weise eingeschränkt. Beispielsweise müssen die Änderungen im Kriterium in Schritt 450 und 460 nicht in linearer Weise erfolgen und müssen nicht auf einfachen minutenweisen Anhebungen oder Verringerungen basieren. Beispielsweise kann eine logarithmische Konvergenz verwendet werden, die auf dem Halbieren der verschiedenen Zeitintervalle nach der Newton-Methode basiert. Als ein weiteres Beispiel kann es erwünscht sein, dass in Schritt 450 und Schritt 460 die restliche Batterielebensdauer von Client 34 berücksichtigt wird, und dass damit bei noch langer restlicher Batterielebensdauer von Client 34 die in Schritt 450 durchgeführte Justierung des Kriteriums nicht aggressiv erfolgen muss. Wenn dagegen die Batterie von Client 34 nur noch eine kurze restliche Lebensdauer hat, kann die Justierung des Kriteriums in Schritt 450 in aggressiver Weise versuchen, dass das Kriterium die Leerlauf-Timeout-Periode so schnell wie möglich erreicht, um die Batterielebensdauer von Client 34 zu erhalten.

Während hier nur bestimmte Kombinationen der verschiedenen Merkmale und Komponenten der Erfindung erläutert wurden, wird es dem Fachmann auf dem Gebiet der Technik einleuchten, dass je nach Wunsch auch Teilmengen der offenbarten Merkmale und Komponenten und/oder alternative Kombinationen dieser Merkmale und Komponenten entsprechend dem konkreten Bedarf eingesetzt werden können. Beispielsweise wird typischerweise in Betracht gezogen, obwohl das nicht notwendig ist, dass die Schritte 430–460 nur während den Zeitspannen aufgerufen werden, in denen der Client 34 erkennt, dass die Verbindung 100 (oder 104) sich im Leerlauf befindet, und so kann das Verfahren 400 so modifiziert sein, dass die Durchführung der Schritte 430–460 nur während dieser Zeitspannen bewirkt wird, in denen die Verbindung 100 (oder Verbindung 104) sich im Leerlauf befindet.

Darüber hinaus sollte auch verständlich sein, dass der Ursprung der Keep-Alive-Pakete nicht auf den Client 34 beschränkt sein muss. Wenn beispielsweise die Basisstation 46 erkennt, dass die Verbindung 100 als persistente Verbindung aufrechterhalten werden muss, dann kann es erwünscht sein, dass die Basisstation 46 die Schritte 430–460 im Auftrag des Client 34 durchführt, wodurch Ressourcen auf dem Client 34 und im Link 42 freigesetzt werden. Aus dem gleichen Grund wird in Betracht gezogen, dass die Schritte 430–460 auch durch den Webserver 62 im Auftrag des Client 34 durchgeführt werden können.

In einer anderen Variation der Erfindung wird in Betracht gezogen, dass die Schritte 430–460 durch den Client 34 vor der Herstellung einer Verbindung durchgeführt werden können, wodurch das geeignete Kriterium zum Senden der Keep-Alive-Signale innerhalb der Timeout-Periode noch vor dem Herstellen der Verbindung ermittelt werden kann und wodurch die Wahrscheinlichkeit der Beendigung der Verbindung verringert wird. Außerdem wird in Betracht gezogen, dass – sobald diese Timeout-Periode ermittelt wurde – diese Periode an andere Clients gemeldet werden kann, die mit dem Knoten 38 verbunden sind, wodurch bei diesen Clients die Notwendigkeit entfällt, ihrerseits die Schritte 430–460 durchzuführen.

Während sich das System 30 auf einen speziellen Typ von Netzwerk richtet, sollte es verständlich sein, dass auch andere Typen von Clients, Servern und Netzwerken verwendet werden können. Beispielsweise kann die Erfindung auf Peerto-Peer-Verbindungen angewendet werden und muss nicht auf Beziehungen des Typs Client/Server beschränkt sein. Außerdem unterliegt auch der Typ der physischen Verbindungen, über die die Verbindung abgewickelt wird, keiner Beschränkung und kann auf Ethernet, Intranets, 802.11, Bluetooth usw. basieren. Und obwohl die Ausführungsformen hier im Zusammenhang mit Verbindungen erläutert wurden, von denen zumindest ein Abschnitt Bandbreitenbeschränkungen unterliegt, sollte es verständlich sein, dass die Erfindung auch auf Verbindungen ohne jegliche Bandbreitenbeschränkung anwendbar ist.

Die oben beschriebenen Ausführungsformen der Erfindung sollen lediglich als Beispiele dienen, und es können daran durch den Fachmann auf dem Gebiet der Technik Änderungen und Modifikationen vorgenommen werden, ohne dass dadurch der Umfang der Erfindung verlassen wird, der ausschließlich durch die hier beigefügten Ansprüche definiert wird.