nicht angemeldet
Erkennen, ob User noch auf der Seite. bzw aktiv ist. Möglich ?
Hallo alle zusammen,
ist es möglich, das man per Perl-Script erkennt, ob noch der User auf der Seite bzw angemeldet ist.
Kleines Beispiel:
Ich habe ein LogIn mit Benutzer und Passwort.
Der Benutzer darf nur einmal angemeldet sein und das Passwort muß auch richtig sein. Bis hier hin alles kein Problem.
Nur wie erkenne ich, daß der Benutzer nicht mehr da ist, weil er z.B. den Browser geschlossen hat ohne sich abzumelden, die Verbindung wurde unterbrochen, Rechner ist abgestürzt oder ähnliches.
Kann mir jemand bei dem Problem helfen ? Weiß jemand Rat ?
Am besten als Beispiel zum Durchtesten.
Danke im voraus
Mario19
-
Hoi,
ist es möglich, das man per Perl-Script erkennt, ob noch der User
auf der Seite bzw angemeldet ist.Nein.
Nur wie erkenne ich, daß der Benutzer nicht mehr da ist, weil er
z.B. den Browser geschlossen hat ohne sich abzumelden, die
Verbindung wurde unterbrochen, Rechner ist abgestürzt oder
ähnliches.Gar nicht. Du kannst hoechstens mit Sessions arbeiten und fuer diese
Sessions einen Timeout definieren. Will heissen, du startest beim
Login des Users eine Session, und wenn er eine Zeit lang nichts
gemacht hat, dann verfaellt sie. Aber letztenendes hast du keinerlei
Kontrolle darueber, ob der User noch da ist oder nicht.Am besten als Beispiel zum Durchtesten.
Ich glaube nicht, Tim.
Gruesse aus MS,
c.j.k-
Danke Christian,
dann muß ich mir irgendetwas anderes einfallen lassen.
Bis dahin
M19
-
Hi,
dann muß ich mir irgendetwas anderes einfallen lassen.
das denke ich auch. Mein Vorschlag: Nicht HTTP verwenden.
Viele Grüße
Michael-
Hoi Michael,
dann muß ich mir irgendetwas anderes einfallen lassen.
das denke ich auch. Mein Vorschlag: Nicht HTTP verwenden.
Letztenendes gilt das aber auch fuer andere Protokolle, etwa TCP. Hier
wird auch 'nur' auf einen Timeout gewartet, wenn keine Antwort kommt.
Die FIN-ACK-FIN-ACK-Folge ist zwar vorgeschrieben, aber im Zweifelsfall
wuerde ich da nicht drauf setzen (Verbindungs-Abbruch, ...).Gruesse,
c.j.k-
Yo!
Letztenendes gilt das aber auch fuer andere Protokolle, etwa TCP. Hier
wird auch 'nur' auf einen Timeout gewartet, wenn keine Antwort kommt.Das gilt aber für alles, was sich auf der Ebene von TCP abspielt: Datenpakete werden bedarfsweise hin- und hergeschickt, aber ohne Erfolgsgarantie.
Wenn ständiger Kontakt gewünscht ist, bzw. verbindungsorientierte Verbindungen, ist das eine Aufgabe für die darüberliegende Protokolle.
- Sven Rautenberg
-
Hoi,
Letztenendes gilt das aber auch fuer andere Protokolle, etwa TCP.
Hier wird auch 'nur' auf einen Timeout gewartet, wenn keine
Antwort kommt.Das gilt aber für alles, was sich auf der Ebene von TCP abspielt:
Datenpakete werden bedarfsweise hin- und hergeschickt, aber ohne
Erfolgsgarantie.Entschuldigung, aber das ist Unsinn. Ich glaube, du verwechselst das
mit UDP. TCP garantiert, dass alle Datenpakete, wenn eben moeglich,
ankommen -- und das sogar in der richtigen Reihenfolge.Wenn ständiger Kontakt gewünscht ist, bzw. verbindungsorientierte
Verbindungen, ist das eine Aufgabe für die darüberliegende
Protokolle.Ich glaube, du verwechselst da was mit UDP.
Gruesse,
c.j.k-
Moin!
Das gilt aber für alles, was sich auf der Ebene von TCP abspielt:
Datenpakete werden bedarfsweise hin- und hergeschickt, aber ohne
Erfolgsgarantie.Entschuldigung, aber das ist Unsinn. Ich glaube, du verwechselst das
mit UDP. TCP garantiert, dass alle Datenpakete, wenn eben moeglich,
ankommen -- und das sogar in der richtigen Reihenfolge.Dein Einwand ist verständlich, weil ich mich nicht ganz deutlich ausgedrückt habe.
TCP baut eine "gesicherte Verbindung" auf. Es bemerkt aber den Verlust dieser Verbindung erst, wenn das nächste Datenpaket nicht mehr durchkommt. Es ist also problemlos möglich, das Netzwerkkabel 10 Minuten abzutrennen, den Rechner durch halbe Haus zu schleppen, dort wieder zu verbinden, und die geöffneten Verbindungen weiterzubenutzen, als wäre nichts geschehen - wenn in der Zeit keine Daten gesendet werden. Soll heißen: Auch bei TCP merkt man den Daten- und Verbindungsverlust erst, wenn er bereits erfolgt ist, weil nicht ständig kontrolliert wird, ob die Verbindung noch steht. Deshalb: "Ohne Erfolgsgarantie" daß die Daten auch ankommen. Bei TCP kriegt man diese Tatsache freundlicherweise recht schnell mit, bei UDP muß man es aus der fehlenden Antwort schließen - sofern man eine erwartet.
Wenn ständiger Kontakt gewünscht ist, bzw. verbindungsorientierte
Verbindungen, ist das eine Aufgabe für die darüberliegende
Protokolle.Ich glaube, du verwechselst da was mit UDP.
Tja, das glaube ich eben nicht. :)
- Sven Rautenberg
-
-
-
-
-
-