Preview only show first 10 pages with watermark. For full document please download

übungen Zu Systemprogrammierung 2 (sp2) Agenda ü2 – Ipc Mit Sockets, Signale

   EMBED

Share

Transcript

Agenda Übungen zu Systemprogrammierung 2 (SP2) 2.1 2.2 2.3 2.4 2.5 2.6 2.7 Ü2 – IPC mit Sockets, Signale C. Erhardt, J. Schedel, A. Ziegler, J. Kleinöder 22-ServerSockets_handout 22-ServerSockets_handout Lehrstuhl für Informatik 4 Verteilte Systeme und Betriebssysteme IPC-Schnittstelle: Server UNIX-Signale Signal-API von UNIX Einsammeln von Zombies Makefiles – Teil 3 Aufgabe 2: sister Gelerntes anwenden Friedrich-Alexander-Universität Erlangen-Nürnberg WS 2015 – 02. bis 06. November 2015 https://www4.cs.fau.de/Lehre/WS15/V_SP2 c ce, js, az, jk Agenda SP2 (Ü2 | WS 2015) 2 Server-Sockets und Signale 2–1 IPC-Schnittstelle: Server Ausgangssituation: Socket wurde bereits erstellt (socket(2)) Nach seiner Erzeugung muss der Socket zunächst an eine Adresse gebunden werden, bevor er verwendet werden kann IPC-Schnittstelle: Server UNIX-Signale Signal-API von UNIX Einsammeln von Zombies Makefiles – Teil 3 Aufgabe 2: sister Gelerntes anwenden bind(2) stellt eine generische Schnittstelle zum Binden von Sockets in unterschiedlichen Domänen bereit: int bind(int sockfd, const struct sockaddr *addr, socklen_t addrlen); 22-ServerSockets_handout sockfd: Socket-Deskriptor addr: protokollspezifische Adresse 22-ServerSockets_handout 2.1 2.2 2.3 2.4 2.5 2.6 2.7 c ce, js, az, jk SP2 (Ü2 | WS 2015) 2 Server-Sockets und Signale | 2.1 IPC-Schnittstelle: Server 2–2 Socket-Interface () ist zunächst protokollunabhängig: struct sockaddr { sa_family_t sa_family; // Adressfamilie char sa_data[14]; // Platzhalter fuer Adresse }; „Klassenvererbung für Arme“; i. d. R. Cast notwendig addrlen: Länge der konkret übergebenen Struktur in Bytes c ce, js, az, jk SP2 (Ü2 | WS 2015) 2 Server-Sockets und Signale | 2.1 IPC-Schnittstelle: Server 2–3 Adress-Struktur bei IPv4-Sockets Adress-Struktur bei IPv6-Sockets IPC-Schnittstelle Name durch IPv4-Adresse und Port-Nummer definiert: Name durch IPv6-Adresse und Port-Nummer definiert: struct sockaddr_in sa_family_t in_port_t struct in_addr }; struct sockaddr_in6 sa_family_t in_port_t uint32_t struct in6_addr uint32_t }; { sin6_family; sin6_port; sin6_flowinfo; sin6_addr; sin6_scope_id; struct in6_addr { unsigned char }; s6_addr[16]; { sin_family; // = AF_INET sin_port; // Port sin_addr; // Internet-Adresse sin_port: Port-Nummer sin_addr: IPv4-Adresse INADDR_ANY: wenn Socket auf allen lokalen Adressen (z. B. allen Netzwerkschnittstellen) Verbindungen akzeptieren soll Umwandlung mittels htons(3), htonl(3): konvertiert Datenwort von Host-spezifischer Byteorder in Netzwerk-Byteorder – bzw. zurück: uint32_t uint16_t uint32_t uint16_t c ce, js, az, jk htonl(uint32_t htons(uint16_t ntohl(uint32_t ntohs(uint16_t SP2 (Ü2 | WS 2015) hostlong); hostshort); netlong); netshort); 2 Server-Sockets und Signale | 2.1 IPC-Schnittstelle: Server 22-ServerSockets_handout sin_port und sin_addr müssen in Netzwerk-Byteorder vorliegen! 22-ServerSockets_handout IPC-Schnittstelle = AF_INET6 Port-Nummer = 0 IPv6-Adresse = 0 sin6_port: Port-Nummer sin6_addr: IPv6-Adresse in6addr_any: auf allen lokalen Adressen Verbindungen akzeptieren sin6_port muss in Netzwerk-Byteorder vorliegen (htons(3)) in6_addr-Struktur ist byteweise definiert, deswegen keine Konvertierung nötig c ce, js, az, jk 2–4 // // // // // SP2 (Ü2 | WS 2015) 2 Server-Sockets und Signale | 2.1 IPC-Schnittstelle: Server 2–5 IPC-Schnittstelle: Server IPC-Schnittstelle: Server Verbindungsannahme vorbereiten mit listen(2): Verbindung annehmen mit accept(2): int listen(int sockfd, int backlog); int accept(int sockfd, struct sockaddr *addr, socklen_t *addrlen); backlog: (Unverbindliche) Größe der Warteschlange, in der eingehende addr, addrlen: Ausgabeparameter zum Ermitteln der Adresse des Verbindungswünsche zwischengepuffert werden Clients Bei voller Warteschlange werden Verbindungsanfragen zurückgewiesen Maximal mögliche Größe: SOMAXCONN Bei Desinteresse zweimal NULL übergeben Entnimmt die vorderste Verbindungsanfrage aus der Warteschlange Blockiert bei leerer Warteschlange 22-ServerSockets_handout 22-ServerSockets_handout Erzeugt einen neuen Socket und liefert ihn als Rückgabewert c ce, js, az, jk SP2 (Ü2 | WS 2015) 2 Server-Sockets und Signale | 2.1 IPC-Schnittstelle: Server 2–6 Kommunikation mit dem Client über diesen neuen Socket Annahme weiterer Verbindungen über den ursprünglichen Socket c ce, js, az, jk SP2 (Ü2 | WS 2015) 2 Server-Sockets und Signale | 2.1 IPC-Schnittstelle: Server 2–7 TCP/IP-Sockets: Zusammenfassung Beispiel: einfacher Echo-Server U2 2. Übung 3 TCP-Sockets: Zusammenfassung Server ! Client IPC-Schnittstelle Fehlerabfragen nicht vergessen int listenSock = socket(AF_INET6, SOCK_STREAM, 0); socket socket struct sockaddr_in6 name = { .sin6_family = AF_INET6, .sin6_port = htons(1112), .sin6_addr = in6addr_any, }; bind(listenSock, (struct sockaddr *) &name, sizeof(name)); bind listen listen(listenSock, SOMAXCONN); read/write Kommunikation Verbindungsabbau close connect read/write close ■ Statt der Systemaufrufe read(2)/write(2) können auch Bibliotheksfunktionen c ce, js, az, jk SP2 (Ü2 | WS 2015) 2 Server-Sockets und Signale | 2.1 IPC-Schnittstelle: Server 2–8 wie zum Beispiel fgets(3), fputs(3) oder fprintf(3) verwendet werden. Beispiel: einfacher Echo-Server Systemprogrammierung — Übungen © Jürgen Kleinöder, Michael Stilkerich, Jens schedel, Christoph Erhardt • Universität Erlangen-Nürnberg • Informatik 4, 2012 IPC-Schnittstelle U02.fm 2012-05-08 14.11 U2.5 Reproduktion jeder Art oder Verwendung dieser Unterlage, außer zu Lehrzwecken an der Universität Erlangen-Nürnberg, bedarf der Zustimmung des Autors. for (;;) { int clientSock = accept(listenSock, NULL, NULL); char buf[1024]; ssize_t n; while ((n = read(clientSock, buf, sizeof(buf))) > 0) { write(clientSock, buf, n); } close(clientSock); } 2 Server-Sockets und Signale | 2.1 IPC-Schnittstelle: Server 2–9 „Wiederverwenden“ von Ports Nach Beendigung des Server-Prozesses erlaubt das Betriebssystem kein sofortiges bind(2) an den selben Port 22-ServerSockets_handout 1. Bei jedem Start einen anderen Port verwenden – doof! 1. Mehrere Prozesse Anfrage wird durch Kindprozess bearbeitet 2. Mehrere Threads Anfrage wird durch einen Thread im gleichen Prozess bearbeitet 2 Server-Sockets und Signale | 2.1 IPC-Schnittstelle: Server SP2 (Ü2 | WS 2015) Lösungsmöglichkeiten: Mögliche Ansätze zur Abhilfe: SP2 (Ü2 | WS 2015) c ce, js, az, jk Testen und Debuggen eines Server-Programms dadurch stark erschwert Neue Verbindung kann erst nach vollständiger Abarbeitung der vorherigen Anfrage angenommen werden Monopolisierung des Dienstes möglich (Denial of Service)! c ce, js, az, jk for (;;) { int clientSock = accept(listenSock, NULL, NULL); char buf[1024]; ssize_t n; while ((n = read(clientSock, buf, sizeof(buf))) > 0) { write(clientSock, buf, n); } close(clientSock); } Erst nach Timeout erneut möglich Grund: es könnten sich noch Datenpakete für den alten Prozess auf der Leitung befinden Limitierungen: 22-ServerSockets_handout SP - Ü 22-ServerSockets_handout accept 22-ServerSockets_handout Verbindungsaufbau 2–10 2. Sofortige Wiederverwendung des Ports forcieren: int sock = socket(...); ... int flag = 1; setsockopt(sock, SOL_SOCKET, SO_REUSEADDR, &flag, sizeof(flag)); ... bind(sock, ...); c ce, js, az, jk SP2 (Ü2 | WS 2015) 2 Server-Sockets und Signale | 2.1 IPC-Schnittstelle: Server 2–11 Agenda UNIX-Signale Essenzielles Betriebssystemkonzept: synchrone/asynchrone Programmunterbrechungen (Traps bzw. Interrupts) Zweck: Signalisierung von Ereignissen Abwicklung zwischen Hardware und Betriebssystem Transparent für die Anwendung IPC-Schnittstelle: Server UNIX-Signale Signal-API von UNIX Einsammeln von Zombies Makefiles – Teil 3 Aufgabe 2: sister Gelerntes anwenden UNIX-Signale: Nachbildung des Konzepts auf Anwendungsebene Abwicklung zwischen Betriebssystem und Anwendung Unabhängig von der Hardware 22-ServerSockets_handout 22-ServerSockets_handout 2.1 2.2 2.3 2.4 2.5 2.6 2.7 c ce, js, az, jk SP2 (Ü2 | WS 2015) 2 Server-Sockets und Signale | 2.2 UNIX-Signale U2-1 Signale c ce, js, az, jk 2–12 2 Signalisierung des Systemkerns UNIX-Signale Prozess2 Prozess3 (Segmentation Fault, SIGSEGV) Prozess1 2–13 Anwendungsfall 2: primitive „Kommunikation“ zwischen Prozessen durch den Betriebssystemkern Schreibzugriff auf nicht-schreibbaren Prozess2 Speicherbereich 2 Server-Sockets und Signale | 2.2 UNIX-Signale UNIX-Signale ■ synchrone Signale: unmittelbar durch Aktivität des Prozesses ausgelöst Anwendungsfall 1:außen" Signalisierungen ■ asynchrone Signale: "von ausgelöst SP2 (Ü2 | WS 2015) Prozess Ereignis ist eingetreten beenden (SIGUSR1) (SIGTERM) Prozess3 Prozess1 Kernel Synchrone Signale: unmittelbar durch Aktivität des Prozesses ausgelöst U2.7 Asynchrone Signale: „von Erlangen-Nürnberg außen“ ausgelöst © Jürgen Kleinöder, Michael Stilkerich, Jens schedel, Christoph Erhardt • Universität • Informatik 4, 2012 U02.fm 2012-05-08 14.11 Systemprogrammierung — Übungen 22-ServerSockets_handout 22-ServerSockets_handout SP - Ü (Prozess beenden, SIGINT) Kernel Asynchron zum eigentlichen Programmablauf Reproduktion jeder Art oder Verwendung dieser Unterlage, außer zu Lehrzwecken an der Universität Erlangen-Nürnberg, bedarf der Zustimmung des Autors. c ce, js, az, jk SP2 (Ü2 | WS 2015) 2 Server-Sockets und Signale | 2.2 UNIX-Signale 2–14 c ce, js, az, jk SP2 (Ü2 | WS 2015) 2 Server-Sockets und Signale | 2.2 UNIX-Signale 2–15 U2-1 Signale Reaktion des 3 Reaktion auf Prozesses Signale UNIX-Signale Ign ■ abort Ignorieren des Signals ◆ erzeugt Core-Dump (Segmente + Registerkontext) und beendet Prozess Core ■ exit (Standardreaktion für die(Speicherabbild meisten Signale) Erzeugen eines Core-Dumps + Registerkontext) und Beenden Prozess, des Prozesses ◆ beendet ohne einen Core-Dump zu erzeugen Term ■ ignore Beenden des Prozesses, ohne einen Core-Dump zu erzeugen Standardreaktion ◆ ignoriert Signal für die meisten Signale Aufruf einer vorher festgelegten Funktion, danach Fortsetzen des ◆ Aufruf der Signalbehandlungsfunktion, danach Fortsetzung des Prozesses Prozesses: Signalbearbeitung Signal c ce, js, az, jk SP2 (Ü2 | WS 2015) 2 Server-Sockets und Signale | 2.2 UNIX-Signale Agenda U02.fm 2012-05-08 14.11 SIGINT SIGABRT U2.8 Term Core Beenden durchs Terminal (Ctrl-C) Abort-Signal; entsteht z. B. durch Aufruf von abort(3) SIGFPE Core SIGKILL SIGSEGV Term Core SIGPIPE Term SIGTERM SIGCHLD Term Ign c ce, js, az, jk 2–16 Systemprogrammierung — Übungen © Jürgen Kleinöder, Michael Stilkerich, Jens schedel, Christoph Erhardt • Universität Erlangen-Nürnberg • Informatik 4, 2012 22-ServerSockets_handout SP - Ü 22-ServerSockets_handout Signal-Behandlungsfunktion ■ Signal-Behandlungsfunktion Gängige Signalnummern (mit Standardverhalten) Floating-Point Exception (Division durch 0, Überlauf, ...) „Tötet“ den Prozess; nicht abfangbar Segmentation Violation; illegaler Speicherzugriff Schreiben auf Pipe oder Socket, nachdem die Gegenseite geschlossen wurde Standardsignal von kill(1) Status eines Kindprozesses hat sich geändert SP2 (Ü2 | WS 2015) 2 Server-Sockets und Signale | 2.2 UNIX-Signale Signalbehandlung einrichten 2–17 Signal-API von UNIX Reproduktion jeder Art oder Verwendung dieser Unterlage, außer zu Lehrzwecken an der Universität Erlangen-Nürnberg, bedarf der Zustimmung des Autors. Prototyp: #include IPC-Schnittstelle: Server UNIX-Signale Signal-API von UNIX Einsammeln von Zombies Makefiles – Teil 3 Aufgabe 2: sister Gelerntes anwenden int sigaction(int signum, const struct sigaction *act, struct sigaction *oldact); signum: Signalnummer act: Neue Behandlung für dieses Signal oldact: Bisherige Behandlung dieses Signals (Ausgabeparameter) 22-ServerSockets_handout Die eingerichtete Behandlung bleibt so lange aktiv, bis eine neue mit sigaction() installiert wird 22-ServerSockets_handout 2.1 2.2 2.3 2.4 2.5 2.6 2.7 c ce, js, az, jk SP2 (Ü2 | WS 2015) 2 Server-Sockets und Signale | 2.3 Signal-API von UNIX 2–18 sigaction-Struktur: struct sigaction { void (*sa_handler)(int); // Behandlungsfunktion sigset_t sa_mask; // Blockierte Signale int sa_flags; // Optionen }; c ce, js, az, jk SP2 (Ü2 | WS 2015) 2 Server-Sockets und Signale | 2.3 Signal-API von UNIX 2–19 Signalbehandlung einrichten: sa_handler Signalbehandlung einrichten: sa_mask Signal-API sigaction-Struktur: sigaction-Struktur: struct sigaction { void (*sa_handler)(int); // Behandlungsfunktion sigset_t sa_mask; // Blockierte Signale int sa_flags; // Optionen }; struct sigaction { void (*sa_handler)(int); // Behandlungsfunktion sigset_t sa_mask; // Blockierte Signale int sa_flags; // Optionen }; Über sa_handler kann die Signalbehandlung eingestellt werden: Trifft während der Signalbehandlung dasselbe Signal erneut ein, wird dieses bis zum Ende der Behandlung verzögert (blockiert) SIG_IGN: SIG_DFL: Signal ignorieren Standard-Signalbehandlung einstellen Funktionsadresse: Funktion wird in der Signalbehandlung aufgerufen Maximal ein Ereignis wird zwischengespeichert Mit sa_mask kann man weitere Signale blockieren Hilfsfunktionen zum Auslesen und Modifizieren einer Signal-Maske: 22-ServerSockets_handout 22-ServerSockets_handout c ce, js, az, jk SP2 (Ü2 | WS 2015) 2 Server-Sockets und Signale | 2.3 Signal-API von UNIX Signalbehandlung einrichten: sa_flags sigaddset(3): sigdelset(3): sigemptyset(3): sigfillset(3): sigismember(3): c ce, js, az, jk 2–20 ? 2 Server-Sockets und Signale | 2.3 Signal-API von UNIX 2–21 Signal-API von UNIX Signalbehandlung wird durchgeführt, sobald der Kontrollfluss aus dem Kern zurückkehrt Blockierender Systemaufruf: SA_NOCLDSTOP: SIGCHLD wird nur zugestellt, wenn ein Kindprozess Problem: Die Blockade kann beliebig lang dauern, z. B. beim Warten auf eingehende Verbindungen mit accept(2) 22-ServerSockets_handout terminiert, nicht wenn er gestoppt wird SA_RESTART: durch das Signal unterbrochene Systemaufrufe werden automatisch neu aufgesetzt (siehe nächste Folie) Weitere Flags siehe sigaction(2) 2 Server-Sockets und Signale | 2.3 Signal-API von UNIX Was geschieht, wenn ein Prozess ein Signal erhält, während er sich in einem Systemaufruf befindet? Nicht-blockierender Systemaufruf: Beeinflussung des Verhaltens bei Signalempfang durch sa_flags (0 oder Veroderung von Flag-Konstanten): SP2 (Ü2 | WS 2015) SP2 (Ü2 | WS 2015) Signalbehandlung muss im Benutzerkontext durchgeführt werden struct sigaction { void (*sa_handler)(int); // Behandlungsfunktion sigset_t sa_mask; // Blockierte Signale int sa_flags; // Optionen }; c ce, js, az, jk Bestimmtes Signal zur Maske hinzufügen Bestimmtes Signal aus Maske entfernen Alle Signale aus Maske entfernen Alle Signale in Maske aufnehmen Abfrage, ob bestimmtes Signal in Maske enthalten ist Unterbrechen von Systemaufrufen Signal-API sigaction-Struktur: 22-ServerSockets_handout Signal-API 2–22 Die Signalbehandlung indefinit hinauszuzögern, ist keine gute Idee Lösung: Systemaufruf wird abgebrochen und kehrt mit errno = EINTR zurück, Signal wird sofort behandelt Vereinfachung: Setzt man das Flag SA_RESTART, kehrt der Systemaufruf nicht mit Fehler zurück, sondern wird nach der Signalbehandlung automatisch wiederholt c ce, js, az, jk SP2 (Ü2 | WS 2015) 2 Server-Sockets und Signale | 2.3 Signal-API von UNIX 2–23 Zustellen von Signalen Agenda Signal-API von UNIX Systemaufruf kill(2): int kill(pid_t pid, int sig); 2.1 2.2 2.3 2.4 2.5 2.6 2.7 Shell-Kommando kill(1): Sendet ein Signal an einen bestimmten Prozess z. B. kill -USR1 Shell-Kommando pkill(1): 22-ServerSockets_handout 22-ServerSockets_handout Sendet ein Signal an alle Prozesse, die ein bestimmtes Programm ausführen z. B. pkill -USR1 IPC-Schnittstelle: Server UNIX-Signale Signal-API von UNIX Einsammeln von Zombies Makefiles – Teil 3 Aufgabe 2: sister Gelerntes anwenden c ce, js, az, jk SP2 (Ü2 | WS 2015) 2 Server-Sockets und Signale | 2.3 Signal-API von UNIX c ce, js, az, jk 2–24 Zombies einsammeln mit Hilfe von Signalen SP2 (Ü2 | WS 2015) 2 Server-Sockets und Signale | 2.4 Einsammeln von Zombies 2–25 Agenda Stirbt ein Kindprozess, so erhält der Vater das Signal SIGCHLD vom Kernel Damit ist sofortiges Aufsammeln von Zombieprozessen möglich 2.1 2.2 2.3 2.4 2.5 2.6 2.7 Variante 1: Aufruf von waitpid(2) im Signalhandler Aufruf in Schleife notwendig – während der Signalbehandlung könnten weitere Kindprozesse sterben Variante 3: Signalhandler für SIGCHLD auf SIG_IGN setzen c ce, js, az, jk SP2 (Ü2 | WS 2015) 2 Server-Sockets und Signale | 2.4 Einsammeln von Zombies 22-ServerSockets_handout 22-ServerSockets_handout Variante 2: Signalhandler für SIGCHLD auf SIG_DFL setzen und in den sa_flags den Wert SA_NOCLDWAIT setzen IPC-Schnittstelle: Server UNIX-Signale Signal-API von UNIX Einsammeln von Zombies Makefiles – Teil 3 Aufgabe 2: sister Gelerntes anwenden 2–26 c ce, js, az, jk SP2 (Ü2 | WS 2015) 2 Server-Sockets und Signale | 2.5 Makefiles – Teil 3 2–27 Dynamische Makros Pattern-Regeln $@ Name des Targets (hier: test) Allgemeine Regel zur Erzeugung einer Datei mit einer bestimmten Endung aus einer gleichnamigen Datei mit einer anderen Endung test: test.c $(CC) $(CPPFLAGS) $(CFLAGS) $(LDFLAGS) -o $@ test.c Beispiel: Erzeugung von .o-Dateien aus .c-Dateien $* Basisname des Targets (ohne Dateiendung, hier: test) %.o: %.c $(CC) $(CPPFLAGS) $(CFLAGS) -c $< test.o: test.c test.h $(CC) $(CPPFLAGS) $(CFLAGS) -c $*.c Regeln ohne Kommandos können Abhängigkeiten überschreiben test.o: test.c test.h func.h Die Pattern-Regel wird weiterhin zur Erzeugung herangezogen test.o: test.c test.h $(CC) $(CPPFLAGS) $(CFLAGS) -c $< 22-ServerSockets_handout 22-ServerSockets_handout $< Name der ersten Abhängigkeit (hier: test.c) $ˆ Namen aller Abhängigkeiten (hier: test.o func.o) Achtung: GNU-Erweiterung, nicht SUSv4-konform! test: test.o func.o $(CC) $(CFLAGS) $(LDFLAGS) -o $@ $^ c ce, js, az, jk SP2 (Ü2 | WS 2015) 2 Server-Sockets und Signale | 2.5 Makefiles – Teil 3 Explizite Regeln überschreiben die Pattern-Regeln test.o: test.c $(CC) $(CPPFLAGS) $(CFLAGS) -DXYZ -c $< c ce, js, az, jk 2–28 Agenda SP2 (Ü2 | WS 2015) 2 Server-Sockets und Signale | 2.5 Makefiles – Teil 3 2–29 Aufgabe 2: sister Einfacher HTTP-Webserver zum Ausliefern statischer HTML-Seiten innerhalb eines Verzeichnisbaums (WWW-Pfad) IPC-Schnittstelle: Server UNIX-Signale Signal-API von UNIX Einsammeln von Zombies Makefiles – Teil 3 Aufgabe 2: sister Gelerntes anwenden Abarbeitung der Anfragen erfolgt in eigenem Prozess (fork(2)) Modularer Aufbau (vgl. SP1#SS14 A/II 7) 22-ServerSockets_handout Wiederverwendung einzelner Module in Aufgabe 5: mother 22-ServerSockets_handout 2.1 2.2 2.3 2.4 2.5 2.6 2.7 c ce, js, az, jk SP2 (Ü2 | WS 2015) 2 Server-Sockets und Signale | 2.6 Aufgabe 2: sister 2–30 c ce, js, az, jk SP2 (Ü2 | WS 2015) 2 Server-Sockets und Signale | 2.6 Aufgabe 2: sister 2–31 Exkurs: modulare Softwareentwicklung in C Aufgabe 2: sister Aufgabe 2 Wiederholung: Ein Modul besteht aus ... Hauptmodul (sister.c) Öffentlicher Schnittstelle (Header-Datei) Konkreter Implementierung dieser Schnittstelle (C-Datei) Implementiert die main()-Funktion: Durch diese Trennung ist es möglich die Implementierung auszutauschen, ohne die Schnittstelle zu verändern Initialisierung des Verbindungs- und cmdline-Moduls Vorbereiten der Interprozesskommunikation Annehmen von Verbindungen Übergabe angenommener Verbindungen an das Verbindungsmodul Module, die die öffentliche Schnittstelle verwenden, müssen nicht angepasst werden, wenn deren konkrete Implementierung geändert wird 22-ServerSockets_handout 22-ServerSockets_handout Verbindungsmodul (connection-fork.c) c ce, js, az, jk SP2 (Ü2 | WS 2015) 2 Server-Sockets und Signale | 2.6 Aufgabe 2: sister Implementiert die Schnittstelle aus dem Header connection.h: Initialisierung des Anfragemoduls Erstellen eines Kindprozesses zur Abarbeitung der Anfrage Anmerkung: Entstandene Zombie-Prozesse müssen beseitigt werden! Weitergabe der Verbindung an das Anfragemodul c ce, js, az, jk 2–32 Aufgabe 2: sister SP2 (Ü2 | WS 2015) 2 Server-Sockets und Signale | 2.6 Aufgabe 2: sister 2–33 Agenda Anfragemodul (request-http.c) 2.1 2.2 2.3 2.4 2.5 2.6 2.7 Implementiert die Schnittstelle aus dem Header request.h: Einlesen und Auswerten der Anfragezeile Suchen der angeforderten Datei im WWW-Pfad ! Vorsicht: Anfragen auf Dateien jenseits des WWW-Pfades stellen ein Sicherheitsrisiko dar. Sie müssen erkannt und abgelehnt werden! Ausliefern der Datei IPC-Schnittstelle: Server UNIX-Signale Signal-API von UNIX Einsammeln von Zombies Makefiles – Teil 3 Aufgabe 2: sister Gelerntes anwenden cmdline: Schnittstelle zum Parsen der Befehlszeilenargumente i4httools: Hilfsfunktionen zum Implementieren eines HTTP-Servers c ce, js, az, jk SP2 (Ü2 | WS 2015) 2 Server-Sockets und Signale | 2.6 Aufgabe 2: sister 2–34 22-ServerSockets_handout 22-ServerSockets_handout Hilfsmodule (cmdline, i4httools) c ce, js, az, jk SP2 (Ü2 | WS 2015) 2 Server-Sockets und Signale | 2.7 Gelerntes anwenden 2–35 Aktive Mitarbeit! „Aufgabenstellung“ 22-ServerSockets_handout Programm schreiben, welches durch Ctrl-C nicht beendet werden kann c ce, js, az, jk SP2 (Ü2 | WS 2015) 2 Server-Sockets und Signale | 2.7 Gelerntes anwenden 2–36