[go: up one dir, main page]

DE60300432T2 - Vorrichtung und Verfahren zur Optimierung des Netzwerkverkehrs - Google Patents

Vorrichtung und Verfahren zur Optimierung des Netzwerkverkehrs Download PDF

Info

Publication number
DE60300432T2
DE60300432T2 DE60300432T DE60300432T DE60300432T2 DE 60300432 T2 DE60300432 T2 DE 60300432T2 DE 60300432 T DE60300432 T DE 60300432T DE 60300432 T DE60300432 T DE 60300432T DE 60300432 T2 DE60300432 T2 DE 60300432T2
Authority
DE
Germany
Prior art keywords
server
program
request
local
local server
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Lifetime
Application number
DE60300432T
Other languages
English (en)
Other versions
DE60300432D1 (de
Inventor
Frederic Vignaud
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Societe Francaise du Radiotelephone SFR SA
Original Assignee
Societe Francaise du Radiotelephone SFR SA
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Societe Francaise du Radiotelephone SFR SA filed Critical Societe Francaise du Radiotelephone SFR SA
Application granted granted Critical
Publication of DE60300432D1 publication Critical patent/DE60300432D1/de
Publication of DE60300432T2 publication Critical patent/DE60300432T2/de
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/04Protocols specially adapted for terminals or networks with limited capabilities; specially adapted for terminal portability
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L51/00User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail
    • H04L51/58Message adaptation for wireless communication
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/2866Architectures; Arrangements
    • H04L67/289Intermediate processing functionally located close to the data consumer application, e.g. in same machine, in same home or in same sub-network
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/50Network services
    • H04L67/56Provisioning of proxy services
    • H04L67/563Data redirection of data network streams
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/50Network services
    • H04L67/60Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
    • H04L67/62Establishing a time schedule for servicing the requests
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/329Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer [OSI layer 7]

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Traffic Control Systems (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Road Signs Or Road Markings (AREA)
  • Computer And Data Communications (AREA)

Description

  • Die Erfindung betrifft ein Verfahren zur Optimierung eines Netzverkehrs und der entsprechenden Durchführungsmittel. Sie ist hauptsächlich für die Verwendung in der Telekommunikation und solchen Dienstleistungen bestimmt, die über diese Netze zugänglich sind. Insbesondere ist sie für den Zugriff auf Dienstleistungen mit Hilfe von Netzen und unter Verwendung mobiler Clients bestimmt. Unter einem mobilen Client ist eine intelligente Vorrichtung zu verstehen, die imstande ist, ein kommunizierendes Programm zu erstellen, um auf ein oder mehrere Telekommunikationsnetze zuzugreifen und sich damit in eine Dienstleistung einzuloggen, die einer Dienstleistung entspricht, für die der Nutzer des mobilen Clients abonniert ist.
  • Eines der Ziele der Erfindung ist es, den von dem mobilen Client für den Zugriff auf die verschiedenen Dienstleistungen, für die der Nutzer abonniert ist, erhaltenen und ausgehenden Informationsfluss zu reduzieren.
  • Ein weiteres Ziel der Erfindung ist es, die funkelektrische Aktivität eines mobilen Clients zu reduzieren.
  • Ein weiteres Ziel der Erfindung ist es, den Energieverbrauch eines mobilen Clients zu reduzieren.
  • Nach dem neuesten Stand der Technik sind unterschiedliche Methoden bekannt, um zu versuchen, diese Probleme zu lösen. Eine davon ist unter der Bezeichnung Optimierung der Routing-Protokolle bekannt. Ein Routing-Protokoll oder ein Protokoll generell definiert Formate für den Informationsaustausch zwischen zwei Vorrichtungen, die über ein Netz miteinander kommunizieren. Ein Protokoll definiert insbesondere, welche Informationen über Datenübertragungsblöcke oder Nachrichten übermittelt werden. Die Optimierung eines Protokolls nach dem neuesten Stand der Technik bedeutet, dass die Größe der gesendeten Datenübertragungsblöcke reduziert wird. Es handelt sich um eine Rationalisierung der übertragenen Informationen. Es geht also darum, in dem Kontext, in dem die Mitteilung oder der Datenübertragungsblock übermittelt wird, keine redundanten oder unzweckmäßigen Informationen zu übertragen.
  • Eine weitere Lösung ist die Verwendung von Cache-Speichern. Ein Cache-Speicher ist ein Speicher, der die Spur der jüngsten von dem Nutzer der Vorrichtung, in dem der Cache-Speicher installiert ist, durchgeführten Operationen bewahrt. Wenn also der Nutzer zweimal dieselbe Anforderung eingibt, braucht er die Antwort darauf nicht mehr im Netz zu suchen, weil sie bereits im Cache-Speicher vorhanden ist. Eine solche Lösung ist unangemessen, weil die Antwort auf eine Anforderung von dem Zeitpunkt abhängen kann, zu dem die Frage gestellt wird. Wenn die Cache-Speicher nicht aktualisiert werden, um den Netzfluss zu beschränken, sind die Antworten auf identische Eingaben nicht immer relevant. Dies gilt insbesondere für Anwendungen wie z.B. das Messaging-System. Ein Client oder eine Client-Anwendung führt regelmäßig Abfragen durch, um zu prüfen, ob neue Mitteilungen eingegangen sind. Die Eingabe ist also immer die gleiche, aber die Antworten stimmen nicht unbedingt miteinander überein. Diese Antwort kann also nicht in einem Cache-Speicher abgelegt werden. Diese periodischen Abfragen werden auch als „Polling" bezeichnet.
  • Eine dritte Lösung besteht darin, den Fluss zu reduzieren, indem die übermittelten Daten komprimiert werden. Diese Technik hat jedoch eine intensive funkelektrische Aktivität sowie die Besetzung des Netzes zur Folge. Außerdem werden dadurch zusätzliche Kalkulationen ausgelöst, weil die aus- und eingehenden Daten komprimiert und dekomprimiert werden müssen. Dadurch wird das Netzverkehrsaufkommen ein wenig verringert, aber man büßt gleichzeitig an Autonomie für einen mobilen Client ein, weil die Kompression und Dekompression viel Zykluszeit des Mikroprozessors beanspruchen und entsprechend viel Energie verbrauchen.
  • Nach dem neuesten Stand der Technik kennt man auch das Dokument GB 2 327 829 A , das ein Kommunikationsverwaltungs-Verfahren verbreitet. Dadurch werden diese Kommunikationen verändert, aber nicht reduziert.
  • Folglich reduziert keine der drei nach dem neuesten Stand der Technik existierenden Lösungen die Netzaktivität eines Clients, und insbesondere eines mobilen Clients, auf beträchtliche Weise. Auch löst keine davon ein Problem im Zusammenhang mit einer regelmäßigen Abfrage eines Servers und damit ein Problem des Verbrauches.
  • Das fortbestehende Problem liegt also in zahlreichen Netzprotokollen darin, dass der Client dem Server regelmäßig Anforderungen schickt, um über eine Änderung eines Kontexts auf dem Server auf dem Laufenden zu sein. Dieser regelmäßige Abfragefluss ist bezüglich des Frequenzbereiches kostspielig und ein wesentliches Ziel der Erfindung besteht darin, diesen Netzfluss zu reduzieren.
  • Durch die Erfindung werden diese Probleme gelöst, indem der vom Client in Richtung einer in der Vorrichtung des Clients enthaltenen Service-Servers, auch „Proxy" genannt, mit Hilfe eines lokalen Serverprogrammes generierte Netzfluss kontrolliert wird, wobei das lokale Serverprogramm durch einen Netzkontrollserver gesteuert wird. Das lokale Serverprogramm ist in der Vorrichtung des Clients installiert. Dieses lokale Serverprogramm fängt den gesamten ein-/ausgehenden Verkehr der Client-Vorrichtung auf.
  • Damit dient das lokale Serverprogramm erstens der Verkehrskontrolle; hier kann diese Kontrolle im Relaismodus erfolgen, wobei das lokale Serverprogramm die vom Client in Richtung Server ausgegebene Mitteilung unbearbeitet überträgt. Das lokale Serverprogramm kann aber auch in einem Sperrmodus funktionieren, bei dem die vom Client in Richtung Server ausgegebene Mitteilungen blockiert werden. Im Sperrmodus antwortet das lokale Serverprogramm dem Client, dass der Service-Server unzugänglich oder besetzt ist. Und schließlich kann das lokale Serverprogramm im Initialisierungsmodus funktionieren, wobei die vom Client ausgegebenen Mitteilungen abgefangen und an einen Netzkontrollserver übermittelt werden, aber nicht an den Service-Server, für den die Mitteilung ursprünglich bestimmt war.
  • Zweitens erfüllt das lokale Serverprogramm eine Kommunikationsfunktion mit dem Netzkontrollserver. Dank dieser Funktion können Mitteilungen mit dem Netzkontrollserver ausgetauscht werden, wodurch auch der Netzkontrollserver die Funktionsweise des lokalen Serverprogramm steuern kann.
  • Der Netzkontrollserver ist eine an das Netz angeschlossene Vorrichtung; er erfüllt hauptsächlich zwei Funktionen. Erstens eine Kommunikationsfunktion mit einem lokalen Serverprogramm. Zweitens eine Abfragefunktion eines Service-Servers, z.B. Abfrage eines Messaging-Servers.
  • Damit lautet das Prinzip der Erfindung folgendermaßen. Zunächst befindet sich das lokale Serverprogramm im Initialisierungsmodus. In dieser Betriebsart fängt es die ersten vom Client ausgegebenen Mitteilungen ab. Diese Mitteilungen sind ursprünglich für einen Service-Server bestimmt. Diese Mitteilungen werden anschließend über das lokale Serverprogramm an den Netzkontrollserver weitergeleitet. Bei Eingang dieser Mitteilungen parametriert sich der Netzkontrollserver so, dass er mit dem Service-Server anstelle der Client-Anwendung dialogieren kann. Die vom Kontrollserver in der Initialisierungsphase empfangenen Mitteilungen enthalten u.a. einen Identifier oder ein „Login" des Nutzers der Client-Vorrichtung und ein Passwort, das dem Konto dieses Benutzers im Service-Server entspricht. Ebenso enthalten die eingehenden Mitteilungen einen Hinweis auf die Häufigkeit, mit der der Service-Server abgefragt werden soll. Damit ist der Kontrollserver in der Lage, sich so zu parametrieren, dass er die Abfrage der Client-Anwendung durchführen kann.
  • Nach der Initialisierungsphase wechselt das lokale Serverprogramm in den Sperrmodus über. Das lokale Serverprogramm verbleibt im Sperrmodus, bis es eine Mitteilung des Kontrollservers erhält, dass sich der Kontext auf dem Service-Server geändert hat. In diesem Fall geht das Programm des Lokalservers in den Relaismodus und der Client kann den Service-Server abfragen. Ein Kontext beinhaltet beispielsweise eine Anzahl nicht gelesener Mitteilungen oder neuer Mitteilungen in einem elektronischen Briefkasten.
  • Die Erfindung betrifft damit ein Verfahren zur Optimierung eines Netzverkehrs, welches einen mobilen Clients und einen Service-Server beinhaltet, dadurch gekennzeichnet, dass das Verfahren folgende Etappen beinhaltet:
    • – eine Client-Anwendung, die von dem mobilen Client durchgeführt wird, sendet eine erste Anfrage an den Service-Server,
    • – ein lokales Serverprogramm, das von dem mobilen Client durchgeführt wird, fängt die erste Anfrage an den Service-Server ab,
    • – das lokale Serverprogramm erzeugt eine Initialisierungsnachricht aus dem Inhalt der ersten Anfrage, wobei die Initialisierungsnachricht Informationen beinhaltet, anhand derer sich ein Kontrollserver für die Client-Anwendung ausgeben kann, vorzugsweise einen Identifier und ein Passwort, wobei die Initialisierungsnachricht auch Informationen über einen abzufragenden Service-Server beinhaltet, vorzugsweise seine Adresse in einem Netz und seinen Typ,
    • – das lokale Serverprogramm sendet die Initialisierungsnachricht an den Kontrollserver,
    • – der Kontrollserver empfängt die Initialisierungsnachricht und parametriert sich gemäß des Inhalts der Initialisierungsnachricht, um Anforderungen an den Service-Server zu senden.
  • Die Erfindung betrifft auch eine Client-Vorrichtung, das in einem Netz kommuniziert, dadurch gekennzeichnet, dass die Client-Vorrichtung einen Programmspeicher mit Befehlscodes beinhaltet, die einer Client-Anwendung entsprechen, die Anforderungen an einen Service-Server richtet, wobei der Programmspeicher auch Befehlscodes beinhaltet, die einem lokalen Serverprogramm entsprechen, um von der Client-Anwendung ausgehende Mitteilungen abzufangen und zu bearbeiten und von einem Kontrollserver ausgehende Mitteilungen zu empfangen und zu bearbeiten.
  • Die Erfindung betrifft auch eine Kontrollserver-Vorrichtung, das im Netz kommuniziert, dadurch gekennzeichnet, dass das Netzkontrollserver-Vorrichtung einen Konfigurationsspeicher zur Aufzeichnung der Informationen einer Initialisierungsnachricht beinhaltet, wobei das Kontrollserver-Vorrichtung auch einen Programmspeicher mit Befehlscodes beinhaltet, um abhängig vom Inhalt des Konfigurationsspeichers Anforderungen an den Service-Server zu richten, wobei der Programmspeicher auch Befehlscodes beinhaltet, um abhängig von einer Antwort auf eine Anforderung eine Freigabe- und/oder Status-Meldung an ein lokales Serverprogramm zu übermitteln.
  • Beim Durchlesen der im folgenden angegebenen Beschreibung und der darin enthaltenen Abbildungen wird man die Erfindung besser verstehen. Die Abbildung dienen lediglich als Hinweise auf die Erfindung und sind keinesfalls erschöpfend. Sie zeigen:
  • 1: zeigt für die Einrichtung des erfindungsgemäßen Verfahrens nützliche Mittel
  • 2: zeigt Etappen des erfindungsgemäßen Verfahrens
  • 2bis zeigt Etappen des erfindungsgemäßen Verfahrens
  • 1 zeigt eine Client-Vorrichtung 101 oder den Mobilclient 101. In der Beschreibung geht man davon aus, dass der Mobilclient 101 ein Mobiltelefon 101 ist. Das Mobiltelefon 101 besitzt in diesem Falle eine Antenne 102, um eine funkelektrische Verbindung 103 mit einem Mobilfunknetz 104 herzustellen. Netz 104 wird nicht im Detail gezeigt. Bei der Beschreibung wird davon ausgegangen, dass Netz 104 alle notwendigen Elemente beinhaltet, damit sich z.B. Telefon 101 in das Internet einloggen kann. Entsprechend beinhaltet Netz 104 u.a. eine Basisstation, an die das Telefon 101 sowie sämtliche Vorrichtungen angeschlossen sind, mit denen die Basisstation an Internet angeschlossen werden kann.
  • Telefon 101 beinhaltet außerdem elektronische Schaltkreise 105, die erstens an die Antenne 102 und zweitens an einen internen Bus 106 von Telefon 101 angeschlossen sind. Die Schaltkreise 105 haben also die Aufgabe, die Funkschnittstelle zwischen Telefon 101 und Netz 104 herzustellen. Für die Beschreibung wurde die Norm GSM genommen, aber es könnte sich genauso gut um eine andere Norm handeln, z.B. PCS, DCS, UMTS oder alle anderen existierenden und/oder künftigen funkelektrischen Normen.
  • In der Beschreibung werden Vorrichtungen oder Programmen Aktionen zugeordnet. Das bedeutet, dass diese Aktionen von einem Mikroprozessor dieser Vorrichtung oder der Vorrichtung, welche das Programm beinhaltet, ausgeführt werden, wobei besagter Mikroprozessor von in einem Speicher der Vorrichtung abgelegten Befehlscodes gesteuert wird. Anhand dieser Befehlscodes können die Mittel der Vorrichtung verwendet und die geplante Aktion durchgeführt werden.
  • Telefon 101 beinhaltet einen Mikroprozessor 107, der an den Bus 106 angeschlossen ist. Telefon 101 beinhaltet außerdem Programmspeicher 108 und 109. Die Speicher 108 und 109 werden einzeln dargestellt, können aber ebenso wie die übrigen Speicher der Vorrichtung in ein- und derselben Komponenten vereint werden.
  • Speicher 108 beinhaltet Befehlscodes, die einer Client-Anwendung entsprechen. Eine solche Anwendung ist beispielsweise eine elektronische Mitteilungssoftware. Dank einer solchen Software kann Telefon 101 eine elektronische Mitteilung abfragen, d.h. einen Service-Server, wobei der Dienst die elektronische Mitteilung ist.
  • Speicher 109 ist in mehrere Bereiche unterteilt, wobei jeder Bereich einer Funktion oder einer Funktionsweise des lokalen Serverprogramms oder „Proxy" entspricht. Speicher 109 entspricht also eigentlich dem Befehlscode des lokalen Serverprogramms. Bereich 109a beinhaltet Befehlscodes, um eine z.B. von der Client-Anwendung 108 ausgehende Abfrage abzufangen. Bereich 109b beinhaltet Befehlscodes, die der Funktionsweise im Initialisierungsmodus entsprechen. Bereich 109c beinhaltet Befehlscodes, die der Funktionsweise im Kommunikationsmodus mit dem Netzkontrollserver entsprechen. Bereich 109d entspricht der Funktionsweise des lokalen Serverprogramms im Relaismodus.
  • Speicher 108 et 109 sind an Bus 106 angeschlossen.
  • Telefon 101 beinhaltet auch noch andere Konfigurationsspeicher. In Speicher 110 kann mindestens ein Identifier/eine Adresse von Telefon 101 für die Kommunikationen mit einem Netzkontrollserver oder Service-Server abgelegt werden. Ein Identifier/eine Adresse ist beispielsweise eine Internet-Adresse IPv4 (Internet-Protokoll, Version 4), eine Internet-Adresse IPv6 und kann auch eine Telefonnummer sein, mit der Telefon 101 im Mobilfunknetz, in dem der Benutzer abonniert ist, identifiziert wird. Letzterer Identifier/letztere Adresse wird im Rahmen einer Kommunikation z.B. in Form von Kurzmitteilungen verwendet.
  • In Speicher 111 wird ein Identifier des Nutzers beim Anschluss an einen Service-Server abgelegt. Ein solcher Identifier 111 wird mit einem Passwort 112 in Verbindung gebracht, das in Speicher 112 abgelegt ist. In Speicher 113 wird die Adresse eines Service-Servers abgelegt. Eine solche Adresse ist entweder eine Internet-Adresse mit IP-Protokoll oder eine URL-Adresse (Universal Resource Locator). In Speicher 114 wird schließlich eine Abfragefrequenz eines Service-Servers abgelegt.
  • Speicher 110 bis 114 sind an Bus 106 angeschlossen.
  • In der Praxis können die Parameter der Client-Anwendung 108 in den Speichern 110 bis 114 gespeichert werden. Anwendung 108 braucht nämlich Adresse 113, um Anforderungen an einen Service-Server zu senden, sowie einen Identifier 111 und ein Passwort 112, um von diesem Service-Server erkannt zu werden, und eine Adresse 110, damit der Service-Server die Anforderung der Anwendung 108 ausführen kann.
  • 1 zeigt auch einen Service-Server 115. Server 115 ist mittels Schnittstellenverbindungskreise 116 an Netz 104 angeschlossen. Die Kreisläufe 116 sind außerdem an einen internen Bus 117 des Service-Servers 115 angeschlossen. Service-Server 115 beinhaltet auch einen Mikroprozessor 118 sowie einen Programmspeicher 119. Server 115 beinhaltet auch einen Sicherheitsspeicher 120 zur Ablage der elektronischen Mitteilungen sowie einen Identifikationsspeicher 121 zur Identifizierung der Personen, die sich in Server 115 einloggen. Die Elemente 118 bis 121 sind an Bus 117 angeschlossen.
  • Speicher 119 beinhaltet Befehlscodes, mit denen Server 115 die Anforderungen, die von den unterschiedlichen Clients kommen und insbesondere die Client-Anwendungen wie z.B. Anwendung 108, verwalten kann.
  • Speicher 121 ist beispielsweise als Tabelle 121 strukturiert. Beispielsweise entspricht jede Zeile von Tabelle 121 einer Person und jede Spalte von Tabelle 121 einer Angabe zu dieser Person. Ebenso beinhaltet Speicher 121 eine Spalte 121a, die einer elektronischen Adresse entspricht, eine Spalte 121b, die einem Identifier oder „Login" entspricht, und eine Spalte 121c, die einem Passwort entspricht.
  • 1 zeigt auch einen Netzkontrollserver 122. Server 122 ist mittels Netzschnittstellenkreisläufen 123 an Netz 104 angeschlossen; die Kreisläufe 123 sind außerdem an einen internen Bus 124 von Netzkontrollserver 122 angeschlossen.
  • Netzkontrollserver 122 beinhaltet einen Mikroprozessor 125, einen Programmspeicher 126 und einen Konfigurationsspeicher 127. Die Elemente 125 bis 127 sind an Bus 124 angeschlossen.
  • Speicher 126 beinhaltet Befehlscodes, die den Mikroprozessor 125 steuern. Ein Bereich 126a beinhaltet Befehlscodes, mit denen Server 122 einen Service-Server, z.B. Server 115, abfragen kann. Bereich 126b beinhaltet Befehlscodes, mit denen Server 122 mit dem Lokalserver-Programm 109 dialogieren kann. Bereich 126c beinhaltet Befehlscodes, die der Verwaltung der Initialisierungsmitteilungen entsprechen, die von einem lokalen Serverprogramm ausgegeben werden.
  • Initialisierungspeicher 127 ist als Tabelle 127 strukturiert. Beispielsweise entspricht jede Spalte einer Person und jede Zeile einer Angabe zu dieser Person. Speicher 127 beinhaltet also eine Zeile 127a, die einem Identifier einer Person entspricht, z.B. eine Telefonnummer oder eine Internet-Adresse. Zeile 127b entspricht einem Identifier, z.B. von Speicher 111. Zeile 127c entspricht einem Passwort, Zeile 127d der Adresse eines Service-Servers und Zeile 127e einer Abfragefrequenz eines Service- Servers.
  • Sämtliche Elemente aus 1 kommen erfindungsgemäß zum Einsatz.
  • 2 zeigt, dass die Etappen des Verfahrens erfindungsgemäß in mehreren Vorrichtungen zum Einsatz kommen. Die drei betreffenden Vorrichtungen sind erstens ein Mobilclient 101, ein Netzkontrollserver 122 und ein Service-Server 115. Für die Beschreibung der Etappen des erfindungsgemäßen Verfahrens wurde ein elektronischer Messaging-Server verwendet. Von jeder dieser Vorichtungen werden also Aktionen durchgeführt.
  • 2 zeigt auch, dass für den Client 101 oder das Mobiltelefon 101 zwei Anwendungen gleichzeitig existieren, die jeweils Etappen des erfindungsgemäßen Verfahrens einsetzen. Beim Mobiltelefon 101 unterscheidet man also eine Client-Anwendung, z.B. eine Anwendung, mit der ein elektronischer Messaging-Server abgefragt werden kann, und eine Anwendung oder Programm des Lokalservers, auch „Proxy" genannt. Die Etappen des erfindungsgemäßen Verfahrens kommen damit auch in diesen beiden Programmen zum Einsatz.
  • 2 zeigt eine erste Vorab-Etappe 201 zur Sendung einer ersten Abfrageanforderung durch die Client-Anwendung 108. Diese Anforderung wird nach einem elektronischen Mitteilungsprotokoll erzeugt. Solche Protokolle sind beispielsweise die Protokolle POP und IMAP. Solche Abfrageanforderungen beinhalten einen Identifier des Server, an den sie gerichtet sind, den Identifier der Person, von der die Abfrage ausgeht, ein Passwort für diese Person und einen Identifier, um dieser Anforderung auszuführen. Es handelt sich um Konfigurationsparameter der Anwendung 108. In unserem Beispiel entspricht die Adresse des Service-Servers der Adresse von Server 115; es handelt sich um eine Internet-Adresse. Der Identifier der Person entspricht dem Inhalt von Speicher 111 und das Passwort dem Inhalt von Speicher 112. Die Adresse für die Antwort kann entweder im Routing-Protokoll enthalten sein, wenn es sich um das IP-Protokoll handelt, oder ausdrücklich in einer Anforderung enthalten sein.
  • Nach ihrer Erstellung wird die Anforderung gesendet. Hier ist in der Etappe 201 unter 'gesendet' zu verstehen, dass sie dem Mikroprozessor unterzogen wird, mit dem Befehl, mit Hilfe der funkelektrischen Hilfsmittel 105 und 102 zu senden.
  • Jedoch wird der Mikroprozessor auch vom lokalen Serverprogramm 109 gesteuert. Der Mikroprozessor weiß also, dass er sämtliche Anforderungen und sonstigen funkelektrisch übertragenen Mitteilungen abfangen muss. Damit wird zur Etappe 202 – Produktion und Sendung einer Initialisierungsnachricht – übergegangen. In dieser Etappe 202 steuern die Befehlscodes des Bereiches 109a den Mikroprozessor 107. Damit kann das Lokalserver-Programm 109 die Anforderung, die von der Anwendung 108 gesendet wurde, abfangen. Lokalserver-Programm 109 entscheidet also, dass es sich um das Senden einer ersten Anforderung handelt. Diese Erfassung ist relativ einfach; es genügt beispielsweise, einen markierten Speicher zu verwenden, auf dem gespeichert werden kann, ob durch Anwendung 108 bereits eine Anforderung erfolgt ist oder nicht. Wenn der markierte Speicher anzeigt, dass keine Anforderung erfolgt ist, dann weiß das Lokalserver-Programm 109, dass es sich um eine Initialisierungsphase handelt; es führt diese Initialisierung durch und validiert den markierten Speicher. Ansonsten weiß das Lokalserver-Programm 109, dass es sich nicht um eine Initialisierungsphase handelt.
  • In der Etappe 202 wird der Mikroprozessor auch durch die Befehlscodes des Bereichs 109b gesteuert. In der Etappe 202 erzeugt der Mikroprozessor 107 eine Initialisierungsnachricht, welche die Anforderung 101 beinhaltet. Diese Initialisierungsnachricht wird dann an den Netzkontrollserver 122 gesendet. In der Etappe 202 bedeutet ,senden', dass die Initialisierungsnachricht durch die funkelektrischen Mittel des Telefons 101 funkelektrisch ausgestrahlt wird.
  • Von Etappe 202 geht man einerseits auf eine Etappe 203 -Antwort auf erste Abfrage- und andererseits auf eine Etappe 204 -Parametrierung des Netzkontrollservers 122 – über.
  • Die Etappe 203 wird vom lokalen Serverprogramm 109 durchgeführt. In der Etappe 203 erzeugt der Mikroprozessor 107 also eine Antwort auf die in der Etappe 201 durch die Anwendung 108 erzeugte Anforderung. Es handelt sich um eine von dem benutzten Protokoll, POP oder IMAP, erzeugte Standardantwort, welche zum Beispiel angibt, dass der Service-Server 115 nicht erreichbar oder besetzt ist. Diese Antwort kann zum Beispiel auch angeben, dass keine neue Mitteilung vorliegt. Zweck der Antwort ist es, die Anwendung 108 irre zu führen. Die Anwendung 108 soll nämlich davon ausgehen, sie habe eine Verbindung mit dem Service-Server 115 hergestellt. Wenn die Antwort auf die Anforderung 1 erzeugt ist, wird sie auf die gleiche Weise gesendet wie in der Etappe 201. Das heißt, die Antwort verlässt in Wirklichkeit nie das Telefon 101. Von der Etappe 203 geht man auf eine Etappe 205 – Empfang einer Antwort auf die erste Anforderung – über. In der Etappe 205 empfängt die Anwendung 108 eine Antwort, welche in Abhängigkeit von dem Protokoll formatiert ist, das sie benutzt hat, um die Anforderung in der Etappe 201 zu senden. Diese Antwort entspricht also den Erwartungen der Anwendung 108. Die Anwendung 108 bearbeitet diese Antwort so, als sei sie vom Server 115 gesendet worden.
  • In der Etappe 204 empfängt der Netzkontrollserver 122 eine Initialisierungsnachricht. Diese Initialisierungsnachricht ermöglicht dem Mikroprozessor 125, den Konfigurationspeicher 127 zu aktualisieren. In der Etappe 204 wird der Mikroprozesor 125 durch die Befehlscodes der Bereiche 126b und 126c gesteuert. In der Etappe 204 benutzt der Mikroprozessor 125 die in der Initialisierungsnachricht enthaltenen Informationen, um den Speicher 127 zu aktualisieren. Diese Aktualisierung besteht in der Anlegung einer neuen Spalte und im Ausfüllen der Felder/Zeilen dieser neuen Spalte. Die Information über die Anforderungsfrequenz wird entweder durch die Zeitspanne zwischen den beiden ersten, durch die Anwendung 108 gesendeten Anforderungen erhalten oder vom lokalen Serverprogramm 109 direkt im Speicher 114 gelesen. Diese Anforderungsfrequenz wird in die Initialisierungsnachricht der Etappe 202 eingefügt.
  • Bei den ausgefüllten Feldern handelt es sich um die schon in den Etappen 201, 202 und bei der Beschreibung des erfindungsgemäßen Verfahrens angegebenen Felder.
  • Die Etappen 201 bis 205 bilden eine Initialisierungsphase des erfindungsgemäßen Verfahrens. Während dieser Phase arbeitet das lokale Serverprogramm 109 im Initialisierungsmodus.
  • Von der Etappe 205 geht die Anwendung 108 auf eine Etappe 206 – Senden einer zweiten Abfrageanforderung des Service-Servers 115 – über. Diese zweite Anforderung ist mit derjenigen identisch, die in der Etappe 201 gesendet wird. Sie wird also auf die gleiche Weise gesendet wie dies für die Etappe 201 der Fall ist. Unter dem Gesichtspunkt der Anwendung 108 ist die Etappe 206 mit der Etappe 201 identisch. Anschließend geht man auf eine vom lokalen Serverprogramm 109 eingerichtete Etappe 207 über.
  • In der Etappe 207 fängt das Programm 109 die zweite Anforderung auf die gleiche Weise ab, wie dies in der Etappe 202 der Fall ist. Es sendet anschließend eine Antwort auf die zweite Anforderung, wobei es so tut, als sei der Server 115 besetzt, nicht erreichbar oder als gebe es zum Beispiel keine neue Mitteilung. Anschließend geht man auf eine von der Anwendung 108 eingesetzte Etappe 208 – Empfang einer Antwort auf die zweite Anforderung – über. Die Etappe 208 ist mit der Etappe 205 identisch.
  • In der Praxis wird die Zeitspanne zwischen der Etappe 201 und der Etappe 206 vom Inhalt des Speichers 114 gesteuert, welcher der Frequenz der von der Anwendung 108 an den Service-Server 115 gesendeten Anforderungen entspricht.
  • Die Etappen 206 bis 208 zeigen die Funktionsweise des lokalen Serverprogramms 109 im Sperrmodus. In diesem Modus fängt das Programm 109 alle von der Anwendung 108 gesendeten Mitteilungen ab und antwortet ihr, dass auf dem Server 115 keine Kontextänderung vorgenommen wurde. Im Sperrmodus erfolgt im Anschluss an eine Anforderung des Servers 115 keine funkelektrische Sendung.
  • Von der Etappe 204 geht der Netzkontrollserver 122 auf eine Etappe 209 – Anforderung an die Service-Server – über.
  • In der Etappe 209 tastet der von den Befehlcodes des Bereiches 126a gesteuerte Mikroprozessor 125 die Tabelle 127 ab, um festzustellen, welchen Service-Server er abfragen soll. Diese Feststellung wird im Verhältnis zu einer nicht dargestellten inneren Uhr des Servers 122 und den Informationen der Anforderungsfrequenz der Zeile 127e vorgenommen.
  • Wenn der Mikroprozessor 125 in der Tabelle 127 eine durchzuführende Anforderung findet, benutzt der Mikroprozessor 125 die Informationen der betreffenden Spalte, um eine Abfrageanforderung an den Service-Server zu senden. Um diese Anforderung zu erstellen benutzt er die in der Spalte enthaltenen Informationen, insbesondere den Identifier 127b, das Passwort 127c und die Adresse 127d des Service-Servers. Die in der Etappe 209 vom Netzkontrollserver 122 erzeugte Abfrageanforderung des Service-Servers ist mit der Abfrageanforderung identisch, die in den Etappen 201 und 206 erzeugt werden, abgesehen davon, dass die Antwortadresse für den Service-Server 115 diejenige des Netzkontrollservers 122 ist.
  • Für eine Anforderung an einen Messaging-Server wird vorzugsweise das IMAP Protokoll benutzt. In diesem Protokoll können nämlich Anforderungen zum Erhalt von Auskünften über die Anzahl der in einem elektronischen Messaging-Server enthaltenen neuen Mitteilungen gesendet und die Kommunikationen zwischen dem Server 122 und dem Server 115 vermindert werden.
  • Die vom Server 122 gesendeten Abfrageanforderungen erreichen den Server 115 über das Netz 104. Man geht von einer Etappe 209 auf die Etappe 210 – Antwort des Service-Servers 115 – über.
  • In der Etappe 210 erhält der Server 115 eine Abfrageanforderung zur Bekanntgabe des Status eines elektronischen Messaging-Servers. Dieser elektronische Messaging-Server wird durch ein „login" 127b/111 und ein Passwort 127c/112 identifiziert. Mit Hilfe dieser Informationen kann der Mikroprozessor 118 eine Zeile in der Tabelle 121 und damit ein Messaging-Serverkonto identifizieren. Mit dieser Adresse kann der Mikroprozessor 118 im Ablagespeicher 120 die entsprechenden Mitteilungen finden. Anschließend erzeugt der Server 115 eine Antwort auf die in der Etappe 209 gesendeten Abfrageanforderung, diese Antwort wird an die Adresse des Servers 122 gesendet. Von der Etappe 210 geht man auf eine Etappe 211 – Analyse der Antwort des Servers 115 durch den Server 122 – über.
  • In der Etappe 211 stellt der Mikroprozessor 125 fest, ob sich in dem abgefragten elektronischen Messaging-Server neue Mitteilungen befinden. Diese Feststellung geschieht in Abhängigkeit von der Antwort des Servers 115 auf die in der Etappe 209 gesendeten Abfrageanforderung. Es handelt sich um eine Anforderung nach dem Protokoll IMAP, um zu erfahren, wieviel neue Mitteilungen sich in dem elektronischen Messaging-Server befinden. Die Antwort beinhaltet also eine oder eine Mehrzahl neue(r) Mitteilung(en). Wenn diese Zahl 0 ist, bedeutet das, dass sich in dem Messaging-Server keine neue Mitteilung befindet. Falls sich in dem Messaging-Server keine neue Mitteilung befindet, geht man auf die Etappe 209 über, und die Anforderungen gehen weiter; wenn sich wenigstens eine neue Mitteilung in dem elektronischen Messaging-Server befindet, geht man auf eine Etappe 212 – Freigabe eines „Proxy" – über.
  • In der Etappe 212 erzeugt der Mikroprozessor 125 eine Mitteilung zur Eröffnung eines „Proxy". Der Empfänger der Mitteilung wird mit Hilfe des Inhalts des Speicher 127 festgelegt. Der Mikroprozessor 125 kann nämlich mit Hilfe eines Identifiers 127b und eines Passworts 127c einen Identifier 127a eines Telefons 101 finden. Bei diesem Identifier handelt es sich entweder um eine Internet-Adresse oder zum Beispiel um eine Telefonnummer mit Hilfe derer eine kurze Mitteilung gesendet werden kann.
  • Bei der Mitteilung für die Freigabe eines „Proxy" handelt es sich also um eine einfache, an das lokale Serverprogramm 109 gesendete Mitteilung mit einem Befehlscode, welcher angibt, dass die Funktionsweise des lokalen Serverprogramms 109 geändert werden soll. Anschließend geht man auf eine Etappe 213 – Freigabe eines „Proxy" – über.
  • In der Etappe 213 empfängt das lokale Serverprogramm 109 die in der Etappe 212 gesendete Mitteilung. Das lokale Serverprogramm 109 weiß in diesem Fall, dass es die von der Anwendung 108 gesendeten Mitteilungen nicht mehr blockieren soll. Das lokale Serverprogramm 109 geht anschließend auf einen Relaismodus über.
  • Von der Etappe 208 geht die Anwendung 108 auf eine Etappe 214 – Sendung einer dritten Anforderung – über. Für die Beschreibung geht man davon aus, dass die Etappe 214 nach der Etappe 213 liegt. Das heißt, in dem Augenblick, in dem die Etappe 214 startet, befindet sich das Programm 109 im Relaismodus. Die Etappe 214 ist den Etappen 201 und 206 identisch. Von der Etappe 214 geht man auf eine Etappe 215 – Anforderungsrelais – über. Die Etappe 215 wird vom lokalen Serverprogramm 109 ausgelöst. In dieser Etappe verhält sich das lokale Serverprogramm 109 wie die Anwendung 108, das heißt, es sendet diesmal die Abfrageanforderung funkelektrisch. Dann geht man auf eine Etappe 216 – Antwort des Service-Servers 115 – über.
  • Im Relaismodus leitet das Programm 109 des lokalen Servers die von der Anwendung 108 gesendeten Anforderungen nicht mehr auf den Netzkontrollserver 122 um. Er verhält sich wie ein einfaches Zwischenglied in der Weiterleitung der Mitteilungen und beeinflusst weder ihren Inhalt noch ihren Empfänger. In der Etappe 216 empfängt der Server 115 eine Abfrageanforderung von einem herkömmlichen elektronischen Messaging-Server und antwortet also auf die bekannte Weise. Diese Antwort wird in der Etappe 217 vom lokalen Serverprogramm 109 abgefangen. Auch diesmal ist das Programm 109 im Relaismodus und leitet also die Antwort des Servers 115 direkt an die Anwendung 108 weiter; hierbei handelt es sich um die Etappe 218 – Bearbeiten der Antwort des Servers 115 auf die in der Etappe 214 gesendeten Anforderung durch die Anwendung 108 – eine herkömmliche und bekannte Etappe.
  • Von der Etappe 217 geht das lokale Serverprogramm 109 ebenfalls auf eine Etappe 219 über, weiche darin besteht, dass die Funktionsweise wieder auf einen Sperrmodus übergeht, wie dies in den Etappen 206 bis 208 beschrieben wurde.
  • 2bis zeigt, dass auf die Etappe 209 auch eine Etappe 220 – Sendung einer Statusmitteilung – folgen kann. Die Etappe 220 kann nämlich vom Netzkontrollserver 122 zu jedem beliebigen Zeitpunkt ausgelöst werden. Es handelt sich um das Senden einer Statusmitteilung an das lokale Serverprogramm 109. Im Idealfall tritt die Etappe 220 in regelmäßigen Abständen auf. Eine Statusmitteilung ist dazu bestimmt, einem lokalen Serverprogramm anzugeben, dass der Server 122 den Server 115 weiterhin abfragt. Von der Etappe 220 geht man über auf eine Etappe 221 – Empfang der Statusmitteilung durch die lokale Serveranwendung 109 – über. In der Etappe 221 entscheidet das Programm, ob der Server 115 weiter abgefragt werden soll oder nicht. Wenn er weiter abgefragt werden soll, geht man auf auf eine Etappe 222 – weiter abfragen – über. Die Etappe 222 besteht nämlich aus einer positiven Antwort an die Statusmitteilung. Das lokale Serverprogramm 109 sendet dann eine Antwort an den Netzkonrollserver 122, aus welcher hervorgeht, dass weiter abgefragt werden soll. Wenn nicht geantwortet werden soll, geht man auf eine Etappe 223 – Abfragen beenden – über.
  • In der Etappe 223 wird keine Antwort auf die Statusmitteilung gesandt. In diesem Fall stellt der Netzkontrollserver 122 fest, dass auf seine Statusmitteilung keine Antwort eingegangen ist, und er aktualisiert seine Konfiguration. Hierbei handelt es sich um die Etappe 224.
  • Die Etappe 224 besteht darin, dass im Speicher 127 eine Spalte gelöscht wird. Diese Spalte entspricht dem Identifier 127a, für welchen auf eine Statusmitteilung keine Antwort eingegangen ist. In der Praxis kann man davon ausgehen, dass es sich bei einer Mitteilung – „Proxy" eröffnen – um eine Statusmitteilung handelt, wobei dies aber nicht die einzig mögliche Statusmitteilung ist.
  • Eine Statusmitteilung kann ebenfalls eine Information enthalten, aus welcher hervorgeht, dass seit der letzten Statusmitteilung keine neue Mitteilung erhalten wurde.
  • In der Praxis kann die Funktionsweise des lokalen Serverprogramms 109 auch dadurch geändert werden, dass eine Zeitspanne abgelaufen ist. Wenn zum Beispiel das lokale Serverprogramm 109 seit einer gewissen Zeit vom Server 122 keine Statusmitteilung erhalten hat, kann das lokale Serverprogramm 109 der Ansicht sein, der Netzkontrollserver 122 sei nicht mehr aktiv. In diesem Fall geht das lokale Serverprogramm 109 von allein in den Relaismodus über. Im Relaismodus antwortet das lokale Serverprogramm 109 nicht mehr auf die Statusmitteilungen des Netzkontrollservers 122.
  • Der Übergang von einem Modus auf einen anderen kann ebenfalls vom Benutzer des Telefons 101 forciert werden.
  • Man sieht, dass mit der Erfindung die effektiven Verbindungen zwischen den Telefonen 101 und dem Service-Server 115 nur dann stattfinden, wenn sie nützlich sind, das heißt, wenn auf einem Messaging-Server neue Mitteilungen abgehört werden sollen.
  • Die Erfindung kann ganz einfach auf alle Verbindungen mit einem mobilen Client ausgedehnt werden, der regelmäßig einen Server abfragen muss, um festzustellen, ob es auf diesem Server eine Kontextänderung gegeben hat. In diesem Falle wird das regelmäßige Abfragen vom Netzkontrollserver 122 und nicht vom Telefon 101 durchgeführt. Dies erlaubt, den Radiofrequenzteil des Netzes nicht zu überlasten und nicht unnütz die Energie des mobilen Telefons 101 zu verschwenden.
  • In einer Variante der Erfindung leitet der Server 122, wenn er auf dem Server 115 eine Kontextänderung feststellt, den neuen Kontext, zum Beispiel neue Mitteilungen, auf den Server 122. Die Weiterleitung der Mitteilungen auf das Telefon 101 wird in diesem Fall nicht zwischen dem Telefon 101 und dem Server 115 vollzogen, sondern zwischen dem Telefon 101 und dem Server 122.
  • Zwischen der Anwendung 108 und dem Server 115 einerseits und dem lokalen Serverprogramm 109 und dem Netzkontrollserver 122 andererseits kann man unterschiedliche Kommunikationsprotokolle einrichten. Es kann nämlich vorkommen, dass der Netzkontrollserver 122 Mitteilungen auf das Telefon 101 sendet, das nicht andauernd an das Internet angeschlossen ist, vor allem in der Norm IPv4. Das bedeutet, dass das Telefon 101 nicht andauernd über eine gültige Internetadresse verfügt. In diesem Fall kann man das kurze Mitteillungsprotokoll benutzen, zum Beispiel um zwischen dem Telefon 101 und dem Server 122 eine Verbindung herzustellen. Da alle anderen Verbindungen des Telefons 101 nach außen führen, können sie nach einem durch das Telefon 101 vorgenommenene Einloggen eben dieses Telefons 101 in das Internet durchgeführt werden.

Claims (9)

  1. Verfahren zur Optimierung eines Netzverkehrs (103), welches einen mobilen Client (101) und einen Service-Server (115) beinhaltet, das folgende Etappen umfasst: – eine vom mobilen Client ausgeführte Client-Anwendung (108) sendet (201) eine erste Anforderung an den Service-Server, – ein vom mobilen Client ausgeführtes lokales Serverprogramm (109), fängt die erste an den Service-Server gerichtete Anforderung ab (202), dadurch gekennzeichnet, dass das Verfahren auch folgende Etappen umfasst: – das von einem Netzkontrollserver gesteuerte lokale Serverprogramm erzeugt (202) eine Initialisierungsnachricht aus dem Inhalt der ersten Anforderung, wobei die Initialisierungsnachricht Informationen beinhaltet, anhand derer sich ein Kontrollserver für die Client-Anwendung ausgeben kann, wobei diese Informationen einen Identifier (111) und ein Passwort (112) beinhalten, wobei die Initialisierungsnachricht auch Informationen über einen abzufragenden Service-Server (113) enthält, wie zum Beispiel seine Adresse in einem Netz und seinen Typ. – das lokale Serverprogramm (202) sendet die Initialisierungsnachricht an den Kontrollserver (122), – der Netzkontrollserver (204) empfängt die Initialisierungsnachricht und der Kontrollserver parametriert sich (204) gemäß des Inhalts der Initialisierungsnachricht, um Anforderungen an den Service-Server zu senden (209).
  2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass das Verfahren folgende Etappen umfasst: – die Client-Anwendung sendet (206) eine zweite Anforderung an den Service-Server, – das lokale Serverprogramm fängt (207) die zweite Anforderung ab und unterbricht die Übermittlung, – das lokale Serverprogramm erzeugt und sendet (207) eine Antwort an die Client-Anwendung, – die Client-Anwendung empfängt (208) die Antwort des lokalen Serverprogramms.
  3. Verfahren nach einem der Ansprüche 1 oder 2, dadurch gekennzeichnet, dass das Verfahren folgende Etappen beinhaltet: – der Kontrollserver sendet (209) eine Anforderung an den Service-Server und gibt sich dabei als Client-Anwendung aus, – der Service-Server empfängt (210) die Anforderung des Kontrollserver und antwortet darauf (210), – der Kontrollserver empfängt die Antwort und sendet (212) eine Freigabenachricht an das lokale Serverprogramm, – das lokale Serverprogramm empfängt (213) die Freigabenachricht und parametriert sich dementsprechend, – die Client-Anwendung sendet (214) eine dritte Anforderung an den Service-Server, – das lokale Serverprogramm fängt (215) die dritte Anforderung ab und sendet sie an den Service-Server weiter, – der Service-Server empfängt und bearbeitet (216) die dritte Anforderung.
  4. Verfahren nach Anspruch 3, dadurch gekennzeichnet, dass das lokale Serverprogramm die Anforderungen der Client-Anwendung blockiert (207), bis das lokale Serverprogramm vom Kontrollserver eine Freigabenachricht erhält.
  5. Verfahren nach einem der Ansprüche 1 bis 4, dadurch gekennzeichnet, dass das lokale Serverprogramm die Anforderungen der Client-Anwendung bis zum Ablauf einer vordefinierten Frist blockiert.
  6. Verfahren nach einem der Ansprüche 1 bis 5, dadurch gekennzeichnet, dass es die folgenden Etappen beinhaltet: – der Kontrollserver sendet (220) eine Statusmitteilung an das lokale Serverprogramm, – der Kontrollserver unterbricht (224) die Übermittlung der Abfrage an den Service-Server, wenn er vom lokalen Serverprogramm keine der Statusmitteilung entsprechende Antwort erhält.
  7. Verfahren nach einem der Ansprüche 1 bis 6, dadurch gekennzeichnet, dass es sich bei der Client-Anwendung um ein elektronisches Messaging-System und beim Service-Server um einen Messaging-Server handelt.
  8. Client-Vorrichtung, um auf einem Netz zu kommunizieren, zur Einrichtung von Etappen des Verfahrens nach einem der Ansprüche 1 bis 7, wobei die Client-Vorrichtung einen Programmspeicher (108) mit Befehlscodes beinhaltet, welche einer Client-Anwendung entsprechen, die Anforderungen an einen Service-Server leitet, wobei der Programmspeicher (109) ebenfalls Befehlscodes beinhaltet, welche einem lokalen Serverprogramm zum Abfangen und Bearbeiten von Mitteilungen entsprechen, die von der Client-Anwendung gesandt werden, dadurch gekennzeichnet, dass der Programmspeicher ebenfalls Befehlscodes zum Empfangen und Bearbeiten von Mitteilungen beinhaltet, welche von einem Netzkontrollserver gesendet werden, wobei das lokale Serverprogramm vom Netzkontrollserver gesteuert wird.
  9. Kontrollserver-Vorrichtung, um auf einem Netz zu kommunizieren, zur Einrichtung von Etappen des Verfahrens nach einem der Ansprüche 1 bis 7, dadurch gekennzeichnet, dass das Kontrollserver-Vorrichtung einen Konfigurationsspeicher (127) zum Speichern der Informationen einer Initialisierungsnachricht beinhaltet, wobei das Kontrollserver-Vorrichtung ebenfalls einen Programmspeicher (126) mit Befehlscodes zum Senden von Anforderungen an den Service-Server in Abhängigkeit von dem Inhalt des Konfigurationsspeichers beinhaltet, wobei der Programmspeicher ebenfalls Befehlscodes zum Senden einer Freigabe- und/oder Statusmitteilung an ein lokales Serverprogramm in Abhängigkeit von einer Antwort an eine Abfrage beinhaltet, wobei das lokale Serverprogramm vom Netzkontrollserver gesteuert wird.
DE60300432T 2002-03-05 2003-01-23 Vorrichtung und Verfahren zur Optimierung des Netzwerkverkehrs Expired - Lifetime DE60300432T2 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR0202806A FR2837042B1 (fr) 2002-03-05 2002-03-05 Procede d'optimisation d'un trafic reseau et dispositif de mise en oeuvre associe
FR0202806 2002-03-05

Publications (2)

Publication Number Publication Date
DE60300432D1 DE60300432D1 (de) 2005-05-04
DE60300432T2 true DE60300432T2 (de) 2006-02-16

Family

ID=27741446

Family Applications (1)

Application Number Title Priority Date Filing Date
DE60300432T Expired - Lifetime DE60300432T2 (de) 2002-03-05 2003-01-23 Vorrichtung und Verfahren zur Optimierung des Netzwerkverkehrs

Country Status (8)

Country Link
US (1) US7228330B2 (de)
EP (1) EP1343291B1 (de)
AT (1) ATE292351T1 (de)
DE (1) DE60300432T2 (de)
DK (1) DK1343291T3 (de)
ES (1) ES2240910T3 (de)
FR (1) FR2837042B1 (de)
PT (1) PT1343291E (de)

Families Citing this family (55)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20060195595A1 (en) * 2003-12-19 2006-08-31 Mendez Daniel J System and method for globally and securely accessing unified information in a computer network
JP4386732B2 (ja) 2002-01-08 2009-12-16 セブン ネットワークス, インコーポレイテッド モバイルネットワークの接続アーキテクチャ
US7627679B1 (en) * 2003-12-30 2009-12-01 At&T Intellectual Property Ii, L.P. Methods and systems for provisioning network services
US7856493B1 (en) * 2004-03-17 2010-12-21 Cisco Technology, Inc. Method and apparatus providing device-initiated network management
DE502005000586D1 (de) * 2005-02-11 2007-05-24 1 2 Snap Ag Client mit Speicher zum selbstständigen Ablaufen einer Applikation unabhängig vom Server
US8438633B1 (en) 2005-04-21 2013-05-07 Seven Networks, Inc. Flexible real-time inbox access
WO2006136660A1 (en) 2005-06-21 2006-12-28 Seven Networks International Oy Maintaining an ip connection in a mobile network
US20070027669A1 (en) * 2005-07-13 2007-02-01 International Business Machines Corporation System and method for the offline development of passive simulation clients
US8805425B2 (en) 2007-06-01 2014-08-12 Seven Networks, Inc. Integrated messaging
US9002828B2 (en) 2007-12-13 2015-04-07 Seven Networks, Inc. Predictive content delivery
US8107921B2 (en) 2008-01-11 2012-01-31 Seven Networks, Inc. Mobile virtual network operator
US8862657B2 (en) 2008-01-25 2014-10-14 Seven Networks, Inc. Policy based content service
US20090193338A1 (en) 2008-01-28 2009-07-30 Trevor Fiatal Reducing network and battery consumption during content delivery and playback
US8909759B2 (en) 2008-10-10 2014-12-09 Seven Networks, Inc. Bandwidth measurement
US7974194B2 (en) * 2008-12-12 2011-07-05 Microsoft Corporation Optimizing data traffic and power consumption in mobile unified communication applications
US8645660B2 (en) 2009-12-10 2014-02-04 Microsoft Corporation Automatic allocation of data replicas
US11595901B2 (en) * 2010-07-26 2023-02-28 Seven Networks, Llc Optimizing mobile network traffic coordination across multiple applications running on a mobile device
GB2495066B (en) * 2010-07-26 2013-12-18 Seven Networks Inc Mobile application traffic optimization
EP3407673B1 (de) 2010-07-26 2019-11-20 Seven Networks, LLC Koordinierung eines mobilnetzwerkverkehrs zwischen mehreren anwendungen
GB2510493B (en) * 2010-07-26 2014-12-24 Seven Networks Inc Mobile application traffic optimization
US20120149352A1 (en) 2010-07-26 2012-06-14 Ari Backholm Context aware traffic management for resource conservation in a wireless network
US8838783B2 (en) 2010-07-26 2014-09-16 Seven Networks, Inc. Distributed caching for resource and mobile network traffic management
EP2599345B1 (de) * 2010-07-26 2017-09-06 Seven Networks, LLC Verteilte implementierung dynamischer drahtlosverkehrsrichtlinien
US9563751B1 (en) 2010-10-13 2017-02-07 The Boeing Company License utilization management system service suite
US8769299B1 (en) 2010-10-13 2014-07-01 The Boeing Company License utilization management system license wrapper
US8843153B2 (en) 2010-11-01 2014-09-23 Seven Networks, Inc. Mobile traffic categorization and policy for network use optimization while preserving user experience
WO2012060995A2 (en) 2010-11-01 2012-05-10 Michael Luna Distributed caching in a wireless network of content delivered for a mobile application over a long-held request
EP2636268B1 (de) 2010-11-22 2019-02-27 Seven Networks, LLC Optimierung von ressourcenabfrageintervallen zur zufriedenstellenden beantwortung von anfragen auf mobilen vorrichtungen
EP2661697B1 (de) 2011-01-07 2018-11-21 Seven Networks, LLC System und verfahren zur reduzierung eines mobilnetzwerkverkehrs für domänennamensystem (dns)-anfragen
WO2012145544A2 (en) 2011-04-19 2012-10-26 Seven Networks, Inc. Device resource sharing for network resource conservation
US8621075B2 (en) 2011-04-27 2013-12-31 Seven Metworks, Inc. Detecting and preserving state for satisfying application requests in a distributed proxy and cache system
EP2621144B1 (de) 2011-04-27 2014-06-25 Seven Networks, Inc. System und Verfahren zur Erstellung von Abfragen über eine mobile Vorrichtung auf Basis atomisierter Verfahren zur Verkehrsentlastung für mobile Netzwerke
WO2013015835A1 (en) 2011-07-22 2013-01-31 Seven Networks, Inc. Mobile application traffic optimization
EP2737741A4 (de) 2011-07-27 2015-01-21 Seven Networks Inc Überwachung der aktivitäten von mobilanwendungen für böswilligem verkehr auf einer mobiler vorrichtung
TWI434595B (zh) * 2011-11-09 2014-04-11 Quanta Comp Inc 網路系統之連線建立管理方法及其相關系統
WO2013086214A1 (en) 2011-12-06 2013-06-13 Seven Networks, Inc. A system of redundantly clustered machines to provide failover mechanisms for mobile traffic management and network resource conservation
US8934414B2 (en) 2011-12-06 2015-01-13 Seven Networks, Inc. Cellular or WiFi mobile traffic optimization based on public or private network destination
WO2013086455A1 (en) 2011-12-07 2013-06-13 Seven Networks, Inc. Flexible and dynamic integration schemas of a traffic management system with various network operators for network traffic alleviation
US9277443B2 (en) 2011-12-07 2016-03-01 Seven Networks, Llc Radio-awareness of mobile device for sending server-side control signals using a wireless network optimized transport protocol
US9832095B2 (en) * 2011-12-14 2017-11-28 Seven Networks, Llc Operation modes for mobile traffic optimization and concurrent management of optimized and non-optimized traffic
EP2792188B1 (de) 2011-12-14 2019-03-20 Seven Networks, LLC Mobilfunknetzbenachrichtigung und nutzungsanalysesystem sowie verfahren mittels aggregation von daten in einem verteilten verkehrsoptimierungssystem
GB2499306B (en) 2012-01-05 2014-10-22 Seven Networks Inc Managing user interaction with an application on a mobile device
US8812695B2 (en) 2012-04-09 2014-08-19 Seven Networks, Inc. Method and system for management of a virtual network connection without heartbeat messages
WO2013155208A1 (en) 2012-04-10 2013-10-17 Seven Networks, Inc. Intelligent customer service/call center services enhanced using real-time and historical mobile application and traffic-related statistics collected by a distributed caching system in a mobile network
KR101380072B1 (ko) 2012-07-02 2014-04-01 닉스테크 주식회사 로컬 프락시를 이용한 정보 유출 방지 시스템
WO2014011216A1 (en) 2012-07-13 2014-01-16 Seven Networks, Inc. Dynamic bandwidth adjustment for browsing or streaming activity in a wireless network based on prediction of user behavior when interacting with mobile applications
US9161258B2 (en) 2012-10-24 2015-10-13 Seven Networks, Llc Optimized and selective management of policy deployment to mobile clients in a congested network to prevent further aggravation of network congestion
US9307493B2 (en) 2012-12-20 2016-04-05 Seven Networks, Llc Systems and methods for application management of mobile device radio state promotion and demotion
US9241314B2 (en) 2013-01-23 2016-01-19 Seven Networks, Llc Mobile device with application or context aware fast dormancy
US8874761B2 (en) 2013-01-25 2014-10-28 Seven Networks, Inc. Signaling optimization in a wireless network for traffic utilizing proprietary and non-proprietary protocols
US9326185B2 (en) 2013-03-11 2016-04-26 Seven Networks, Llc Mobile network congestion recognition for optimization of mobile traffic
WO2014204995A1 (en) * 2013-06-17 2014-12-24 Seven Networks, Inc. Methods and systems for providing application programming interfaces and application programming interface extensions to third party applications for optimizing and minimizing application traffic
US10216549B2 (en) 2013-06-17 2019-02-26 Seven Networks, Llc Methods and systems for providing application programming interfaces and application programming interface extensions to third party applications for optimizing and minimizing application traffic
US9065765B2 (en) 2013-07-22 2015-06-23 Seven Networks, Inc. Proxy server associated with a mobile carrier for enhancing mobile traffic management in a mobile network
US10078835B2 (en) * 2014-03-05 2018-09-18 Mastercard International Incorporated Authentication token for wallet based transactions

Family Cites Families (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5673322A (en) * 1996-03-22 1997-09-30 Bell Communications Research, Inc. System and method for providing protocol translation and filtering to access the world wide web from wireless or low-bandwidth networks
US5948066A (en) * 1997-03-13 1999-09-07 Motorola, Inc. System and method for delivery of information over narrow-band communications links
GB9715966D0 (en) * 1997-07-30 1997-10-01 Ibm Data communications management for use with networking applications and for mobile communications environments
US20020002615A1 (en) * 1998-09-18 2002-01-03 Vijay K. Bhagavath Method and apparatus for switching between internet service provider gateways
US6507867B1 (en) * 1998-12-22 2003-01-14 International Business Machines Corporation Constructing, downloading, and accessing page bundles on a portable client having intermittent network connectivity
GB2366163A (en) * 2000-08-14 2002-02-27 Global Knowledge Network Ltd Inter-network connection through intermediary server
US6895444B1 (en) * 2000-09-15 2005-05-17 Motorola, Inc. Service framework with local proxy for representing remote services
US6895425B1 (en) * 2000-10-06 2005-05-17 Microsoft Corporation Using an expert proxy server as an agent for wireless devices
JP4409788B2 (ja) * 2001-05-10 2010-02-03 富士通株式会社 無線データ通信網切替装置と無線データ通信網切替処理用プログラム
US20030149720A1 (en) * 2002-02-06 2003-08-07 Leonid Goldstein System and method for accelerating internet access

Also Published As

Publication number Publication date
EP1343291B1 (de) 2005-03-30
FR2837042B1 (fr) 2005-04-08
ES2240910T3 (es) 2005-10-16
US7228330B2 (en) 2007-06-05
EP1343291A1 (de) 2003-09-10
US20030172112A1 (en) 2003-09-11
DE60300432D1 (de) 2005-05-04
FR2837042A1 (fr) 2003-09-12
ATE292351T1 (de) 2005-04-15
DK1343291T3 (da) 2005-05-30
PT1343291E (pt) 2005-06-30

Similar Documents

Publication Publication Date Title
DE60300432T2 (de) Vorrichtung und Verfahren zur Optimierung des Netzwerkverkehrs
DE69226436T2 (de) Netzwerksüberwachungsverfahren und vorrichtung
EP1436676B1 (de) Verfahren zum bedienen und zum beobachten von feldger ten
EP1436677B1 (de) Verfahren zur inbetriebnahme eines bedien- und beobachtungssystems von feldgeräten
DE10225786A1 (de) Verfahren und Vorrichtung zur Übertragung, zum Senden und/oder zum Empfang von Informationen in Verbindung mit einem Fahrzeug
DE60301194T2 (de) System und Verfahren zur Übertragung von Multimediainhalten zu mobilen Endgeräten
DE69921446T2 (de) Übertragungsstruktur für industrielle prozesssteuerungssysteme
WO2002021350A1 (de) Kurznachrichtendienst bestellwesen
EP1283632B1 (de) Verfahren und Anordnung zur Übertragung von Daten
DE102017127903A1 (de) Anbindungsvorrichtung für einen Datenaustausch zwischen einem Feldbusnetzwerk und einer Cloud
DE10151119C2 (de) Verfahren zum Erfassen von mehreren Feldgeräten in einer Gerätekonfiguration
DE102006049131B4 (de) Verfahren und System für Netzwerkdienste bei einem mobilen Fahrzeug
DE60114186T2 (de) Nachrichten-Vermittler
DE60004216T2 (de) Verbindungskennung
DE10316236A1 (de) Verfahren und Anordnung zur Konfiguration einer Einrichtung in einem Datennetz
DE102004056536A1 (de) Steuervorrichtung der drahtlosen Netzkommunikation und Netzsystem
DE10151117A1 (de) Verfahren zum Ausbilden einer Bedienfunktion von Feldgeräten und Feldgerät
DE10260404A1 (de) System und Verfahren zur Überwachung von technischen Anlagen und Objekten
DE60036503T2 (de) Verfahren zur Kommunikation zwischen Fernobjekten
EP1518386B1 (de) System und verfahren zur direkten kommunikation zwischen automatisierungsgeräten
DE102011116251B4 (de) Nachrichtenübermittlungssystem und Verfahren zum Übertragen einer Nachricht von einem Server zu einem Fahrzeug
DE60006384T2 (de) Gateway in einem funksystem
EP1285541B1 (de) Übermittlung von dienstesteuerinformationen über wenigstens eine zwischenstation
DE60104672T2 (de) System zur überwachung von terminals
EP1435026B1 (de) System und verfahren zur datenausgabe eines geräts, insbesondere eines automatisierungsgerät über eine standardisierte schnittstelle mit variablenersetzung über einen echoserver

Legal Events

Date Code Title Description
8364 No opposition during term of opposition
8328 Change in the person/name/address of the agent

Representative=s name: HAMMONDS LLP, LONDON, GB

R082 Change of representative

Ref document number: 1343291

Country of ref document: EP

Representative=s name: J D REYNOLDS & CO., GB