Nachdem meine ersten Versuche was Server/Client-Programmierung mit Indy10 recht gut verlaufen, möchte ich das ganze etwas ausbauen, und da weiß ich nicht, wie ich das regeln soll, bzw. wie das sonst so gemacht wird.

Ich möchte gerne die Kommunikation einschränken lassen können. D.h. der Server akzeptiert z.B. nur Anfragen aus dem LAN, und/oder nur nach einer Anmeldung. Wie mach ich das? Klar, der Client muss eine Anmelde-Anforderung senden mit Name und Passwort. Der Server überprüft dann IP und Anmeldedaten und erlaubt ggf. die Verbindung oder verweigert sie.

Und dann? Soll ich die Verbindung während der gesamten Programmlaufzeit des Clienten offenlassen? Bis jetzt starte ich für jede Anfrage an den Server eine neue Verbindung und beende die nach dem kleinen Frage-Antwort-Spielchen. Also Connect-WriteQuery-ReadAnswer-Disconnect auf Clientseite.
So bräuchte ich auf der Serverseite eine Liste mit verifizierten IPs, um bei einem neuen Verbindungsaufbau (mit einer Datenanfrage vom Clienten) die IP mit denen in der Liste zu vergleichen. Wenn die IP ok ist, dann wird dei Datenanfrage bearbeitet, ansonsten kommt ne Meldung zurück "Bitte erst anmelden" oder "Zugriff nur vom LAN erlaubt".

Wie macht man das normalerweise?

Nur die IPs zu speichern reicht warscheinlich nicht, es könnte ja zwischenzeitlich ein anderer User/Client auf der selben IP versuchen, sich am Server anzumelden.

Du könntest dem Client nach erfolgter erstmaliger Anmeldung eine Session-Id verpassen, die der Vlient bei jeder folgenden Anfrage mitübermitteln muss. So musst du statt auf IP und Passwort nur auf die Session-Id prüfen.

Hi,

Vorneweg: Keine Ahnung wie du das machst, aber ich kenne es aus anderen Programmen, da lasse ich meine User nur 15 Minuten aktiv sein, sonst sollen sie sich neu anmelden. Die Abmeldung macht der Server.

Anderes Beispiel wären Session und Cookies ähnlich deiner Variante.

Du verwendest eine TCP-Connection? Wieso lässt Du diese dann nicht offen?

Du musst nur ab und zu ein kleines Paket schicken, damit die Verbindung nicht aufgrund eines Timeouts beendet wird. Nach erfolgter Authentifizierung verwaltest Du dann die Verbindungsthreads und hast somit alle Verbindungen immer im Griff und brauchst nicht jedes Mal zu authentifizieren.

Moin!

Ich sehe da auch die zwei schon genannten Möglichkeiten als Standard:

a) Single-TCP-Session authentifizieren und offen halten, ggfs. KeepAlive-Pakete senden (ca. alle 60sec. min 1 Byte, sonst machen manche Router ihre TCP-Table leer). Vorteil: wenig Aufwand, relativ sicher; Nachteil: wenn viele Benutzer erwartet werden, gibt es u.U. Restriktionen im OS zu beachten, wenn es keine Server-Variante ist (MaxTCPConnections)!

b) Multiple-TCP-Sessions: eine Authentifizierungs-Session, in der eine Sitzungskennung und ein -schlüssel ausgehandelt werden. Folgende TCP-Sessions werden dann RC4-verschlüsselt abgehandelt (RC4 ist so schnell, dass es als "Bremse" vernachläsigbar ist). Am Server wird die Kennung zum Indizieren des Schlüssels verwendet. Vorteil: wenige gleichzeitige Sessions; Nachteil: hoher Aufwand

cu
Narses

Wenn Du keine ständige Verbindung haben willst, dann wechsle besser zu UDP, denn der Overhead von TCP ist beim Verbindungsaufbau auch nicht zu vernachlässigen. Aber: Auch wieder höherer Aufwand.

UGrohne hat folgendes geschrieben:

Du verwendest eine TCP-Connection? Wieso lässt Du diese dann nicht offen?

Weil ich von der Materie praktisch gar keine Ahnung habe und nicht wusste, dass man das ohne weiteres machen kann ohne irgendwelche Komplikationen zu bekommen. Wenn das "erlaubt" ist, dann werde ich das wohl so machen.

Um zu viele Nutzer mache ich mir keine Sorgen. Das werden in aller Regel höchstens ein oder zwei sein - mehr wäre Unfug.