Die Präsentation wird geladen. Bitte warten

Die Präsentation wird geladen. Bitte warten

H. Krumm, RvS, Informatik IV, Uni Dortmund 1 Rechnernetze und verteilte Systeme (BSRvS II) Prof. Dr. Heiko Krumm FB Informatik, LS IV, AG RvS Universität.

Ähnliche Präsentationen


Präsentation zum Thema: "H. Krumm, RvS, Informatik IV, Uni Dortmund 1 Rechnernetze und verteilte Systeme (BSRvS II) Prof. Dr. Heiko Krumm FB Informatik, LS IV, AG RvS Universität."—  Präsentation transkript:

1 H. Krumm, RvS, Informatik IV, Uni Dortmund 1 Rechnernetze und verteilte Systeme (BSRvS II) Prof. Dr. Heiko Krumm FB Informatik, LS IV, AG RvS Universität Dortmund Computernetze und das Internet Anwendung Transport Vermittlung Verbindung Multimedia Sicherheit Netzmanagement Middleware Verteilte Algorithmen Anwendung Prinzipien WWW, FTP, Mail DNS TCP-, UDP-Sockets im Client/Server- Programm

2 H. Krumm, RvS, Informatik IV, Uni Dortmund 2 Netzanwendungen: Struktur Host 1Host 2Host n Netz- und Transport Anwendungs- prozess 1 Anwendungs- prozess 2 Anwendungs- prozess m Kommunikation (via TCP und UDP)

3 H. Krumm, RvS, Informatik IV, Uni Dortmund 3 Client/Server-Paradigma Viele Anwendungen bestehen aus zwei Teilen: Client & Server Client: Initiiert Kontakt mit dem Server Fordert einen Dienst vom Server an Bsp. Web: Client im Browser, Client im Mailsystem Server: Bietet dem Client Dienstleistungen an Bsp. Bietet Web-Seiten an, liefert s

4 H. Krumm, RvS, Informatik IV, Uni Dortmund 4 Peer-to-Peer-Paradigma Die Anwendungen bestehen aus gleichberechtigten Teilen: die Peers (teilweise auch Agenten genannt) Skalierbarkeit +Keine zentralen Funktionen benötigt -Verwaltung von vielen Peer-Peer- Assoziationen Peers und Client/Server Peers wirken für andere Peers als Server und umgekehrt

5 H. Krumm, RvS, Informatik IV, Uni Dortmund 5 Anwendungen und Anwendungsprotokolle Anwendung Anwendungsprozesse werden in Endsystemen (Hosts) ausgeführt. Sie tauschen Anwendunsnachrichten aus. Beispiele: , File Transfer, WWW Anwendungsprotokolle Legen Syntax und Semantik der Anwendungsnachrichten fest Legen Ablauf des Nachrichtenaustauschs fest

6 H. Krumm, RvS, Informatik IV, Uni Dortmund 6 Schnittstelle zum Transportsystem Ein Anwendungsprozess kommuniziert (sendet/empfängt) über das Netz durch eine Software-Schnittstelle ein so genanntes Socket Tür zum Netzwerk Kommunikation durch Abgabe bzw. Abholung von Nachrichten an der Tür Programmierschnittstelle: API (Application Programming Interface) u.U. Wahl-/Parametrierungsmöglichkeiten Wahl des Transportprotokolls Wahl einiger Parameter (z.B. Timeout, Puffergrößen)

7 H. Krumm, RvS, Informatik IV, Uni Dortmund 7 Adressierung Um Nachrichten einem Prozess zuzuordnen wird eine eindeutige Kennung/Adresse benötigt Jeder Host hat eine eindeutige IP-Adresse (IP-V4: 32Bit) Damit sind aber noch keine Prozesse adressierbar!! Paar ausIP-Adresse für den Rechner und Port-Nummer für die Anwendung Echo-Server: TCP- oder UDP-Port 7 HTTP-Server: TCP-Port 80 SMTP-Mail-Server: TCP-Port 25 POP3-Mail-Server: TCP-Port 110

8 H. Krumm, RvS, Informatik IV, Uni Dortmund 8 Anwendungsanforderungen an Transportdienst Zuverlässigkeit beim Datentransfer Einige Anwendungen erfordern hohe Zuverlässigkeit (z.B. Dateitransfer) andere können einen gewissen Datenverlust verkraften (z.B. Audio- Übertragungen) Zeitverhalten Einige Anwendungen verlangen die Einhaltung von Zeitschranken (z.B. Steuerungen, Spiele) andere verkraften auch längere Verzögerungen (z.B. , Dateitransfer)

9 H. Krumm, RvS, Informatik IV, Uni Dortmund 9 Anwendungsanforderungen an Transportdienst Bandbreite Einige Anwendungen benötigen eine gewisse minimale Bandbreite (z.B. Multimedia) andere (elastische) Anwendungen nutzen die Bandbreite, die verfügbar ist (z.B. Dateitransfer) Sicherheit Einige Anwendungen haben hohe Sicherheitsanforderungen (z.B. E-Banking) andere nutzen nur allgemein einsehbare Daten (z.B. Fernsehen über Internet) Interaktion mit anderen Anwendungen Manche Anwendungen sollen andere nicht beeinflussen (z.B. Monitoring)

10 H. Krumm, RvS, Informatik IV, Uni Dortmund 10 Internet – Transport: Dienste und Protokolle TCP verbindungsorientiert zuverlässiger Transport Flusskontrolle Überlastkontrolle kein Timing keine garantierte Bandbreite UDP nicht verbindungsorientiert unzuverlässiger Transport keine Fluss- und Überlastkontrolle kein Timing keine garantierte Bandbreite

11 H. Krumm, RvS, Informatik IV, Uni Dortmund 11 WWW: World Wide Web Browser WWW- Server HTTP-Kommunikation TCP Internet HTTP: Hypertext-Transfer-Protocoll Client-Server Client: Browser fordert WWW-Objekte an, empfängt sie und stellt sie dar Server: WWW-Server sendet entsprechende Objekte HTTP/1.0: RFC 1945 HTTP/1.1: RFC 2616 benutzt TCP Client iniziiert TCP-Verbindung zum Server Server akzeptiert Verbindung HTTP-Pakete werden ausgetauscht TCP-Verbindung wird beendet zustandlos: Server speichert keine Informationen über vorangegangene Verbindungen.

12 H. Krumm, RvS, Informatik IV, Uni Dortmund 12 WWW: HTTP Browser WWW- Server HTTP-Kommunikation TCP Internet Nonpersistent-HTTP Maximal ein Objekt kann pro Verbindung übertragen werden. HTTP/1.0 benutzt Nonpersistent-HTTP. Persistent-HTTP Mehrere Objekte können pro Verbindung übertragen werden. Persistent-HTTP ohne Pipelining Der Client fordert erst ein neues Objekt an, nachdem das vorangehende empfangen wurde. Persistent HTTP mit Pipelining Der Client fordert ein neues Objekt an, sobald er auf eine Referenz stößt. HTTP/1.1 benutzt Persistent-HTTP mit Pipelining im Default-Modus

13 H. Krumm, RvS, Informatik IV, Uni Dortmund 13 WWW: HTTP-PDUs Browser WWW- Server HTTP-Kommunikation TCP Internet Simple Request METHOD URI Full Request METHOD URI HTTP/1.1 Header-Field-Name : value … Header-F-ield-Name : value MIME-conform Body Nachrichten sind Request-Nachrichten oder Response-Nachrichten METHOD z.B. GET, POST,..

14 H. Krumm, RvS, Informatik IV, Uni Dortmund 14 WWW: HTTP-PDUs Browser WWW- Server HTTP-Kommunikation TCP Internet Response HTTP/1.1 Status-Code Reason-Line Header-Field-Name : value MIME-conform Body Response-Status-Codes 200 OK404 Not Found 301 Moved Permanently505 HTTP Version Not Supported 400 Bad request

15 H. Krumm, RvS, Informatik IV, Uni Dortmund 15 WWW: HTTP - Operationen GET-Methode: Fordert das Objekt mit gegebener URL an ls4com2> telnet ls4-www.cs.uni-dortmund.de 80 Trying Connected to willi. Escape character with´^]´. GET

16 H. Krumm, RvS, Informatik IV, Uni Dortmund 16 WWW: Caching Laden von Seiten kann aufwändig/langwierig sein Caching im Browser Caching im Proxy- Server

17 H. Krumm, RvS, Informatik IV, Uni Dortmund 17 WWW: Conditional GET Ziel: Sende das angeforderte Objekt nicht, wenn der Client bereits eine aktuelle Version im Cache hat Client (u.U. Proxy) sendet das Datum seiner Kopie mit (if-modified-since) Server schickt das angeforderte Objekt nur, wenn eine neue Version vorhanden

18 H. Krumm, RvS, Informatik IV, Uni Dortmund 18 WWW: Authentifikation und Autorisierung Authentifikation Client gibt Id an und Beweis, dafür, dass er dies auch ist. Autorisierung Zugriff für Client nur im Rahmen der ihm zugewiesenen Privilegien Üblicher Ansatz: Benutzername, Password oder IP-Adresse Zustandslos: Client muss Autorisierung in jeder Anfrage präsentieren Autorisierung im Header Ohne Autorisierung keine Zugriff Vorsicht: Benutzername und Password im Browser-Cache!

19 H. Krumm, RvS, Informatik IV, Uni Dortmund 19 WWW: Zustandsspeicherung mit Cookies Viele Web-Seiten nutzen Cookies Basiskomponenten 1.Cookie-Zeile im Header der HTTP-Response Nachricht 2.Cookie-Zeile in der HTTP- Request Nachricht 3.Cookie-Datei auf dem Benutzerrechner, vom Browser verwaltet 4.Datenbank mit Cookies auf Server-Seite Beispiel: Susan nutzt das Internet von ihrem PC Sie ruft eine e-Commerce Seite erstmals auf Es wird ein Cookie mit einer eindeutigen ID generiert und auf Susans Rechner und in der Datenbank gespeichert

20 H. Krumm, RvS, Informatik IV, Uni Dortmund 20 WWW: Zustandsspeicherung mit Cookies

21 H. Krumm, RvS, Informatik IV, Uni Dortmund 21 WWW: Zustandsspeicherung mit Cookies Vorteile der Cookies Autorisierung Einkaufskarten (Speichern von Käufen, Bezahlung, …) Empfehlungen Zustand einer Benutzersitzung Die andere Seite der Cookies Cookies übermitteln Informationen Bei jedem neuen Zugriff kann die vorhandene Information ergänzt werden Suchmaschinen nutzen Cookies um über Nutzer zu lernen Informationen können an Dritte weitergegeben werden

22 H. Krumm, RvS, Informatik IV, Uni Dortmund 22 FTP: Internet File Transfer Protocol Aufgabe: Übertragung von Dateien von / zu einem entfernten Rechner Client/Server Modell Client auf Nutzerseite initiiert die Übertragung Server auf dem Host führt Übertragung aus RFC 959 und Port 21 auf dem Server

23 H. Krumm, RvS, Informatik IV, Uni Dortmund 23 FTP: Separate Kontroll- und Datenverbindungen FTP Client ruft FTP Server über Port 21 auf und spezifiziert TCP als Transportprotokoll Client autorisiert sich über die Kontrollverbindung Client kann sich die Verzeichnisse des Servers mittels der Kontrollkommandos ansehen Dateitransfer führt zur Öffnung einer TCP- Datenverbindung Nach dem Transfer schließt der Server die Datenverbindung Server öffnet eine neue Datenverbindung zur Übertragung der nächsten Datei Server speichert den Zustand des Clients (Verzeichnis, Authentifizierung) FTP sendet Kontrollinformation separat (out of band) im Gegensatz zu HTTP (in band)

24 H. Krumm, RvS, Informatik IV, Uni Dortmund 24 FTP: Kommandos und Antworten Einige Kommandos Nach dem Aufru ftp muss das Password eingegeben werden binary setzt den Übertragungsmodus auf binär (statt ASCII) ls listet das entfernte Verzeichnis put überträgt eine Datei zum entfernten Rechner get überträgt eine Datei vom entfernten Rechner Einige Rückgabewerte Jedes Kommando wird vom Server per Reply beantwortet Verwendete Statuscodes: 331 Username ok, password required 125 Data connection already open; transfer starting 425 cant open data connection 452 error writing file FTP ist altes Protokoll und hat schwerwiegende Sicherheitsmängel (z.B. unverschlüsselte Passwortübertragung, unverschlüsselte Dateiübertragung)

25 H. Krumm, RvS, Informatik IV, Uni Dortmund 25 Message Handling System Message Transfer System User User- Agent User- Agent User- Agent Message- Transfer- Agent User User- Agent User User- Agent User User- Agent Message- Transfer- Agent Message- Transfer- Agent SMTP Pop / IMAP lokale Interaktion SMTP

26 H. Krumm, RvS, Informatik IV, Uni Dortmund 26 Protokolle SMTP: Simple Mail Transfer Protocol [RFC 2821] Benutzt TCP, um s vom Sender (Mail Server des Senders) zum Empfänger (Mail Server des Empfängers) zu transferieren 3 Phasen Handshake Nachrichtentransfer Beenden der Verbindung 7-bit ASCII-Format zeilenweise organisiert Empfang von s Mail-Server speichert empfangene s User-Agenten greifen auf die s zu, durch POP: Post Office Protocol Autorisierung und Download IMAP: Internet Mail Access Protocol komplexer und variantenreicher

27 H. Krumm, RvS, Informatik IV, Uni Dortmund 27 Mail-Format Umschlag (Envelope) FROM: TO: SUBJECT: Leerzeile Inhalt (Body) Textzeile. Plain: ASCII-Zeilen Subject: is this your picture? From: "Adele Krause" Date: Thu, 09 Sep :18: To: I think this is your picture...

28 H. Krumm, RvS, Informatik IV, Uni Dortmund 28 MIME – Multimedia Mail Extensions Multimedia-Daten oder auch kodierte Dateien können nicht direkt per verschickt werden, da sie nicht ASCII-kodiert sind Lösung MIME-Format Beim Sender Daten in ASCII kodieren MIME Header hinzufügen, in welchem das Dateiformat angegeben ist (z.B. jpeg, word, gif, mpeg, plain) Beim Empfänger Interpretation des MIME-headers Dekodierung des ASCII-Textes Aufruf des zugehörigen Programms zum Anzeigen der Daten

29 H. Krumm, RvS, Informatik IV, Uni Dortmund 29 MIME – Multimedia Mail Extensions From: Frank Thorsten Breuer MIME-Version: 1.0 To: Subject: MIME-Demo Content-Type: multipart/mixed; boundary=" E59DCA CDB5F" Dies ist eine mehrteilige Nachricht im MIME-Format E59DCA CDB5F Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dies ist eine Multipart- . Der Text-Teil hat eine Zeile E59DCA CDB5F Content-Type: image/jpeg; name="inpud.jpg" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="inpud.jpg" /9j/4AAQSkZJRgABAQEAXwBfAAD//gAcU29mdHdhcmU6IE1pY3Jvc29mdCBPZmZpY2X/2wBD 6zX4R/UvpID0Ai8/+s1+Ef1L6Ses1+Ef1L6SA9AIvP8A6zX4R/UvpJ6zX4R/UvpID//Z E59DCA CDB5F--

30 H. Krumm, RvS, Informatik IV, Uni Dortmund 30 DNS: Domain Name System ls4-www.cs.uni-dortmund.de [129,217,16.36] Menschen werden durch mehrere Identifikatoren identifizierbar: SSN, Name, Pass, … Internet Hosts oder Router: IP-Adresse (32 Bit) – Teil jedes Datagramms Name gaia.cs.umass.edu wird von Menschen genutzt Abbildung Name IP-Adresse nötig Domain Name System Verteilte Datenbank implementiert eine Hierarchie von Name-Servern Protokoll der Anwendungsschicht zur Übersetzung Name IP Adresse Zentraler Dienst des Internets auf der Anwendungsebene realisiert

31 H. Krumm, RvS, Informatik IV, Uni Dortmund 31 DNS: Domänen-Hierarchie ls4-www.cs.uni-dortmund.de [ ] DNS Namen werden von rechts nach links abgearbeitet Namenshierarchie kann als Baum visualisiert werden Blätter sind Rechnernamen Innere Knoten gehören zu Domains

32 H. Krumm, RvS, Informatik IV, Uni Dortmund 32 DNS: Nameserver-Hierarchie Warum kein zentrales DNS? Zentraler Ausfallpunkt Großes Verkehrsaufkommen Weit entfernte Datenbank Schlechte Wartbarkeit Im DNS hat kein Server alle Abbildungen von Namen auf IP-Adressen Lokale Name-Server Gehören zu einem ISP (local (default) name server) Jede Anfrage wird erst zum lokalen Server geleitet Root Name-Server Einige wenige meist in den USA, empfangen Anfragen von lokalen Name-Servern Autoritative Name-Server Jeder Host gehört zu einem autoritativen Name-Server, der seine Adresse verbindlich speichert Antwortet auf Anfragen bzgl. zugehöriger Hosts

33 H. Krumm, RvS, Informatik IV, Uni Dortmund 33 DNS: Root Name Server Werden von lokalen Name-Servern kontaktiert, wenn diese eine Adresse/einen Namen nicht auflösen können Root Name-Server (13 weltweit) fragen den zugehörigen autorativen Name-Server, falls sie die Adresse nicht kennen erhalten von diesem die Abbildung und leiten sie an den lokalen Name-Server weiter

34 H. Krumm, RvS, Informatik IV, Uni Dortmund 34 DNS: Einfaches Beispiel Ablauf einer Anfrage von surf.eurecom.fr nach der Adresse von gaia.cs.umass.edu 1.Nachfrage beim lokalen Name- Server dns.eurecom.fr 2.dns.eurecom.fr kontaktiert den Root-Name-Server (falls notwendig) 3.Root-Name-Server kontaktiert den autoritativen Name-Server (falls notwendig) 4.Antwort an Root 5.Antwort an eurecom 6.Antwort an surf

35 H. Krumm, RvS, Informatik IV, Uni Dortmund 35 DNS: Einfaches Beispiel - Variante Root Name-Server kennt u.U. den richtigen autoritativen Name-Server nicht fragt dann bei einem intermediate Name- Server, um den autorativen Name- Server zu finden

36 H. Krumm, RvS, Informatik IV, Uni Dortmund 36 DNS: Anfrage-Ketten Rekursive Anfrage Angefragte Name-Server ist für die Auflösung der Adresse verantwortlich Dies kann zu zahlreichen weiteren Anfragen und hoher Last führen Iterative Anfrage Angefragter Server antwortet mit der Adresse des nächsten Name-Servers Fragender Server kontaktiert direkt diesen Server

37 H. Krumm, RvS, Informatik IV, Uni Dortmund 37 DNS: Caching und Aktualisierung Nachdem ein Name-Server eine Abbildung Name IP-Adresse erhalten hat, speichert er diese im Cache Einträge im Cache, die nicht nachgefragt wurden, werden nach einer Zeitspanne wieder gelöscht Struktur der Einträge (Name, Wert, Typ, TTL) Typ A Name IP-Adresse beschreiben die Abbildung, Typ NS Name beschreibt eine Domain und IP-Adresse die Adresse des autorativen Servers Typ CNAME Name ist ein Alias-Name und Wert der vollständige Name Typ MX Name ist ein Alias-Name für einen Mail-Server und Wert ist der vollständige Name TTL (time to live)

38 H. Krumm, RvS, Informatik IV, Uni Dortmund 38 Socket-Programmierung: Kommunikations-API Socket API Eingeführt für BSD4.1 UNIX, 1981 Sockets werden von Anwendungsprogrammen erzeugt, genutzt und abschließend freigegeben API: erlaubt die Wahl eines Transportprotokolls und das Setzen einiger Parameter, i.e. UDP: Unzuverlässige Datagramme TCP: Zuverlässige Byteströme

39 H. Krumm, RvS, Informatik IV, Uni Dortmund 39 Sockets Socket:Implementierungsobjekt Socket-Operationen:Verwaltung, Ein- und Ausgabe zum Netz

40 H. Krumm, RvS, Informatik IV, Uni Dortmund 40 Sockets SAP (Service Access Point) und CEP (Connection Endpoint): Elemente der logischen Architektur Sockets:Elemente der Implementierung, Programmschnittstellen-Elemente zum Kommunikationssystem, implementieren SAPs und CEPs; Netz-E/A = Socket-E/A ähnlich Datei-E/A Socket hat Filedeskriptornummer (Socket-ID ist FD) ClientServer Transportdienst logisch SAPCEP Client- prozess Server- prozess Transportdienst- implementierung Implementierung Socket als CEP Socket als SAP mit fester Server-Portnummer Socket als SAP und CEP

41 H. Krumm, RvS, Informatik IV, Uni Dortmund 41 TCP-Sockets: Client und Server Client initiiert den Verbindungsaufbau Server-Prozess muss dazu laufen Server muss einen Socket generiert haben Client muss Server-Adresse kennen (IP-Adresse, Portnr.) Generiert einen TCP-Socket Spezifiziert die IP-Adresse und die Port-Nummer des Server-Sockets zur Kontaktaufnahme Client fordert den Aufbau einer TCP- Verbindung an Mit dem Verbindungsaufbau generiert der Server einen neuen Socket zur Kommunikation mit dem Client (so kann Server nebenläufig mit mehreren Clients kommunizieren) Anwendungssicht: TCP bietet eine zuverlässige, reihenfolgentreue Verbindung

42 H. Krumm, RvS, Informatik IV, Uni Dortmund 42 AP2 readwrite TCP-Sockets: Anwendungssicht auf TCP-Verbindung AP1 read 1 Byte-Queue je Richtung (FIFO, zuverlässig) ganz offene TCP-Verbindung: beide Richtungen offen write Socket (CEP) 1 Bytestrom je Richtung

43 H. Krumm, RvS, Informatik IV, Uni Dortmund 43 Auf Server-Seite: socket(), erzeugt einen Socket und liefert die Socket-ID für den Server bind(), bindet den Server-Socket an die IP-Adresse und Port-Nummer des Servers listen(), Server-Socket wird als Responder-Socket beim Betriebssystem angemeldet accept(), warten auf neue Verbindung, liefert CEP-Socket send(), schreiben in den CEP-Socket revc(), lesen aus dem CEP-Socket close(), schließt die Richtung ServerClient der Verbindung TCP-Socket - API Auf Client-Seite: socket(), erzeugt einen Socket und liefert die Socket-ID für den Client connect(), sendet einen Connect- Request an die angegebene IP-Adr. (existiert nicht in Java!) send(), schreibt Daten in den Client-Socket (Senden zum Server) revc(), liest Daten aus dem Client-Socket (Empfangen vom Server) close(), schließt die Richtung ClientServer der Verbindung

44 H. Krumm, RvS, Informatik IV, Uni Dortmund 44 Client/Server: TCP - Interaktion Server-Socket: SAP Verbindungs- endpunkt: CEP Client-Socket: SAP+CEP

45 H. Krumm, RvS, Informatik IV, Uni Dortmund 45 UDP-Sockets UDP nutzt keine Verbindung zwischen Client und Server Kein Verbindungsauf- und Abbau (Connect/Accept, Close) Sender muss mit jedem Senden die IP-Adresse und Port-Nummer des Empfängers angeben Empfänger erfährt die IP-Adresse und Port-Nummer des Senders aus dem empfangenen Datagramm Daten via UDP können in falscher Reihenfolge ankommen oder ohne Anzeige verloren gehen Anwendungssicht: UDP bietet nur eine unzuverlässige Nachrichtenübertragung

46 H. Krumm, RvS, Informatik IV, Uni Dortmund 46 UDP-Socket - API Auf Client-Seite: socket(), erzeugt einen Socket und liefert die Socket-ID für den Client sendto(), schreibt in den Client- Socket unter Angabe der IP- Adresse und Port-Nummer des gewünschten Empfängers revcfrom(), liest aus dem Client-Socket inkl. IP-Adresse und Port-Nummer des Senders bind(), bindet den Socket an eine gewünschte Port-Nummer (optional) Auf Server-Seite: socket(), erzeugt einen Socket und liefert die Socket-ID für den Server bind(), bindet den Server-Socket an die IP-Adresse und Port-Nummer des Servers sendto(), schreibt in den Server- Socket unter Angabe der IP-Adresse und Port-Nummer des gewünschten Empfängers revcfrom(), liest aus dem Server- Socket inkl. IP-Adresse und Port- Nummer des Senders

47 H. Krumm, RvS, Informatik IV, Uni Dortmund 47 Client/Server: UDP - Interaktion


Herunterladen ppt "H. Krumm, RvS, Informatik IV, Uni Dortmund 1 Rechnernetze und verteilte Systeme (BSRvS II) Prof. Dr. Heiko Krumm FB Informatik, LS IV, AG RvS Universität."

Ähnliche Präsentationen


Google-Anzeigen