Programmieren 2 12 Netzwerke Bachelor Medieninformatik Sommersemester 2015 Dipl.-Inform. Ilse Schmiedecke schmiedecke@beuth-hochschule.de 1
Motivation Datenaustausch zwischen Programmen Spielstand Chat Datei Termine 2 2
Direkte Kommunikation zwischen Prozessen Zur Erinnerung: Prozess: Programm Eigenständige, vom BS verwaltete Programmausführung Eigener (vor anderen Programmen) geschützter Datenbereich im Speicher Kommunikation mit anderen Programmen (auf demselben Rechner) über das Dateisystem Thread: Programm-interne zusätzliche Ausführung vom Programm (Prozess) verwaltet "aktives Objekt" (1. Semester: Animate-Objekt mit Animator Thread) gemeinsamer Datenbereich Kommunikation über gemeinsame Objekte möglich (1. Semester: Message Channel) 3 3
Socket: Die Schnittstelle zur "Außenwelt" Socket-Verbindung Live-Datenaustausch zwischen Prozessen Prozess-"Adresse": IP-Nummer (Rechner) und Portnummer (Prozess) Der eigene Rechner hat die IP "localhost" oder "127.0.0.1" Portnummern zwischen 0 und 6000 (genau 65535) wählbar 0 1024 "reserviert" für Standard-Dienst-Prozesse Client-Server-Modell Ein Server-Prozess läuft (oft im Hintergrund) und bedient Client-Anfragen ServerSocket legt eine Portnummer fest erkennt Client-Anfragen und stellt eine Verbindung her (Client)Socket wird mit IP-Adresse und Portnummer auf ein ServerSocket "gerichtet" 4 4
Socket-Erzeugung Im Server Server-Socket erzeugen: Im Client Socket erzeugen, incl. Verbindungsanfrage : Im Server Client-Verbindungsanfrage bearbeiten, Socket-Verbindung zum Client erstellen (blockiert) Nicht vergessen: IOException immer möglich! 5 5
Socket-Kommunikation Jedes Socket besitzt einen Eingabe- und einen Ausgabestrom Wenn die Verbindung steht, können Daten gesendet und empfangen werden: Spieler1 (Server) out in Spieler2 in out 6 6
Fragen zum Nachdenken Könnten auch beide Spieler "Server" sein? Wie würde man eine Spieler-Runde realisieren? accept() blockiert, d.h. bis eine Client-Anfrage kommt, kann der Server nichts machen. Wie würde man das machen, wenn er mehrere Clients parallel bedienen soll? read() blockiert, d.h. solange nichts ankommt, lann der wartende Empfänger nichts machen. Wie lässt sich das lösen? 7 7
Entfernte Spieler im Live-Austausch statt store/restoreavatar jetzt send/receiveavatar play() Endlosschleife receiveavatar, gain strength, sendavatar Ausstieg bei 30 Assets durch send/receive null 8 8
play Spielen bedeutet: in einer Endlosschleife Avatar lesen, verändern, senden Endekriterium: Ein Spieler sendet null 9 9
Lesen und Schreiben Die Spieler unterscheiden sich nur durch das Socket, das im Konstruktor fesetzt wird. 10 10
Spieler in der Runde Jeder Spieler hat zwei Sockets: eines als Server, so dass er vom Vorgänger Kontaktiert werden kann. Dort liest er nur. eines als Client, um sich mit dem Nachfolger zu verbinden. Dort schreibt er nur 11 11
Und jetzt noch ein Chat Chat Es gibt einen Chatserver, mit dem sich alle Clients verbinden Client schickt Nachricht an den Server Server gibt die Nachricht an alle Clients weiter Client Client Client Chatserver Client Client 12 12
Einfaches Prinzip - ABER Clients: send receive and display Server : receive from someone send to all Problem: Receive blockiert: Während der Server auf einen client wartet, kommt kein anderer durch Während der Client auf Nachrichten wartet, kann er keine schreiben. 13 13
Risky Simplicity Für jeden Client einen Input- Wächter als Thread! 14 14
Ausweg: Threads Aktive Objekte Definition Thread (Kontrollfaden) Jeder Prozess hat einen Haupt-Thread (z.b. main) weiteres ausführbares Programm innerhalb eines Prozesses Ausführung "parallel" zum HauptThread Häufigste Verwendung: lange oder blockierende Programmteile auslagern Haupt-Thread läuft weiter Neben-Thread muss vielleicht warten schreibt Ergebnis in eine Datenstruktur oder löst ein Event aus 15 15
cs101.lang.animate und java.lang.runnable "Animierbare" Klasse mit der cs101-bibliothek: act() überschreiben, wird in Endlosschleife ausgeführt Parallel ausführbare Klasse mit der Java-Standard-Bibliothek: run() überschreiben, wird nur 1x ausgeführt (Schleife ggf. in run() ) 16 16
cs101.lang.animatorthread und java.util.thread Starten des nebenläufigen Thread, z.b. in einer main-methode wiederholter nebenläufiger Aufruf von act() einmaliger nebenläufiger Aufruf von run() 17 17
Verbesserung des Servers Der Hauptthread wartet auf eine Verbindungsanfrage (blockiert) erstellt die Verbindung startet einen neuen Lese-Thread und wartet auf die nächste Verbindungsanfrage. Der Lese-Thread wartet auf eine Nachricht von genau einem Client (blockiert) versendet sie an alle Clients und wartet auf die nächste Nachricht 18 18
Der Lese-Thread: Ein Runnable-Objekt 19 19
Starten des Lese-Thread im ChatServer 20 20
Und der Client? In Endlosschleife Wartet auf Eingabe aus dem Textfeld Sendet Eingabe an den Server Wartet auf Server-Nachrichten Lese-Thread Wartet auf Nachricht vom Server Hängt sie an die vorigen Nachrichten an Wartet wieder Haupt-Thread Startet Lese-Thread Wartet auf Benutzereingabe sendet sie an den Server Wartet wieder 21 21
FX ChatFrame mit LeseThread FX ChatFrame ist BorderPane (250, 200) 22 22
Die Netzwerk-Interaktion 23 23
Der Lese-Thread, Version 1 Funktioniert, aber: JavaFX erlaubt keine UI-Updates aus einem nicht von FX kontrollierten Thread: 24 24
Der FX-kompatible Lese-Thread mit Platform.runLater wird FX die Kontrolle über den Thread gegeben 25 25
Wie geht es weiter? Clients mit Namen, Teilnehmerliste? Clients registrieren sich beim Server mit Namen Server meldet Teilnahme und Ausstieg an alle Clients Server stellt der Nachricht den Namen voran Chat von Rechner zu Rechner? benutzen sie statt "localhost" die echte IP-Adresse des Servers Problem sind oft Port-Freigaben Security-Einstellungen des Rechners ggf. ändern Port-Freigaben im lokalen Netzwerk nur durch Admin Port 8080 ist meist freigegeben Chat ohne Server? P2P-Chat? Jeder Client ist auch Server Jeder Client "lauscht" auf die bei ihm registrieten Clients 26 26
Das waren die Networking-Grundlagen Ihrer Phantasie sind kaum Grenzen gesetzt 27 27