DE69834579T2

DE69834579T2 - Http- sitzung- überwachung

Info

Publication number: DE69834579T2
Application number: DE69834579T
Authority: DE
Inventors: Fil Annandale FEIT
Original assignee: British Telecommunications PLC
Current assignee: British Telecommunications PLC
Priority date: 1997-12-23
Filing date: 1998-12-23
Publication date: 2007-05-03
Anticipated expiration: 2018-12-24
Also published as: CA2313406A1; CN1283356A; JP4318854B2; EP1042894B1; EP1042894A1; ES2264222T3; JP2002500404A; WO1999034571A1; CN1113517C; US6178439B1; CA2313406C; DE69834579D1

Description

Die Erfindung betrifft Datenübertragungen in Netzwerken, wie sie beispielsweise im Internet auftreten, und sie bezieht sich insbesondere auf eine Sitzungskontrolle für HTTP-Kommunikationen über das Internet.
Bisheriger Stand der Technik
Das Internet ist ein dezentrales Netzwerk (Distributed Network), das mehrere Server umfasst, die mit dezentral angeordneten Clients kommunizieren. Das World Wide Web ist eine Bezeichnung für den im Internet verfügbaren Bestand an Servern. Das Web bildet so ein Kommunikationsmedium für die Datenübertragung zwischen einem Client und einem beliebigen, im Internet verfügbaren Server.
Clients im World Wide Web sind üblicherweise Web-Browser. Diese bestehen aus Programmen, die Anfragen an Server im Internet richten und die von dem Server zurückgesendeten Seiten anschließend verarbeiten und darstellen. Der World Wide Webserver wiederum ist ein Programm, das Anfragen von den Browsern bearbeitet und die anfragenden Browser mit Dokumenten versorgt. Diese Dokumente sind üblicherweise in der Hypertext Markup Language (HTML) gehalten, einer Sprache, die im World Wide Web von den Browsern und Servern allgemein erkannt wird. Um die von einem Server zurückgesandten Webseiten zu lesen, kann ein Browser für das Anzeigen der zurückgesandten Seite eine Skriptsprache ausführen.
Weit verbreitete Skriptsprachen sind das so genannte JavaSkript und das Visual Basic Skript. Die Hypertext Markup Language (HTML) ist ein Anweisungsformat, das zur Information des Browsers bezüglich der Anzeige einer zurückgesandten Seite verwendet wird. Es kann auch Hintergrundinformationen angeben, wie zum Beispiel einander abwech selnde Grafik oder Skriptsprachen. Beim Übertragen der Webseiten zwischen dem Server und dem Browser wird das so genannte Hypertext Transfer Protocol (HTTP) als Übertragungsprotokoll verwendet. Es handelt sich um das vom World Wide Web verwendete Übertragungsprotokoll für die Koordinierung der Übertragungen zwischen einem Webserver und einem Webbrowser.
Gewöhnlich fordert und erhält ein Webbrowser von den Webservern "statische" World Wide Webseiten. Statische Webseiten sind dadurch gekennzeichnet, dass die Seitendaten vorgefasst und unveränderlich sind. Bisweilen führt ein Webserver jedoch Programme zum Zustellen dynamischer Inhalte an einen Browser aus. Wenn ein Server zum Beispiel mit einer Informationsdatenbank kommuniziert, einer Datenbank, auf die ein Anwender mittels eines Browsers zugreifen und diese ändern kann, kann der Server Webseiten zustellen, die die Datenbankinformation in einem zeitnahen Zustand enthalten. Das bedeutet, wenn ein Anwender den Webserver mittels eines Browsers kontaktiert, um auf einen Datenbankeintrag zuzugreifen und diesen zu ändern, dann wird ein anderer Browser, der später auf den Server zugreift, die geänderte Datenbankinformation abrufen. Ein Mechanismus, der es einem Webserver ermöglicht, ein Programm für die Zustellung von dynamischen Inhalten auszuführen, wird Common Gateway Interface (CGI) genannt.
Gegenwärtig enthält jeder Server im Web ein Zugriffsprotokoll. Dieses Protokoll ist eine Datei, die Einzelheiten bezüglich jedes Zugriffs auf den Webserver durch einen Browser im Internet enthält. Die in diesem Protokoll enthaltenen Einzelheiten umfassen das Zugriffsdatum, die Zugriffszeit, die Identifikation des anfordernden Computers (Adresse), die angeforderte Information, wie viel Information an den Anwender gesendet wurde und möglicherweise den Status der Übertragung. Ferner umfasst jeder Browser (Client) auf dem Web einen Cache-Speicher, der eine gewisse Anzahl abgefragter Webseiten aufnimmt, sodass diese Sei ten, damit sie schnell durch den Benutzer gelesen werden können, nicht mehr neu über das Internet von einem Server abgerufen werden müssen.
Die Zeitspanne, während der zwei Computer (zum Beispiel ein Server und ein Browser) miteinander verbunden sind, wird als eine "Sitzung" bezeichnet. Ganz allgemein dauert eine Sitzung gewöhnlich von dem Zeitpunkt, an dem ein Client die Kommunikation mit dem Server eröffnet, bis zu dem Zeitpunkt, an dem er die Kommunikation beendet. Auf dem Web ist eine Sitzung jedoch leicht abweichend definiert. Bei einigen Datenübertragungen zwischen einem Client und einem Server, die nicht über das Internet stattfinden, bauen Client und Server zwischen sich eine Verbindung auf, während deren der Client vom Server Information anfragen kann und der Server die Information an den Client liefert. In diesen Fällen erstreckt sich eine Sitzung zwischen dem Client und dem Server von dem Zeitpunkt, ab dem die Verbindung zwischen dem Client und dem Server zustande gekommen ist, bis zu dem Zeitpunkt, wenn der Client oder der Server die Sitzung beenden. Während der Sitzung können eine beliebige Anzahl von Datenübertragungen und Datenanfragen zwischen dem Client und dem Server stattfinden. Im Web veranlassen die Beschränkungen des Hypertext Transfer Protocols und der World Wide Web-Struktur jedoch die Clients und Server, auf dem Web ein nicht standardgemäßes Konzept einer "Sitzung" zu befolgen. Auf dem Web besteht eine Sitzung nur aus der Zeitspanne, während der eine Seite (unabhängig davon, ob es sich um Datendatei, Bilddatei etc. handelt) angefordert und für einen Anwender (Browser) abgerufen wird. Jede Sitzung zwischen einem Webclient und einem Webserver beläuft sich so auf eine Anforderung des Clients an den Server für eine Seite und eine Übertragung der Seite von dem Server an den Client. Die im Protokoll auf dem Server aufgezeichnete Sitzungsinformation lässt daher das Datum der Seitenanforderung, die Zeit der Anfrage nach der Seite, den Computer, der die Seite anfordert, die Dateiinformation zum Identifizieren der angeforderten Seite, die Anzahl der an den anfragenden Computer zum Zustellen der Seite übersandten Bytes und möglicherweise den Status der Übertragung erkennen.
Das Internet bildet somit nicht den klassischen Fall, wonach sich ein Clientcomputer mit einem anderen Servercomputer verbindet, um zum Beispiel auf eine Datenbank zuzugreifen. Im klassischen Fall prüft ein Anwenderclient einen Datenbankdatensatz, während er mit dem Server verbunden bleibt. In einem solchen Fall kann der Server die Dauer des Datenbankzugriffs durch den Client aufzeichnen. Diese Aufzeichnungen können, da die Sitzungen durch die Zeitspanne von der Verbindung mit der Datenbank bis zu deren Verlassen definiert sind, zur statistischen Analyse im Hinblick auf die Zeit verwendet werden, die Anwender bei der Sichtung der Datensätze verbringen. Auch kann der Datenbankdatensatz gesperrt werden, um andere daran zu hindern, darauf zuzugreifen, bevor der Client fertig ist.
Auf Internetverbindungen trifft dies nicht zu, da eine Sitzung nicht durch die gesamte Verbindungszeit zwischen einem Client und einem Server definiert ist, sondern eher durch eine einzelne Seitenanfrage und eine einzelne Seitenzustellung. Im Falle des Internets besteht keine Chance, dass der Server erkennt, wann der Anwender die Benutzung eines bestimmten Datensatzes beendet hat oder wie lange der Anwender einen bestimmten Datensatz eingesehen hat. Frühere Verfahren versuchten, dem zu begegnen, indem sie manuelle Mechanismen zum Informieren des Servers darüber verwendeten, wann ein Benutzer mit einem Datensatz abgeschlossen hatte; aber solche Systeme waren auf den Client angewiesen und ließen sich nicht auf dem Server alleine realisieren. Daher gewährleistet die gegenwärtige Webstruktur keine effektive Lösung, wenn es für einen Server wichtig wäre, genau zu erfahren, wann ein Anwender mit einem Datensatz abgeschlossen hat, oder genau zu erfahren, wie lange ein Anwender einen Datensatz gesichtet hat.
Ein Beispiel dafür, wie dieses Problem in der Internetumgebung auftritt, zeigt sich, wenn zwei Anwender über das Web auf Informationen in einer Datenbank zuzugreifen versuchen. Für das Beispiel wird angenommen, dass Anwender A von einem Produktverzeichnis Informationen für ein bestimmtes Produkt X in einem Warenhaus anfordert. Das Warenhaus nutzt einen Server auf dem Web, um Informationen bezüglich des Umfangs des Lagerbestands für verschiedene Produkte an Anwender zu liefern. Für das Beispiel wird ferner angenommen, dass gerade wenn Anwender A die Lagerbestandsinformation abruft, 200 Einheiten des Produkts X im Warenhaus verfügbar sind. Der Warenhaus-Server greift auf Anfrage von Anwender A auf seine Datenbank zu, die den Lagerbestand des Produkts X ausweist, entnimmt ihr die Bestandsmenge "200" und stellt eine Seite an den Anwender A zu, die diese Menge angibt. Es wird angenommen, dass ein weiterer Anwender, Benutzer B, dieselbe Lagerbestandsinformation für das Produkt X abruft. Der Warenhaus-Server würde die Seitenanfrage von Anwender B erhalten, seine Datenbank einsehen, einen Bestand des Produktes X von 200 erkennen und eine Seite zustellen, die einen Lagerbestand für das Produkt X von "200" verfügbaren Einheiten ausweist. Ein Problem tritt dann auf, wenn Anwender A den Warenhaus-Server in einer anderen Seitenanfrage mitteilt, dass er 150 Einheiten von den 200 verfügbaren bestellt. Der Warenhaus-Server würde als Reaktion auf die Bestellung des Anwenders A die Verringerung um 150 Einheiten in seine Datenbank schreiben. Dann versucht Anwender B von dem Warenhaus-Server 100 Einheiten anzufordern, indem er eine Bestellanforderung an den Warenhaus-Server sendet. Durch den Warenhaus-Server ist ein Problem aufgetreten, da er Bestellungen für 250 Einheiten angenommen hat, wo nur 200 verfügbar sind.
Entscheidend für das obige Beispiel ist, dass der Warenhaus-Server die Seite in Erwiderung auf die Seitenanfragen des Anwenders B nicht an den Anwender B überstellt, bevor er Kenntnis davon hat, dass Anwender A mit dieser Seite abgeschlossen hat. Solange Anwender A dem Wa renhaus-Server nicht durch irgendeinen Mechanismus manuell anzeigt, dass er seine Nutzung der Lagerbestandsseite für das Produkt X beendet hat, kann der Warenhaus-Server nicht erkennen, ob die Zustellung derselben Lagerbestandsseite für das Produkt an den Anwender B aktuell und zutreffend ist.
Ein weiteres Beispiel, bei dem die beschränkte Definition einer Sitzung auf dem Web zu Problemen führt, ergibt sich, wenn eine Sitzungskontrolle zu statistischen Zwecken gefordert ist. Diese treten zum Beispiel dann auf, wenn im Web werbende Gesellschaften wissen möchten, wie lange jemand ihre Seite oder eine Seite mit ihrer Werbung betrachtet hat. Mit der augenblicklichen Definition einer Websitzung, wonach eine Sitzung einfach aus einer Seitenanforderung und einer Seitenzustellung besteht, kann ein Server ohne manuelle Mechanismen nicht wissen, wie lange ein Anwender eine Seite oder Werbung betrachtet. Daher kann ein Server, ohne auf irgendeine Weise die Beendigung der Verwendung einer bestimmten Seite durch einen Client zu erkennen, nicht wissen, wie lange ein Anwender eine Seite eingesehen hat.
Die 1 zeigt den gegenwärtigen Stand bei Internetsitzungen. Das System von 1 enthält eine Reihe von Clients, von Client Nr. 1 bis Client Nr. n. Die Clients haben über die Internetverbindungen 10 Zugriff auf eine Anzahl von Servern, einschließlich Server 12. Der Server 12 erhält, wie in der 1 dargestellt ist, von den Clients während der mit "A" und "B" bezeichneten Sitzungen Anfragen.
Während Sitzung A informiert Client Nr. 1 den Server 12 über das Internet 10, dass er eine bestimmte ausgewiesene Seite empfangen möchte ("gib mir eine Seite"). Der Server 12 erwidert auf diese Anfrage durch Zusammenstellen dieser Seite und deren Übertragung über das Internet 10 an den Client Nr. 1 ("hier ist Ihre Seite"). Dieses Kommunikationspaar ("gib mir eine Seite" und "hier ist Ihre Seite") stellt die ganze Übertragung zwischen dem Client Nr. 1 und dem Server 12 für die gesamte Sitzung "A" dar. Gleichermaßen kann auch Client Nr. n, wie als Sitzung "B" dargestellt, Seiten vom Server 12 anfordern. In der Sitzung B fordert Client n ebenfalls eine Seite vom Server 12 an und erhält die Seite vom Server 12.
Wie oben ausgeführt wurde, treten Probleme auf, wenn Client Nr. 1 und Client Nr. n während der Sitzung A und der Sitzung B im Großen und Ganzen gleichzeitig dieselbe Seite vom Server 12 anfordern und hierbei die Datensätze im Server 12 in einer sich überschneidenden Weise ändern. In einem solchen Fall kann also der Server 12 die Datenbank 16 als Reaktion auf sich überschneidende Anforderungen von Clients fehlerhaft ändern. Probleme treten ferner auch dadurch auf, dass der Server 12, selbst wenn er die Sitzungszeiten in seinem Zugriffsprotokoll 14 aufzeichnet, nicht erkennen kann, wie lange eine Sitzung A oder Sitzung B dauert, da die Sitzung jeweils einzig mit einer Seitenanforderung und einer Seitenzustellung beginnt bzw. endet.
Von Crespo et al. wird in "Responsive interaction for a large Web application: the meteor shower architecture in the WebWriter II Editor", Computer Networks and ISDN Systems 29 (1997) 1507-1517, ein Editor zur direkten HTML-Bearbeitung beschrieben, der in einem Webbrowser ausgeführt wird und (von einem Server) die Datenstruktur eines Dokuments auf das zugegriffen werden soll, auf den Browser herunter lädt. Dies ermöglicht die lokale Ausführung aller auf dem Dokument auszuführenden Operationen. Die Bedienschnittstelle beruht auf HTML-Frames und umfasst einzelne Frames für die Voransicht des Dokuments und zur Darstellung allgemeiner und spezieller Bedienungskonsolen. Die im JavaSkript-Code erfolgende Bearbeitung erfordert aber das Herunterladen von ca. 20 HTML-Seiten, die nach Bedarf herunter geladen werden. Diese Druckschrift behandelt nicht die oben besprochenen Problemstellungen.
In der US-Patentschrift 5862325 (Reed et al.) wird ein System für die Übertragung von Daten, Metadaten und Methoden von einem Providercomputer über ein Kommunikationsnetzwerk an einen Computer für Verbraucher beschrieben. Die übertragene Information steuert die Kommunikationsverbindung einschließlich Rückmeldungen des Verbrauchercomputers, Aktualisierung von Information und Verfahrensvorgängen für zukünftige Übertragungen. Die sich im Providercomputer ändernde Information wird, um die Kontinuität der Verbindung zu erhalten, automatisch über das Kommunikationssystem auf dem Verbrauchercomputer aktualisiert. Die Übertragung von Metadaten und Methoden erlaubt eine intelligente Informationsverarbeitung durch den Verbrauchercomputer und eine kombinierte Kontrolle von Art und Inhalt nachfolgend durch den Provider und Verbraucher übertragener Information. Eine Kombination der Provider- und Verbraucherprogramme und Datenbanken soll auch zusätzliche Funktionalitäten berücksichtigen, einschließlich einer Koordinierung von mehreren Benutzern einer einzelnen Datenbank. Auch wenn diese Offenbarung Anweisungen in einem Download von einem Server an einen Client einschließt, wobei die Anweisungen den Client veranlassen, eine Zustellbestätigung an den Server zu senden, werden die oben angesprochenen Probleme des Stands der Technik nicht weiter behandelt.
Zusammenfassung der Erfindung
Die vorliegende Erfindung sieht eine solche Sitzungskontrolle im Internet vor, dass ein Server bestimmen kann, wann und wie lange ein Client auf eine von einem Server zugestellte Seite zugreift. Die vorliegende Erfindung erreicht dies durch Anhängen einer Information an jede an einen Client zugestellte Seite zum Erkennen eines "Herzschlag"-Programms, das, während die zugestellte Seite betrachtet wird, die Seite veranlasst, an den Server in festgelegten Zeitabständen ein Pulssignal zurückzusenden. Im einfachsten Beispiel würde ein Server eine Seite an einen Client liefern, die, bis der Client die Sichtung der Seite beendet hat, jede Minute ein Pulssignal an den Server zurücksendet.
Durch Aufzeichnen dieser von der Seite zurückgesandten Pulssignale kann der Server durch einen Blick auf die Anzahl der von der Seite während des Sichtens zurückgesandten Pulsignale ungefähr erkennen, wie lange ein Client eine bestimmte Seite gesichtet hat. Wenn nach obigem Beispiel beispielsweise fünf Pulssignale zurückgesandt wurden, kann der Server daraus schließen, dass der Client die Seite für mehr als fünf Minuten, aber weniger als sechs Minuten gesichtet hat. Auch dem Client wäre nach Ablauf von sechs Minuten bekannt, dass die Seite freigegeben wurde und auf sie durch einen neuen Client ohne Überschneidungen mit der ursprünglichen zugegriffen werden könnte.
Auch wenn die vorliegende Erfindung keine reine Sitzungssteuerung über das Internet vorsieht, so stellt sie den Servern zur Vermeidung von Überschneidungen und zum Erzeugen statistischer Informationen doch gute Daten zur Verfügung, die erkennen lassen wann und für wie lange auf eine Seite zugegriffen wird. Die vorliegende Erfindung kann weiterhin zum Abgleichen der Häufigkeit der Pulssignale gegenüber der Toleranz der statistischen Erhebung angewandt werden. Das heißt, Pulssignale, die jede Minute wiederholt werden, belasten das Internet und den Prozessor des Client mehr als beispielsweise Pulssignale, die alle fünf Minuten wiederholt werden, bieten jedoch genauere Resultate.
Gemäß einem Gesichtspunkt der Erfindung wird ein Netzwerkserver angegeben, der so angeschlossen ist, dass Clients der Zugriff auf ein Netzwerk ermöglicht wird, wobei die Clients auf den Netzwerkserver in Übereinstimmung mit einem Sitzungsprotokoll zugreifen, das eine Sitzung als eine Sitzungsanforderung und eine Sitzungsrückmeldung festlegt und der Netzwerkserver einen Speicher zum Speichern von Seiteninformationen und einen Seitenkompilierer umfasst, um von einem anfragenden Client eine Anforderung einer Seite zu erhalten, in Erwide rung auf die Anfrage unter Verwendung einiger der gespeicherten Seiteninformationen eine Seite zu erstellen und die erstellte Seite über das Netzwerk an den anfragenden Client zu übermitteln, wobei der Seitenkompilierer eine Seiten-Skriptfunktion an die erstellte Seite anfügt und diese mit der erstellten Seite überträgt, und wobei die Seiten-Skriptfunktion Anweisungen enthält, die ausgeführt eine Vielzahl zusätzlicher Mitteilungen erzeugen, die vom anfragenden Client in einem vorbestimmten Zeitabstand oder in vorbestimmten Zeitabständen an den Server gesandt werden.
Gemäß einem anderen Gesichtspunkt der Erfindung ist ein Verfahren zum Erstellen einer Seite für die Übertragung auf einem Netzwerk mit Clients und Servern unter Verwendung eines Sitzungsprotokolls vorgesehen, das jede Sitzung als eine Sitzungsanfrage und eine Sitzungsrückmeldung definiert, und das das Empfangen einer Seitenanforderung von einem anfragenden Client, das Abrufen von Seiteninformationen zum Aufbau einer angeforderten Seite, das Kompilieren der Seiteninformationen in die angeforderte Seite und das Übermitteln der Seite über das Netzwerk an den anfragenden Client umfasst, wobei an die angeforderte Seite eine Seiten-Skriptfunktion zur Übertragung mit dieser angefügt ist und die Seiten-Skriptfunktion Anweisungen enthält, die ausgeführt eine Vielzahl zusätzlicher Meldungen erzeugen, die vom anfragenden Client in einem vorbestimmten Zeitabstand oder in vorbestimmten Zeitabständen gesendet werden.
Kurze Beschreibung der Zeichnungen
1 ist eine vereinfachte Schemazeichnung einer Internetsitzung zwischen Clients und Servern im Internet gemäß dem Stand der Technik,
2 bis 4 zeigen schematische Zeitschaubilder zum Kennzeichnen der zwischen einem Client und einem Server gemäß mehrerer Ausfüh rungsbeispiele der vorliegenden Erfindung stattfindenden Übertragungen,
5 ist ein Blockschema eines Ausführungsbeispiels für Server 12, der gemäß eines Ausführungsbeispiels der Erfindung kommuniziert,
6 ist ein Beispiel für einen Eintrag in das Zugriffsprotokoll auf dem Server 12 von 5 gemäß eines Ausführungsbeispiels der vorliegenden Erfindung,
7 zeigt eine Schemazeichnung des Beispiels für Server 12 von 5 gemäß eines weiteren Ausführungsbeispiels der vorliegenden Erfindung,
8 ist ein schematisches Zeitschaubild der Übertragungen innerhalb und außerhalb von Server 12 während einer beispielhafter Kommunikationssitzung mit einem Client, und
9 ist ein schematisches Zeitschaubild, das eine Kommunikationssitzung zwischen einem Server und zwei unterschiedlichen Clients gemäß einem Ausführungsbeispiel der vorliegenden Erfindung darstellt.
Ausführliche Beschreibung der bevorzugten Ausführungsformen
Immer wenn ein Client, wie beispielsweise der Client Nr. 1 von 1, an den Server 12 eine Anforderung für eine Seite sendet, erstellt Server 12 für die Anforderung einen Protokolleintrag im Zugriffsprotokoll 14. Ein typischer Protokolleintrag ist im Folgenden dargestellt: elara.planet.bt.co.uk--[12/may/1994:10:10:11-400]"GET/icons/blank.xbm HTTP/1.0" 200 509 Im obigen Protokolleintrag stellt "elara.planet.bt.co.uk" die Adresse des Client-Computers dar. Datum und Zeit der Anfrage sind in Klammern angegeben und durch den Anforderungstypus (im Beispiel "400") abgeschlossen. Der Information in den Klammern folgt eine Anweisung zum Abrufen einer angegebenen Datei ("icons/blank.xbm"). Dem folgt das Protokoll (HTTP/ 1.0), gefolgt vom Rückgabecode (200) und der Anzahl der Bytes der angeforderten Datei (509).
Im obigen Beispiel bedeutet der in das Zugriffsprotokoll 14 des Servers 12 eingefügte Eintrag eine Anfrage durch den Client "elara.planet.bt.co.uk" am 12. Mai 1994 um 10:10:11 Uhr zum Abrufen der Datei namens "icons/blank.xbm" vom Server 12 im HTTP-Format. Ein ähnlicher Eintrag wird im Zugriffsprotokoll 14 des Servers 12 jedes Mal erzeugt, wenn ein Client in einer Sitzung (A oder B von 1) von dem Server 12 eine Seite anfordert. Eine Ausprägung der Protokolldatei 14 in der oben beschriebenen Art ist im Stand der Technik bekannt und stellt ein genaues Verzeichnis der Anzahl und der Zeiten der verschiedenen Sitzungen dar, während deren Clients Seiten vom Server 12 abrufen. Eine Aufzeichnung der Zeitdauer, während der ein Client auf eine bestimmte Seite zugreift, ist jedoch nicht enthalten.
Früher stellten einige Programme für die Vornahme von Web-Auswertungen statistische Mutmaßungen darüber an, wie lange ein Client auf einer bestimmten Seite verweilte, indem sie die von den Servern verfügbar gemachte Historie der Zugriffe bestimmter Clients auf die Seite prüften. Das Zugriffsprotokollverfahren nach dem Stand der Technik bietet jedoch keine Möglichkeit, zu erfahren, ob die statistischen Mutmaßungen gültige Indikatoren für die Zeitdauer sind, die Clients auf bestimmten Seiten verweilen.
Die vorliegende Erfindung umgeht den Mangel an Sitzungsinformationen auf dem Web durch Erzeugen einer Reihe von potentiellen Sitzungsendeanfragen. In seiner einfachsten Ausführungsform erfordert die vorliegende Erfindung nur eine, in jede auf dem Server 12 gemeldete Seite zu setzende Skriptsprachfunktion zusammen mit einem einfachen CGI-Skript, das auf dem Server 12 vorzusehen ist. Die in jede auf dem Server 12 verfügbare Seite gesetzte Skriptsprachfunktion bewirkt, dass die Seite in bestimmten Zeitabständen eine Mitteilung in Form eines Pulssignals an den Server 12 erzeugt. Das einfache, auf dem Server 12 platzierte CGI-Skript empfängt dann diese Pulssignale, zeichnet sie auf und erwidert sie in der weiter unten genauer beschriebenen Art. In einer laienhaften Formulierung teilen die von der Seite bereitgestellten Pulssignale dem Server im Wesentlichen mit, dass der Client die Seite weiterhin verwendet und die Rückmeldung des Servers ist eine Antwort, dass "keine Veränderungen an der gegenwärtigen Seite" vorliegen. Auf diese Art bleibt das vorliegende Sitzungskontrollsystem für den Anwender im Wesentlichen unsichtbar.
2 zeigt ein Ausführungsbeispiel der vorliegenden Erfindung, worin ein Client und ein Server die Sitzungskontrollinformation nach der vorliegenden Erfindung austauschen. Zu beachten ist, dass in 2 die Übertragungen von dem Client an den Server mit Rechtspfeilen und die Übertragungen von dem Server an den Client mit Linkspfeilen dargestellt sind. In der 2 sind die Übertragungen chronologisch von oben nach unten angeordnet. Es wird darauf hingewiesen, dass die 3, 4, 5, 6, 8 und 9 auf ähnliche Weise angelegt sind, wobei die chronologischen Abfolgen vom oberen Bereich der entsprechenden Figur zu derem unteren Bereich verlaufen.
In der 2 sind die ersten zwei Übertragungen zwischen dem Client und dem Server identisch mit dem Stand der Technik, wie er mit Bezug auf die 1 beschrieben wurde. Das bedeutet, dass der Client eine Sitzung (beispielsweise Sitzung A in 1) mit einer Anfrage an den Server "gib mir Seite X" eröffnet. Der Server protokolliert dann diese Anfrage entsprechend dem oben beschriebenen Beispielprotokolleintrag in das Protokoll 14. Mit der Rückmeldung "hier ist Ihre Seite" antwortet dann der Server dem Client mit der angeforderten Seite. Diese Seite unterscheidet sich von den Seiten nach dem Stand der Technik insofern, dass die Seite die Skriptsprachfunktion enthält, die die späteren Pulssignale erzeugt. Ein Beispiel für eine Skriptsprachfunktion wird nachstehend ausführlich beschrieben.
Sobald der Client die Seite erhalten hat, wartet die Skriptfunktion eine vorbestimmte Zeit X₀ und erzeugt dann eine Anfrage an den Server, worin sie dem Server im Wesentlichen mitteilt "ich bin immer noch hier"; dies bedeutet, dass der Client die Seite X zur Zeit X₀, nachdem die Seite vom Client empfangen wurde, immer noch verwendet. Die erste, auf den Erhalt der Seite folgende Antwort an den Server wird als das erste Pulssignal bezeichnet. In Reaktion auf das erste Pulssignal protokolliert der Server das Pulsignal im Zugriffsprotokoll und antwortet dann, indem er an den Client im Wesentlichen eine Null-Seite sendet, deren Bedeutung sich als "in Ordnung -- wie ich höre, bist Du immer noch auf Seite X" interpretieren lässt.
Im Anschluss an den ersten Zeitabschnitt X₀, bei dem das erste Pulssignal an den Server gesandt wurde, wartet die Seite einen weiteren Zeitabschnitt (X₁) ab, bevor sie das zweite Pulssignal an den Server sendet. Der Server protokolliert dieses Pulssignal und antwortet. Der Vorgang setzt sich in den Zeitabschnitten X₂ und X₃ fort. Nach dem Senden des dem Zeitabschnitt X₃ folgenden Pulssignals merkt der Server, dass der Client die Seite X verlassen hat, da die Pulssignale vom Client aufgehört haben.
Auf jeden Fall hat der Server in dem Ausführungsbeispiel von 2 in dem Zugriffsprotokoll 14 genügend Informationen aufgezeichnet, um anzuzeigen, dass der Client die Seite X angefordert hat und zumindest während (X₀ + X₁ + X₂ + X₃) auf der Seite verweilte. Da die Dauer der Pulssignale (X₁, X₂ und X₃) in der Ausführungsform von 2 ferner einheitlich lang ist (was, wie bei späteren Ausführungsformen erläutert wird, kein Erfordernis der Erfindung ist), enthält das Serverprotokoll genügend Informationen, um zu erkennen, dass der Client für einen Zeitraum von mehr als (X₀ + 3X₁), aber weniger als (X₀ + 4X₁) auf der Seite X verblieben ist.
Die 3 und 4 zeigen weitere Ausführungsbeispiele der vorliegenden Erfindung, die für die Akkumulation von verschiedenen Arten von Daten nutzbringend sein können. Die 3 und 4 sind stenografische Darstellungen von der in 2 gezeigten Art, wobei der Server und die Serverrückmeldungen zugunsten der Übersichtlichkeit weggelassen wurden. Die Unterschiede zwischen den Ausführungsformen nach den 2, 3 und 4 bestehen in der Organisation und der Dauer der Pulssignale, die von der Seite an den Server geliefert werden. In der 2 sind die Pulssignale (X₁, X₂, X₃) in gleichmäßigen Zeitabschnitten angeordnet. In der 3 erfolgt das erste Pulssignal nach einer Zeitdauer X₄ und danach erfolgt für etwa für die vierfache Dauer von X₄ kein zweites Pulssignal. Danach erfolgen die Pulssignale Nr. 3 und 4 etc. nach derselben Zeitdauer wie das erste Pulssignal. Das heißt, in 3 ist 4X₄ = X₅ = 4X₆ usw. Die Ausführungsform nach 3 kann für das Erstellen von Statistiken von Bedeutung sein, worin ein Werbender wissen möchte, ob der Anwender lange genug auf einer Seite verweilte, um die Werbung aufzunehmen (X₄), sich darüber hinaus aber nicht wirklich dafür interessiert, wie lange der Anwender darauf verbleibt, es sei denn, es ist extrem lange (T = X₅), sodass der Werbende zu diesem Zeitpunkt wissen möchte, wie lange genau der Benutzer auf der Seite verbleibt, das durch die erhöhte Wiederholrate der Pulssignale (T = X₆) angezeigt würde.
Eine weitere beispielhafte Ausführungsform der vorliegenden Erfindung ist in der 4 gezeigt, worin sich die Wiederholrate der Pulssignale mit der Zeit erhöht. Das Beispiel von 4 kann beispielsweise für den Fall relevant sein, wenn zwei Anwender auf dieselbe Datenbank zugreifen und der Server bei einem ersten Anwender abfragen möchte, wann der Anwender mit der Datenbank fertig ist, um dann einem zweiten Anwender den Zugriff zu gestatten. In diesem Falle würde der Ser ver erwartungsgemäß dem Anwender eine gewisse (längere) Zeit (T = X₇) gewähren, bevor er das ersten Pulssignal anfordert. Danach würde der Server die Pulssignale häufiger anfordern, um zu bestimmen, wann der Anwender das System verlassen hat. Die Ausführungsform nach 4 ist daher dann angebracht, wenn von einem Anwender bekanntermaßen erwartet wird, dass er eine angemessene Zeit mit einer Seite verbringt bevor er sie verlässt. Wenn zum Beispiel bei der im oberen Abschnitt zum Stand der Technik beschriebenen Ausführungsform zwei Anwender gleichzeitig auf dieselbe Lagerbestandsdatenbank für das Produkt X auf dem Warenhaus-Server zugreifen und das Warenhaus weiß, dass Anwender ungefähr drei oder vier Minuten in der Datenbank mit Zugriffen auf die Bestandsaufzeichnungen und mit Käufen verbringen, kann der Warenhaus-Server das X₇-Pulssignal auf etwa drei Minuten, das X₈-Pulssignal auf eineinhalb Minuten, das X₉- Pulssignal auf 40 Sekunden usw. setzen, um genau einzugrenzen, wann der Anwender innerhalb des ungefähren Drei- bis Vier-Minuten-Bereichs die Datenbank tatsächlich verlässt.
5 zeigt eine beispielhafte Ausführungsform des Aufbaus von Server 12. Die Seitenanforderungssignale und Pulssignale sind wiederum auf der linken Seite der 5 in von oben nach unten erfolgender, chronologischer Reihenfolge dargestellt. Wenn eine Seitenanfrage von einem Client empfangen wird, nimmt der Server 12 die Seitenanfrage im Prozessor 20 entgegen, der dann auf die Datenbank 16 zugreift, um die Seite aufzufinden oder zu kompilieren. Danach sendet der Prozessor 20 die Seite in einer "Seitenrücksendungs"-Übertragung an den Client. Wie zuvor beschrieben, enthält die Seite die Skriptsprachfunktion, die in vorbestimmten Zeitintervallen die Pulssignale erzeugt. Wie in 5 gezeigt ist, wird das erste Pulssignal "Pulssignal Nr. 1" nach dem ersten Zeitintervall zurückgesendet. Prozessor 20 erhält das Pulssignal und verzeichnet das Pulssignal im Protokoll 14. Als nächstes greift der Prozessor 20 auf die CGI-Routine 21 zu (auf die im Pulssignal Nr. 1 wie im Weiteren beschrieben Bezug genommen wird), die den Prozessor 20 unterweist, das "In Ordnung"-Signal zurück an den Server zu senden.
Ein Benutzer des Servers 12 kann auf den Prozessor 20 später mittels eines dezentralen Computers 22 zugreifen, um die Seitenanforderungen und nachfolgenden Pulssignalinformationen mittels eines Zugriffs auf das Protokoll 14 abzuholen. Aus diesen kann der Computer 22 die Verweilinformation für statistische Zwecke zusammenstellen.
Wenn der Benutzer des Servers auf das Protokoll 14 mittels des Computers 22 zugreift, wird er gemäß eines Ausführungsbeispiels der Erfindung ein Zugriffsprotokoll ähnlich dem in der 6 gezeigten vorfinden. Das Beispiel von 6 weist insofern Ähnlichkeiten mit der in der 2 gezeigten Übertragungsfolge auf, als die Frequenz der Pulssignale (X₁, X₂, X₃ etc.) einheitlich ist. Wie weiter unten noch näher beschrieben wird, zeigt die in Protokoll 14 der 6 ausgewiesene Information dem Benutzer des Servers, dass ein bestimmter Client auf eine bestimmte Seite zugegriffen hat und diese dann mehr als neun, aber weniger als zehn Minuten gesichtet hat.
Dies kann durch Einsehen einer jeden der im Zugriffsprotokoll 14 von 6 dargestellten Zeilen festgestellt werden. In der ersten Zeile hat der Prozessor 20 eine Seitenanfrage von einem als "pc59" identifizierten Client nach einer Seite mit dem Namen "Index.html" in das Zugriffsprotokoll aufgezeichnet. Die Seitenanfrage erfolgte am 9. Oktober 1996 um 16:51:56 Uhr. Die erste Zeile in dem Zugriffsprotokoll 14 von 6 stellt, wie über die Anweisung "GET" festzustellen ist, eine Seitenanforderung dar.
Die auf die Zeile mit der "GET"-Anfrage folgenden nächsten fünf Zeilen in 6 stellen jeweils von der Seite an den Server zurückgesandte Pulssignale dar. Wie aus diesen Zeilen ersichtlich ist, wurde das Pulssignal von demselben PC "pc59" am selben Tag (9. Oktober 1996) zu rückgesandt. Die Pulssignale beginnen fünf Minuten nach der Seitenabfrage (X₀ entspricht nach 2 fünf Minuten) und danach wird jede Minute ein Pulssignal (unter Bezug auf 2 ist X₁ = X₂ = X₃ = 1 Minute) erzeugt. Das Skript für diese Seite (Index.html) wurde also angewiesen, fünf Minuten bis zum Senden des ersten Pulssignals zu warten. Danach soll das Skript jede Minute ein Pulssignal zurück an den Server senden. Die in der 6 dargestellte Information lässt darauf schließen, dass der Benutzer des pc59 die index.html-Seite um 16:51:56 Uhr erhalten hat und auf dieser zumindest bis 17:00:56 Uhr, jedoch nicht bis 17:01:56 Uhr verblieb. Dies ergibt sich daraus, dass die planmäßig jede Minute nach dem ersten zu sendenden Pulssignale um 17:00:56 Uhr enden.
Selbstverständlich ist das Beispiel eines Zugriffsprotokolls in der 6 lediglich exemplarisch für einen Typus einer anwendbaren Pulssignalsequenz. Falls mit einem feineren Zeitraster als dem in der 6 gezeigten in Erfahrung gebracht werden soll, ob der Benutzer eines Clients auf einer Seite verblieben ist, kann das Skript leicht so modifiziert werden, dass es beispielsweise alle zehn Sekunden anstatt jede Minute Pulssignale produziert. Ebenso kann auch das anfängliche Pulssignal (das in dem Beispiel der 6 fünf Minuten nach der Seitenanforderung erfolgt) geändert werden (beispielsweise auf 1 Minute). Die vorliegende Erfindung ist keineswegs auf die Einteilung der Pulsabstände oder Pulszeiten beschränkt.
Es können auch andere Arten von Pulssignalskripten erzeugt werden und diese sind auch für die vorliegende Erfindung vorgesehen. Zum Beispiel kann das Skript ein auf einer Uhrzeit (zum Beispiel zu jeder vollen Stunde) basierendes Pulssignal liefern, oder eines, das auf besonders gearteten Algorithmen (zum Beispiel X_n = 2X_n + 1, wie in 4 dargestellt) beruht. Eine noch andere, ausgefallene Art eines Skripts könnte ein einziges Pulssignal zu einer bestimmten Zeit (zum Beispiel 2.00 Uhr nachmittags) senden, um festzustellen, ob ein Benutzer, der die Seite um 2.00 Uhr nachmittags einsehen soll, sich tatsächlich zur vorgesehenen Zeit auf dieser aufhält. Man kann sich viele andere Arten von Pulssignalskripten vorstellen, und die vorliegende Erfindung ist auf keinen speziellen Typus einer Pulssignalsequenz beschränkt.
Die 7 illustriert einen beispielhaften Typus eines Skripts, das gemäß der vorliegenden Erfindung verwendet werden kann. Selbstverständlich ist die vorliegende Erfindung nicht auf das bestimmte, in der 7 beschriebene Skript beschränkt, sondern erstreckt sich auf alle anderen Arten von Skripten, die sich im Rahmen der in dieser Beschreibung und den Ansprüchen beschriebenen Zwecke und Funktionen vorsehen lassen. Im Beispiel der 7 ist der Server 12 von zum Beispiel 5 genauer dargestellt. Ein Unterschied zwischen der Ausführungsform von 5 und der Ausführungsform von 7 besteht in dem anders gearteten Datenspeicher. In der 5 entnimmt der Server 12 der Datenbank 16 Daten, um eine Seite zu kompilieren. In der 7 dagegen greift der Prozessor 20 des Servers 12 auf Seiten eines Dateiservers und Dateiverzeichnisses 17 zu. Diese und andere Ausführungsformen sind im Rahmen der Erfindung vorgesehen, sofern der Server 12 Seiten für eine Übertragung an die Clients auffinden und aufbereiten kann.
In dem Beispiel der 7 hat ein (nicht dargestellter) Client eine Seite namens "index.html" vom Server 12 abgerufen. Die index.html-Seite enthält zusätzlich zu den Seitendaten, die dem Benutzer des Clients die Seiteninformation zur Verfügung stellen, die in den Zeilen 1-10 dargestellte Skriptfunktion der index.html-Seite. Wie in der 7 gezeigt ist, ist die Beispiel-Skriptfunktion auf der index.HTML-Seite die folgende:
Die Skriptfunktion sorgt für das Senden der Pulssignale vom Client an den Server 12 in Übereinstimmung mit den zuvor beschriebenen Ausführungsbeispielen der 2 bis 6. Die einzelnen Zeilen des Skripts entsprechen den folgenden Funktionen:
Zeile 1 gibt an, dass das Skript im wohl bekannten JavaSkript-Format gehalten ist. Selbstverständlich sind auch andere Skriptsprachen, von denen ein alternatives Beispiel weiter unten beschrieben wird, bekannt und können verwendet werden.
Zeile 2 definiert eine Funktion mit dem Titel "Pulssignal".
Zeile 3 verlangt, dass die definierte Pulssignalfunktion alle 60.000 Millisekunden (60 Sekunden) aufgerufen wird.
Zeile 4 ist eine Anweisung zum Übersenden des Formulars mit dem Titel "beatform" (Pulssignalformular) an den Server 12.
Zeile 5 beendet die Definition der Funktion.
Zeile 6 beendet den JavaSkript-Abschnitt.
Zeile 7 führt die Funktion mit dem Titel "Pulssignal" alle 300.000 Millisekunden (5 Minuten) nach Abruf der index.HTML-Seite aus. Dies legt das erste Pulssignal (K₀ in 2) fest.
Zeile 8 definiert ein an den Server zu sendendes Formular. Nach Übersenden des Formulars wird auf dem Server 12 ein Programm mit dem Titel "nph-beat" ausgeführt.
Zeile 9 gibt an, dass das Formular zumindest ein Feld aufweisen soll.
Zeile 10 gibt das Ende der Formulardefinition an.
Sobald die index.html-Seite beim Client eingegangen ist, wird die Seite nach einer Wartezeit von fünf Minuten die Pulssignalfunktion ausführen, die alle 60 Sekunden das "Pulssignalformular" an den Server sendet. Nach Erhalt des Pulssignalformulars durch den Server 12 wird dieser die Handlungsanweisung im Formular (Zeile 8 des index.html-Skripts) lesen, die ihm anzeigt, das "nph-beat"-Skript auszuführen. Der Prozessor 20 ruft die CGI-Routine 21 auf (die eine eigenständige Softwarekomponente sein kann oder im Prozessor 20 eingegliedert ist), die das CGI-Skript des Servers, wie in der 7 dargestellt, ausführt. Das Skript ist im UNIX-Format dargestellt, kann aber, wie später beschrieben wird, auch in alternativen Formaten gehalten sein. Das CGI-Skript des Servers ist, wie in der 7 zu sehen, sehr einfach. Zeile 1 des CGI-Serverskripts zeigt an, dass das Skript in UNIX-Shell-Programmierung gehalten ist. Zeile 2 sendet einen HTTP-Header an den Browser des Clients, der die index.html-Seite abgerufen hatte. Dieser Header bestimmt "no content" (kein Inhalt), was bedeutet, dass der Browser keine Handlung vornehmen muss. Zeile 3 des CGI-Skripts sendet nach dem Header schließlich eine leere Zeile.
Gemäß dem in der 7 gezeigten Skriptbeispiel ruft ein Client die index.html-Seite ab, die Seite trifft mit dem dargestellten Skript ein und fünf Minuten nach Erhalt der Seite führt die Seite die "Pulssignal"-Funktion aus. Beim Ausführen der "Pulssignal"-Funktion sendet die Seite jede Minute das "beatform"-Dokument an den Server 12. Dieses Dokument fordert den Server auf, nach einer CGI-Routine mit dem Titel "nph-beat" zu suchen. Nach dem Auffinden dieser Routine veranlasst die Routine den Server 12, an den Client einen, von einer leeren Zeile gefolgten HTTP-Header zurückzusenden. Diese leere Zeile entspricht im Wesentlichen der in der 2 gezeigten "In Ordnung"-Feststellung, während das von der index.html-Seite gesendete Formular "beatform" im Wesentlichen der in der 2 gezeigten Aussage "Ich bin immer noch hier" entspricht.
Das in der Programmiersprache C verfasste Pendant zu dem in der 7 gezeigten CGI-Skript ist nachstehend dargestellt:

Zeile 1 im obigen Code ist von der C-Programmiersprache vorgeschrieben,
Zeile 2 definiert das Hauptprogramm,
Zeile 3 sendet einen HTTP-Header an den Browser, der festlegt, dass von dem Browser keine Handlung vorgenommen werden muss, und
Zeile 4 beendet die Programmdefinition.

Besonders zu erwähnen ist, dass gegenwärtig auf vielen World Wide Web-Servern der Name des CGI-Skriptnamens mit einem "nph" beginnen muss, damit dieses den Content-Header zurücksenden kann.
Die obigen Beispiel-Skripte eignen sich für das Ausführungsbeispiel von 7, worin der Server 12 eine Seite von z.B. einem Dateiverzeichnis 17 abruft. Für den Fall, dass der Server 12 Information von einer Datenbank abruft, die, wie in 5 gezeigt, von einem Client verändert werden kann, erhält man etwas komplexere Skripte. Wie im obigen Abschnitt zum Stand der Technik beschrieben wurde, geht das bezüglich der Datenbankanwendung gelöste Problem über das einfache Erhalten statistischer Information hinaus, denn es umfasst auch, dass zwei Clients nicht zur selben Zeit auf denselben Datenbankeintrag zugreifen können. Das Pulssignal ist in der bevorzugten Ausführungsform der Datenbankanwendung gleichförmig (d. h. gleichmäßig periodisch). Außerdem sollte das mit dem Seitenformular zurückgesandte Feld der Datenbank auch eine Art Selbsterkennung aufweisen (d. h., jede zurück gesandte Seite sollte ein eindeutiges Identifikationsfeld aufweisen), so dass dem Server 12 bekannt ist, wo sich der Clientanwender befindet.
Für die Datenbankanwendung muss das Serverskript in der CGI-Routine 21 auf die genaue Datenbankanwendung ausgelegt sein. Insbesondere muss das Skript 1) wissen, wo sich die Datenbank befindet, und 2), wie die Felder in der speziellen Datenbank zu handhaben sind. Ferner muss die vom Server bei einer Datenbankanwendung zurückgesendete Webseite vom Server dynamisch erzeugt werden, was bedeutet, dass die Felder von der Datenbank abgerufen und die Seiten dann anschließend auf der Grundlage der erhaltenen Datenbankinformation erzeugt werden. Die Webseite umfasst idealerweise die Pulssignalskriptfunktion zusammen mit einem von der Pulssignalfunktion zurückzusendenden Formular (oder Dokument), das ein geeignetes Identifikationsfeld enthält.
In der bevorzugten Ausführungsform sollte das Server-CGI-Skript, das die Seite erzeugt und verarbeitet, die folgenden Funktionen ausführen:

1. Ablehnen des Zustellens einer Seite an einen anderen Benutzer, falls die Seite durch einen Benutzer in Gebrauch ist,
2. Kennzeichnen des Pulssignalformulars mit einem geeigneten Identifikationsfeld,
3. Ausfüllen des Datenformulars mit der Information aus der Datenbank, falls erforderlich, und
4. Verweigern der Annahme eines zurückgesandten Formulars, falls ein Pulssignal "ausgesetzt" wurde und ein Anderer die Seite in der Zwischenzeit eingesehen hat.

Ein Beispiel, wie ein Benutzer eines Clients Nr. 4 auf eine Datenbankinformation auf einem Server 12 zugreift, ist in der 8 dargestellt. Als erstes macht der Benutzer des Clients eine Seitenanfrage "Gib mir Seite X". Diese Anfrage wird von dem Prozessor 20 empfangen, der auf die Datenbank 16 zugreift. In dem in der 8 gezeigten Beispiel kann die Seite X einen Datensatz für einen Lagerbestand darstellen, der einen Lagerbestand "M" für ein bestimmtes Produkt verlangt. In diesem Fall fordert der Prozessor 20 die Datenbank 16 in der Anweisung "Gib mir den Datensatz 'M', damit ich die Seite X erstellen kann" auf, den Datensatz M aufzurufen.
In der Datenbank 16 enthält jeder Datensatz eine Datums- und Zeitidentifikations- (DTI) Registrierung, die als Protokoll für den bestimmten Datensatz fungiert. Die DTI-Information ist in der Datenbank als weiteres Feld aufgezeichnet. Wenn der Benutzer des Clients Nr. 4 daher die Seite X, die den Datensatz "M" erfordert, abruft, wird die Anfrage nach dem Datensatz M durch den Benutzer Nr. 4 in dem DTI-Feld für den Datensatz M in der Datenbank 16 aufgezeichnet. Auch wenn aus Gründen der Übersichtlichkeit in 8 eine Kurzform verwendet wird, kann das DTI-Feld ähnlich den in dem Zugriffsprotokoll 14 der 6 gezeigten Einträgen gehalten sein. In dem Beispiel von 8 treten das anfängliche Pulssignal und jedes nachfolgende Pulssignal in 1-Minuten-Intervallen auf und der ursprüngliche Seitenabruf erfolgt um 15:36 Uhr. Demzufolge weist der Datensatz M ein zugehöriges DTI-Feld mit einem Eintrag des ersten Zugriffs von "Benutzer Nr. 4 um 15:36 Uhr" auf, der anzeigt, dass der Benutzer des Clients Nr. 4 eine Seite abgerufen hat, die den Datensatz M um 15:36 Uhr erforderte.
Nachdem der Prozessor 20 den Datensatz M zum Erstellen der Seite X angefordert hat, sendet die Datenbank 16 den Datensatz M an den Prozessor 20, der die Seite X (ein Formular) aufbaut, die ein CGI-Skript (im Folgenden näher erläutert) und die Datensatzinformation "M" enthält. Anschließend veranlasst die Seitenskriptfunktion den Anwenderclient Nr. 4 jede Minute, die er auf der Seite verbleibt, ein Pulssignal an den Server 12 zu senden. Diese Pulssignale sind in der 8 als Angaben "Immer noch auf Seite X" von oben nach unten in chronologischer Reihenfolge dargestellt. Die Pulssignale vom Anwenderclient Nr. 4 kenn zeichnen die Seiteninformation für den Server 12, wie weiter unten im Einzelnen erläutert wird. Der Prozessor 20 empfängt die Pulssignale vom Anwenderclient Nr. 4, der den Prozessor 20 veranlasst, die CGI-Routine 21 aufzurufen. Diese Routine 21 besteht in einer weiteren Skriptfunktion, die den Server 12 veranlasst, eine leere Zeile mit der Bedeutung "In Ordnung" zurückzusenden. Ferner wird jedes Mal, wenn der Prozessor 20 und die CGI-Routine 21 das Pulssignal empfangen, die Datenbank in dem DTI-Feld für den Datensatz M durch Protokollieren der Pulssignaleinträge abgeändert. Daher ist der Datensatz M in der Datenbank 16 zum Beispiel mit einem (teilweisen) DTI-Feld dargestellt, das anzeigt, dass Benutzer Nr. 4 auf der Seite X von 15:36 Uhr (und jede Minute danach) bis mindestens 15:39 Uhr (und möglicherweise länger, je nachdem, wie lange der Anwenderclient Nr. 4 fortfährt durch Verbleiben auf der Seite, Pulssignale an den Server 12 zu senden) verblieben war.
Schließlich kann der Anwenderclient Nr. 4 eine Anfrage an den Server 12 senden, worin er den Server 12 auffordert, den Datensatz "M" abzuändern. Das kann zum Beispiel erfolgen, wenn der Anwenderclient Nr. 4 eine Anfrage zum Kauf einer gewissen Anzahl aus dem Produktverzeichnis "M" für ein bestimmtes Produkt macht. Der Anwenderclient Nr. 4 führt dies aus, indem er ein Formular zurücksendet, das die Abänderung des Datensatzes M angibt. Dieses Formular wird vom Prozessor 20 empfangen, der die Datenbank 16 benachrichtigt, dass der Datensatz M abgeändert werden muss. Die Datenbank 16 ändert den Datensatz M entsprechend ab. Sodann verlässt der Anwenderclient Nr. 4 die Seite X, wodurch die Pulssignale aufhören. Das zeigt dem Server 12, dass der Datensatz M nun für einen anderen Anwenderclient verfügbar ist. Dies ist genauer in der 9 dargestellt, worin Client Nr. 1 die Seite 4 abruft, die Seite 4 empfängt und dann ein (oder mehrere) Pulssignale an den Server 12 sendet, um anzuzeigen, wie lange er auf der Seite 4 verbleibt. Zu einem gewissen Zeitpunkt wird der Client Nr. 1 die Seite 4 verlassen und die zwischen dem Client Nr. 1 und dem Server 12 herr schende Stille zeigt dem Server 12 an, dass der Client Nr. 1 die Seite verlassen hat. Dann kann der Client Nr. 2 bei der Anfrage "c" die Seite Nr. 4 anfordern. Die in der 9 als Übertragung "D" dargestellte Rückmeldung des Servers 12 hängt von der Skriptfunktion und der Zeit T_c zwischen dem letzten, von Client Nr. 1 empfangenen Pulssignal und der Anfrage nach der Seite 4 durch Client Nr. 2 ab. Beispiele verschiedener Möglichkeiten für eine Rückmeldung "D" des Servers 12 an den Client Nr. 2 sind weiter unten genauer beschrieben.
Als erstes ist nachfolgend ein Beispiel eines Seitenskripts für eine Webseite dargestellt, die Daten aus einer Tabelle "T" zur Anzeige bringt. Die Seite wird von einem Server-CGI-Skript erzeugt, das den angeforderten Datensatz Nummer "M" erhält, aus der Tabelle "T" liest und es dem Anwender ermöglicht, den Datensatz abzuändern. Der Datensatz wird neu in die Datenbank geschrieben, wenn der Anwender den Datensatz an das Skript übergibt und der nächste Datensatz (M + 1) wird an dessen Stelle abgerufen. Dieses Beispiel stellt nur eine Umsetzung der vorliegenden Erfindung dar und ist nicht darauf beschränkt:
Dieses Beispielskript ist, wie Zeile 4 angibt, im JavaSkript-Format geschrieben, kann aber auch in anderen möglichen Formaten ausgeführt sein. Nachstehend Erläuterungen zu einigen relevanten Skriptzeilen:
Zeile 3 erzwingt das Neuladen der Seite von dem Server. Hierüber wird ein Problem behandelt, das sich möglicherweise ergibt, wenn jemand an einer Seite arbeitet, dann zu einer anderen Seite springt und schließlich zur ersten Seite zurückkehrt. Wenn die erste Seite erst kürzlich genutzt wurde, kann der Browser versuchen, die Seite aus einem Cache-Speicher zu ziehen, worin kürzlich verwendete Seiten auf Grund der Annahme aufbewahrt werden, dass Anwender häufig auf dieselben Seiten zurückkehren. Wenn die Seite aus dem Cache-Speicher genommen wird, beginnt die Pulssignalfunktion auch dann erneut, wenn ein anderer die Seite in der Zwischenzeit abgerufen haben sollte. Das CGI-Skript namens "DBUPDATE" wird dies unterbinden, indem es ablehnt, die Seite zu speichern. Dafür wird die Mitteilung an den Anwender zurückgesandt, um anzuzeigen, dass der Anwender nicht mehr in deren Besitz ist. Als zusätzliche Vorsichtsmaßnahme erhält jede erzeugte Seite eine Verfallsdauer, sodass sie verfällt, bevor sie heruntergeladen werden kann. Verfallene Seiten werden nicht im Cache-Speicher zwischengespeichert. Für die Behandlung des Problems können andere alternative Techniken eingesetzt werden, die verhindern, dass die Seiten in dem Cache-Speicher zwischengespeichert werden.
Zeile 5 stellt die Pulssignalfunktion dar, die alle 60 Sekunden das Formular "beatform" ("Pulssignalformular") übersendet.
Zeile 10 ist der Titel der zurückgesandten Tabelleninformation, wie zum Beispiel "Information für Mike Jones von der Lohn- und Gehaltsliste", oder jede andere nützliche Information.
Zeile 12 startet das Pulssignal, wenn die Seite geladen ist.
Zeile 13 führt bei jedem Pulssignal das CGI-Skript "nph-dbbeat" aus. Ein Feld namens "whoAmI" (wer bin ich) wird dann mit dem Wert, der den Datensatz und die Tabelle spezifiziert, übergeben.
Zeile 16 enthält Text, der beschreibt, was der Benutzer sieht, oder vielleicht ein Unternehmenskennzeichen.
Zeile 17 ist ein anderes Formular, dass alle für den Datensatz relevanten Daten enthält. Wenn es sich bei dem Datensatz um einen Auszug aus einer Lohn- und Gehaltsliste handelt, kann er Informationen wie Name, Angestelltenkennung, Gehalt, Steuerinformation usw. enthalten. Sobald es vollständig ist, wird das Formular an "DBUPDATE" übermittelt, das die Informationen speichert und eine neue Seite mit den Daten für den Datensatz M + 1 zurücksendet. Mit JavaSkript können eine Reihe von "Übertragen"-Schaltflächen erstellt werden, die zum Beispiel den ersten Datensatz, den letzten Datensatz, den vorangehenden Datensatz, den nachfolgenden Datensatz oder einen bestimmten Datensatz zurücksenden. Das vorliegende Beispiel sendet den "nächsten Datensatz" zurück.
Zeile 18 stellt das im Formular enthaltene "whoAmI"-Feld dar.
Zeile 21 enthält abschließenden Text etwa für die Anbindung von Firmenzeichen, Hilfeseiten etc.
Zeile 22 schließt den Seitenaufbau ab.
Zeile 23 beendet die Seite.
Gemäß diesem Beispiel werden zwei CGI-Skripte benötigt, um mit der Datei zu arbeiten: Ein CGI-Skript, um das Pulssignal zu handhaben und eine weiteres zum Aktualisieren und Zustellen der Webseite aus der Datenbank. Das Pulssignalskript muss, wie in der 8 gezeigt ist, einen Datum/Zeit/Identifikations- (DTI = Date/Time/Identification) Stempel an der angegebenen Stelle einfügen. Der DTI-Stempel kann vorangegangene DTI-Stempel überschreiben oder sie protokollieren. Die Kriterien für das Zulassen einer Überschreibebedingung könnten, falls ein Überschreiben des DTI-Stempels zugelassen ist, beinhalten:

1. Der Computer, der den DTI-Stempel übermittelte, ist derselbe wie der, der ihn zuvor angegeben hat, oder
2. das aktuelle Datum und die aktuelle Zeit sind außerhalb der Zeitablauffrist ("Timeout" Period) des vorangegangenen DTI-Stempels.

Nachstehend ist ein CGI-Skript-Beispiel für eine Pulssignalfunktion in Pseudocode angegeben, wobei, soweit es die Lesbarkeit erhöht, auf Standardfunktionen der C-Programmiersprache Bezug genommen wird:

1. Identifizieren des die Anfrage sendenden Computers mittels getenv("REMOTE_ADDR"). Speichern dessen als "ipAddress".
2. Laden des Werts des "whoAmI"-Parameters. Dies kann unter Verwendung von standardmäßigen CGI-Dienstprogrammen erreicht werden. Speichern als "whoAmI" .
3. Öffnen einer Datei, deren Name dem Wert von "whoAmI" entspricht, zum Lesen.
4. Falls die Datei existiert:
5. Lesen der Inhalte. Sichern der ip-Adresse als "lastIP" und Sichern von Datum und Zeit als "lastDT".
6. Falls das lastIP dem whoAmI entspricht, oder, falls (zur jetzigen Zeit) das lastDT höher als die Zeitablauffrist ist, dann:
7. Neuöffnen der Datei zum Schreiben.
8. Einfügen von whoAmI und des aktuellen Datums und der aktuellen Zeit.
9. Ansonsten versucht diese Person, das Pulssignal eines anderen zu stehlen. Ignorieren.
10. Wenn die Datei nicht existiert:
11. Öffnen der Datei zum Schreiben.
12. Einfügen von whoAmI, des aktuellen Datums und der aktuellen Zeit.
13. Schließen der Datei.
14. Schreiben von "HTTP/1.0 204 No Content\n\n" an stdout, um dem Client mitzuteilen, dass das Skript ausgeführt wurde.
15. Beenden des Skripts.

Das zweite, für obiges Beispiel benötigte Skript ist dasjenige, das die Webseite von der Datenbank aktualisiert und zustellt. In dem Beispiel wird es als "DBUPDATE"-Skript bezeichnet, für das nachfolgend ein Beispiel in Pseudocode angegeben ist, worin auf Standardfunktionen der C-Programmiersprache Bezug genommen wird, soweit es die Lesbarkeit erhöht:

1. Identifizieren des die Anfrage sendenden Computers über getenv("REMOTE_ADDR"). Speichern dessen als "ipAddress".
2. Laden des Werts des "whoAmI"-Parameters. Dies kann unter Verwendung von standardmäßigen CGI-Dienstprogrammen erreicht werden. Speichern dessen als "whoAmI".
3. Öffnen einer Datei, deren Name dem Wert von "whoAmI" entspricht, um sie zu lesen.
4. Falls die Datei existiert:
5. Lesen der Inhalte. Sichern der ip-Adresse als "lastIP" und Sichern von Datum und Zeit als "lastDT".
6. Falls das lastIP dem whoAmI entspricht, oder, falls (zur jetzigen Zeit) das lastDT höher als die Zeitablauffrist ist, dann:
7. Neuöffnen der Datei zum Schreiben.
8. Einfügen von whoAmI und des aktuellen Datums und der aktuellen Zeit.
9. Ansonsten versucht diese Person, das Pulssignal eines anderen zu stehlen. Ignorieren.
10. Wenn die Datei nicht existiert:
11. Aktualisieren des vorliegenden Datenbanksatzes.
12. Aufbauen einer neuen Seite mit dem Kopf "Datensatz <m> wurde erfolgreich aktualisiert" und den Daten für den nächsten (falls vorhanden) Datensatz.
13. Schließen der Datei.
14. Beenden des Skripts.

Anhand der übrigen Beispiel-Skripte werden in der Ausführungsform nach 9, worin jeder der Clients dieselbe Information vom Server 12 erhalten möchte, Beispiele für Rückantworten des Servers 12 an die Clients 1 und 2 beschrieben. In diesem Beispiel wird angenommen, dass Client Nr. 1 Informationen aus der Lohn- und Gehaltsliste angefordert hat, so dass "payroll/mike smith" in der whoAmI-Datei enthalten ist. Die "remote addr"-Variable (die die IP-Adresse des anfragenden Computers enthält) enthält gegenwärtig die IP-Adresse für Client Nr. 1. Wenn Client Nr. 1 die Seite anfragt, gibt es fünf möglich Bedingungen für eine Rückantwort.
Möglichkeit Nr. 1. Der Server 12 stellt fest, dass die Datei "payroll/mike smith" existiert und die IP-Adresse des Clients Nr. 1 enthält und die Zeitangabe im DTI-Stempel in etwa eine Minute alt ist. Dies ist der Normalfall, der dem Server 12 anzeigt, dass Client Nr. 1 die Datei ""payroll/mike smith" weiterhin verwendet und dass die Pulssignalfunktion die Verfügungsgewalt von Client Nr. 1 über die Seite erneut geltend macht.
Möglichkeit Nr. 2. Falls der Server 12, nachdem er vom Client Nr. 1 die Anfrage für die Seite erhalten hat, feststellt, dass die Datei "pay roll/mike smith" existiert und die IP-Adresse für Client Nr. 1 enthält, aber der DTI-Stempel für diese Datei circa eine Stunde alt ist, erkennt Server 12 dies als ungewöhnlichen Zustand. In diesem Fall hat der Client Nr. 1 die Seite eingesehen, dann verlassen (daher das Fehlen einer näher liegenden Zeit des DTI-Stempels) und ist nun auf diese Seite zurückgekehrt. Die Seite wurde aus dem Cache-Speicher (was normalerweise nicht passieren sollte, da jede Seite verfallen sollte, bevor diese Bedingung eintreten kann) geladen. Durch Laden der Datei aus dem Cache-Speicher kann Client Nr. 1, der früher Eigner der Seite war, seine Kontrolle über die Seite wieder geltend machen.
Möglichkeit Nr. 3. Falls der Server feststellt, dass die Datei "payroll/mike smith" nicht existiert, ist eine Fehlerbedingung eingetreten. Es kann nicht sein, dass die Datei nicht existiert, denn das CGI, das die Seite zugestellt hat, hat auch die Datei erstellt. Wenn eine Annahme getroffen wird, kann das Skript jedoch mit diesem Fehler einfach umgehen. Falls die Datei irgendwie gelöscht wurde, wird sie neu erzeugt und Client Nr. 1 wird der Eigner der Seite. Falls ein anderer Client die Seite besaß, würde sie neu vergeben werden, so dass der andere Eigner die Verfügungsgewalt über die Seite verliert. Es gilt zu bedenken, dass dies ein ungewöhnlicher Fall ist, der wohl kaum vorkommen wird und erfordert, dass die Datei sowohl irgendwie verloren geht als auch in der Zeit zwischen zwei Pulssignalen durch einen anderen Eigner entführt wird. Dennoch kann diese Fehlerbedingung mit der obigen Neuerzeugung und Neuzuordnung behoben werden.
Möglichkeit Nr. 4. Falls Server 12 in Reaktion auf eine Seitenanfrage des Clients Nr. 1 feststellt, dass die Datei "payroll/mike smith" existiert und die IP-Adresse für Client Nr. 2 enthält und die Zeit des DTI-Stempels in etwa eine Minute alt ist, unterrichtet Server 12 den Client Nr. 1, dass er nicht mehr länger Eigner der Seite ist und abwarten muss, bis Client Nr. 2 fertig ist, bevor er wieder Zugriff auf die Seite haben kann. Diese Möglichkeit tritt auf, wenn Client Nr. 1 auf die Seite zugreift, mit der Seite abschließt und dann versucht, während Client Nr. 2 die Seite in der Zwischenzeit übernommen hat, die Seite aus dem Cache-Speicher erneut zu laden. Da das Pulssignal von Client Nr. 1 aufgehört hat, wurde Client Nr. 2 der Zugriff auf die Seite gewährt und nun kann Client Nr. 1 sie nicht mehr aus dem Cache-Speicher laden bevor Client Nr. 2 fertig ist.
Möglichkeit Nr. 5. Die letzte Möglichkeit ergibt sich, wenn Server 12 feststellt, dass die Datei "payroll/mike smith" existiert, die IP-Adresse für Client Nr. 2 enthält und die Zeit ca. eine Stunde zurückliegt. Auch dieser Fall ist ungewöhnlich, da die Seite aus dem Cache-Speicher stammt und vor dem einstündigen Zeitintervall hätte verfallen sollen. Es ist sehr wahrscheinlich, dass Client Nr. 2 die Seite aufgegeben hat, so dass Client Nr. 1 nun seine Rechte daran wieder geltend machen kann. Ein Problem muss jedoch angesprochen worden. Client Nr. 1 könnte noch alte Daten auf seiner Seite haben und die neueren Daten von Client Nr. 2 überschreiben. Dies ist der Hauptgrund dafür, dass keine Seiten in dem Cache-Speicher abgelegt werden sollten. In einer pessimistisch angelegten Ausführung eines Sperrmechanismus sollte Server 12 Anwender Nr. 1 warnen, dass er alte Daten verwenden könnte und dass der Arbeitsvorgang mit neuen Daten wieder aufgenommen werden sollte.
Auf diese Weise können die Daten in der Datenbank gesperrt werden, wenn ein Client die Daten über das Web benutzt. Das CGI DBUPDATE-Skript auf dem Server 12 wird angewandt, um nur dann Daten in die Datenbank zu schreiben, wenn sie von einem Client stammen, der die Seite gesperrt hat. Das CGI-Skript wird dann den nächsten Datensatz an denselben Client schicken. Das Skript handhabt auch Fälle, in denen der Client, der eine Seite übersendet, nicht derselbe Client ist, der sie gesperrt hat. Idealerweise sollte dies jedoch nicht vorkommen. Wenn die Seiten nicht in einem Cache-Speicher zwischengespeichert und nur gesperrte Seiten vom Server 12 zugestellt werden, kann ein zweiter Client die gesperrte Seite nicht mit einem ersten Client überschneidend abrufen. Im Hinblick auf die Stabilität deckt das oben verwendete Skript-Beispiel allerdings jede dieser fünf Möglichkeiten ab (unter der Annahme, dass ein Ablegen im Cache-Speicher möglich ist), sodass sich der Server 12 nicht aufhängen kann.
Beim Lesen obiger Ausführungen kann man erkennen, dass die vorliegende Erfindung eine Sitzungskontrolle für HTTP-Übertragungen ermöglicht, obwohl das Web-Protokoll Sitzungen ausschließlich als eine Seitenanfrage und eine Seitenrückmeldung definiert. Mit der vorliegenden Erfindung kann ein Server erkennen, wie lange ein Client eine Seite einsieht und kann anderen Clients den Zugriff auf Seiten mit Datenbankinformationen verweigern, wenn andere Clients bereits auf diese Datenbankeinträge zugreifen.
Auch wenn die Erfindung in Verbindung mit der Ausführungsform beschrieben wurde, die gegenwärtig sowohl als die brauchbarste und als auch die bevorzugte angesehen wird, so ist doch ersichtlich, dass die Erfindung nicht auf die offenbarte Ausführungsform beschränkt ist, sondern im Gegenteil innerhalb des Schutzbereichs der beigefügten Ansprüche viele Modifikationen und äquivalente Ausführungen umfasst.

Claims

Netzwerkserver (12), der so angeschlossen ist, dass Clients (#1, ..., #n) der Zugriff auf ein Netzwerk ermöglicht wird, wobei die Clients (#1, ..., #n) auf den Netzwerkserver (12) in Übereinstimmung mit einem Sitzungsprotokoll zugreifen, das eine Sitzung als eine Sitzungsanforderung und eine Sitzungsrückmeldung festlegt, wobei der Netzwerkserver umfasst: – einen Speicher zum Speichern von Seiteninformationen, und – einen Seitenkompilierer, um von einem anfragenden Client eine Anforderung einer Seite zu empfangen, in Erwiderung auf die Anfrage unter Verwendung einiger der gespeicherten Seiteninformationen eine Seite zu erstellen und die erstellte Seite über das Netzwerk an den anfragenden Client zu übermitteln, dadurch gekennzeichnet, dass der Seitenkompilierer zum Anfügen einer Seiten-Skriptfunktion an die erstellte Seite und zum Übertragen der Seiten-Skriptfunktion mit der erstellten Seite ausgebildet ist, wobei die Skriptfunktion Anweisungen enthält, die ausgeführt eine Vielzahl zusätzlicher, vom anfragenden Client in einem vorbestimmten Zeitabstand oder in vorbestimmten Zeitabständen an den Server zu sendenden Mitteilungen erzeugen.
Netzwerkserver (12) nach Anspruch 1, worin der Server (12) ausgebildet ist, im Anschluss daran anderen Clients, die die gespeicherten Seiteninformationen abfragen, durch Ändern des Zugriffs auf zumindest einige der gespeicherten Seiteninformationen zu erwidern, bis das Ausbleiben einer zusätzlichen Mitteilung anzeigt, dass der anfragende Client die Seiten-Skriptfunktion nicht länger ausführt.
Netzwerkserver (12) nach Anspruch 1 oder 2, worin die Skriptfunktion die zusätzliche Mitteilung nur solange erzeugt, wie der anfragende Client die erstellte Seite verwendet.
Netzwerkserver (12) nach einem der vorangehenden Ansprüche, worin die Skriptfunktion die zusätzliche Mitteilung nur solange erzeugt, wie der anfragende Client (#1) die erstellte Seite kontinuierlich benutzt.
Netzwerkserver (12) nach einem der vorangehenden Ansprüche, worin der Seitenkompilierer ferner eine Skriptroutine zum Erzeugen einer von dem Server (12) an den anfragen Client (#1) zu sendenden Antwortmitteilung umfasst und worin die zusätzliche Mitteilung Anforderungen an den Server (12) zum Ausführen der Skriptroutine enthält und dadurch die Antwortmitteilung jedes Mal erzeugt und gesendet wird, wenn der Server (12) die zusätzliche Mitteilung erhält.
Netzwerkserver (12) nach Anspruch 4, worin die Antwortmitteilung eine leere Nachricht ist.
Netzwerkserver (12) nach einem der vorangehenden Ansprüche, der ferner ein Zugriffsprotokoll (14) zum Aufzeichnen aller erhaltenen Seitenanfragen umfasst.
Netzwerkserver (12) nach Anspruch 7, worin das Zugriffsprotokoll (14) aufzeichnet, wann alle Seitenanfragen und zusätzlichen Mitteilungen erhalten wurden, und worin der Netzwerkserver (12) ferner einen Prozessor zum Analysieren des Zugriffprotokolls (14) umfasst, um auf Grundlage dieser Aufzeichnung zu entscheiden, ob ein anfragender Client (#1) eine angeforderte Seite weiterhin benutzt.
Netzwerkserver (12) nach einem der vorangehenden Ansprüche, worin der Speicher ein Dateiverzeichnis enthält.
Netzwerkserver (12) nach Anspruch 9, worin die Seiteninformation Seitendateien umfasst.
Netzwerkserver (12) nach einem der vorangehenden Ansprüche, worin der Speicher eine Datenbank (16) umfasst.
Netzwerkserver (12) nach Anspruch 11, worin die Seiteninformation Datenpunkte enthält, die von dem anfragenden Client (#1) in der Datenbank (16) abgerufen und geändert werden können.
Netzwerkserver (12) nach Anspruch 12, worin die Datenbank (16) für diese Datenpunkte Felder für Datum und Zeit umfasst und jedes dieser Felder für Datum und Zeit Informationen enthält, die erkennen lassen, welcher der anfragenden Clients (#1) zuletzt auf einen zugehörigen Datenpunkt zugegriffen hat und wann dieser letzte Zugriff stattfand.
Netzwerkserver (12) nach Anspruch 12, worin die Datenbank (16) für diese Datenpunkte Felder für Datum und Zeit umfasst, und jedes dieser Felder für Datum und Zeit Informationen enthält, die zumindest einen anfragenden Client (#1) identifizieren können, der kürzlich auf einen zugehörigen Datenpunkt zugegriffen hat, und erkennen lassen, wann diese letzten Zugriffe durch diesen zumindest einen anfragenden Client stattfanden.
Netzwerkserver (12) nach einem der vorangehenden Ansprüche, worin die ausführbaren Anweisungen zum Erzeugen mehrfacher zusätzlicher Mitteilungen eingerichtet sind, die vom anfragenden Client (#1) mit einer konstanten, vorbestimmten Zeitspanne zwi schen aufeinanderfolgenden zusätzlichen Mitteilungen an den Server (12) gesendet werden sollen.
Netzwerkserver (12) nach einem der Ansprüche 1 bis 14, worin die Zeitspannen unregelmäßig sind.
Verfahren zum Erstellen einer Seite für die Übertragung auf einem Netzwerk mit Clients (#1, ..., #n) und Servern (12) unter Verwendung eines Sitzungsprotokolls, das jede Sitzung als eine Sitzungsanfrage und eine Sitzungsrückmeldung definiert, das umfasst: – Empfangen einer Seitenanforderung von einem anfragenden Client, – Abrufen von Seiteninformation zum Aufbau einer angeforderten Seite; – Kompilieren der Seiteninformation in die angeforderte Seite, und – Übermitteln der Seite an den anfragenden Client (#1) über das Netzwerk, gekennzeichnet durch Anfügen einer Seiten-Skriptfunktion an die angeforderte Seite und Anfügen der Seiten-Skriptfunktion zu der übertragenen Seite, wobei die Seiten-Skriptfunktion Anweisungen enthält, die ausgeführt eine Vielzahl zusätzlicher, vom anfragenden Client (#1) in einem vorbestimmten Zeitabstand oder in vorbestimmten Zeitabständen an den Server zu sendenden Mitteilungen erzeugen.
Verfahren nach Anspruch 17, worin der Schritt zum Abrufen den Schritt zum Zugreifen auf ein Dateiverzeichnis für zumindest einige der Seiteninformationen umfasst.
Verfahren nach Anspruch 17, worin der Schritt zum Abrufen den Schritt zum Zugreifen auf eine Datenbank für zumindest einige der Seiteninformationen umfasst.
Verfahren nach Anspruch 17, das ferner den Schritt umfasst, dass für andere anfragende Clients die angeforderte Seite solange gesperrt ist, bis die Seiten-Skriptfunktion die zusätzlichen Meldungen nicht mehr in dem vorbestimmten Zeitabstand oder den vorbestimmten Zeitabständen sendet.