Verteilte Systeme. Axel-Tobias Schreiner Fachbereich Mathematik-Informatik Universität Osnabrück

1 Verteilte Systeme Axel-Tobias Schreiner Fachbereich Mathematik-Informatik Universität Osnabrück Eine Einführung in praktische Client-Server Programmierung unter UNIX vor allem im Bereich der TCP/IP-Protokolle, mit der Tool-Command-Language (TCL) und mit C und Objective C. Dieser Band enthält Kopien der OH-Folien, die in der Vorlesung verwendet wurden. Diese Information steht außerdem auf NeXT-Systemen online zur Verfügung; sie ist in sich und mit der Systemdokumentation über Hypertext-Links verbunden und für den Librarian aufbereitet. Die Beispielprogramme werden maschinell aus diesem Text extrahiert. Der Band stellt kein komplettes Manuskript der Vorlesung dar. Zum Selbststudium müßten zusätzlich ein Buch über Client-Server-Programmierung sowie ein Teil der Systemdokumentation konsultiert werden; Kenntnisse von ANSI-C und Objective C werden vorausgesetzt. Inhalt 0 Einführung 1 1 Schichten 5 2 TCL 25 3 TCP-Programmierung 53 4 TCP-Programmierung mit Objective C 73 5 TCP-Tools für die Shell 93 6 Pseudo-Terminals 109 7 Datagramm-Sockets 117 8 Eine grafische Oberfläche 129 9 notes ein Beispiel für Groupware 139 10 Remote Procedure Calls mit rpcgen 155 11 Verteilte Objekte 177 12 Ein Web-Browser als Frontend 199 13 NFS 217

2 Kalender Oktober 10. Einführung. Schichten-Modell. telnet, traffic, netstat 00 01 12. Client/Server: Prozesse, Programme. TCL 01 02 17. TCP-Verbindungen. bind, accept, connect, echo, doecho 01 19. RPC. dp_makerpc*, Stubs, Sicherheit 01 24. RPC, schrittweiser Ablauf. Telefonbuch-Objekt 01 26. Verteilte Objekte: Telefonbuch, Portmapper 01 31. arp, ifconfig, rpcinfo, nfsstat, spray, netstat, snmp 01 November 2. TCL: Grundbegriffe, trace 02 7. TCL: Ausdrücke, string, Listen, Kontrollstrukturen 02 9. TCL: Prozeduren, Blockstruktur, exec, file, cat, return 02 14. TCL: info level, return. Sockets 02 03 16. [krank] 21. [Skalla, RZ] Routing und WAN-Anschluß 23. TCP-Programmierung in C 03 28. Klient mit select. Klassen für Sockets 03 04 30. Klassen für Sockets: Object, Address, Inet, Unix, Fd 04 Dezember 5. Socket, Tcp, Acceptor. TCP-Tools: tcp, tcpd, snoop 04 05 7. Implementierung der Shell-TCP-Tools. Pseudo-Terminals 05 06 12. Pseudo-Terminals, stty-modes. use-server, Parsierung 06 07 14. Datagramme. use-server und -Klient in TCL und C. 07 19. TK, grafische Oberfläche für use-klient 08 Januar 9. Client/Server-Prinzip bei X. use-oberfläche 08 11. use: Anschluß am Server, asynchrone/robuste Version 08 16. notes: Idee, Architektur, Parser, grafische Oberfläche 09 18. notes: Verbindung zum Server 09 23. XDR, RPC. xin, xout, Darstellung auf dem Netz. High-level. 10 25. rpcgen Prinzip und Sprache. mbox/mboxd. 10 30. Java. rpcgen: Dummy-Funktionen, Monolith, Klient. 10 Februar 1. rpcgen: mbox-funktionen. Verteilte Objekte: tel 10 11 6. leaky und tel. Protokolle für mbox. 11 8. mbox 11 13. httpd, HTML plus Objective C 12 15. NFS 13

3 Termine Vorlesung Dienstag, 10:15 31/449a Schreiner Donnerstag, 10:15 31/449a Übungen Freitag, 8:15 31/449a Gremeyer Freitag, 10:15 31/322 Sprechstunde Donnerstag ab 10:00 n.v. 31/321 Schreiner (2480, axel) 31/325 Gremeyer (2482, gremeyer) Literatur Diese Folien befinden sich als Dateien im Katalog../skript und gedruckt in der Lehrsammlung. Bitte nicht per Laserdrucker drucken. Es gibt heute sehr viele Bücher über UNIX, verteilte Systeme und Client-Server Programmierung. Manche behandeln die Protokolle, andere die Programmierung von Verbindungsmechanismen und wieder andere den Umgang mit Klienten. Die folgenden Bücher sind nützlich. Soweit vorhanden, befinden sie sich in der Lehrsammlung. Comer 0-13-474321-0 Internetworking with TCP/IP Comer/Stevens 0-13-465378-5... Design, Implementation, and Internals Comer/Stevens 0-13-020272-X... Client-Server Programming and Applications Kerninghan/Ritchie 3-446-15497-3 Programmieren in C Kernighan/Pike 3-446-14273-8 Der UNIX-Werkzeugkasten Ousterhout 0-201-63337-X Tcl and the Tk Toolkit Stevens 0-13-949876-1 UNIX Network Programming Stevens 0-201-63346-9 TCP/IP Illustrated, Vol. 1: The Protocols Wall/Schwartz 0-937175-64-1 Programming perl Welch 0-13-182007-9 Practical Programming in Tcl and Tk Einige meiner Beispiele habe ich in Artikeln in unix/mail behandelt. Die Manual-Seiten befinden sich online im Katalogbereich /NextLibrary/Documentation/ManPages und können mit dem Kommando NeXT mit dem Librarian betrachtet werden. man oder auf

4 leere Seite

5 1 Schichten Letztlich sollen Applikationen zusammenarbeiten. Die dazu nötige Software wird in Schichten aufgebaut, die von den elektrischen Aspekten bis zu den Anwendungsprogrammen reichen. Das sogenannte OSI-Modell hat sieben Schichten, bei der TCP/IP-Protokollfamilie unterscheidet man vier Schichten, die zum Teil mit OSI übereinstimmen: Application Presentation Session TFTP SNMP NFS NIS NSP portmapper RPC XDR FTP LPD SMTP TELNET Transport UDP TCP Network IP ICMP ARP RARP Data Link IEEE 802.3 Ethernet andere Physical

6 Klienten- und Serverprozesse Auf dem eigenen Rechner erfährt man Datum und Uhrzeit mit date: $ date Sat Apr 9 16:24:40 MET DST 1994 $ Wenn man zugreifen kann, erfährt man Datum und Uhrzeit von einem fremden Rechner etwa so: $ rsh linux -l axel date Sat Apr 9 15:37:35 GMT 1994 $ Mit rsh wird hier unter dem Benutzernamen axel auf dem Rechner linux das Kommando date ausgeführt. Dazu ist eine Anmeldung auf dem fremden Rechner nötig. Auch ohne Berechtigung funktioniert folgendes: $ telnet linux daytime Trying 131.173.160.252... Connected to linux. Escape character is ^]. Sat Apr 9 15:45:53 1994 Connection closed by foreign host. $ telnet linux daytime 2>/dev/null Connected to linux. Escape character is ^]. Sat Apr 9 15:51:57 1994 $ Mit telnet wird hier eine Verbindung zum Rechner linux und dort zum Port des daytime-service aufgebaut. Dieser Service liefert eine Zeile mit einem Datumstempel, die telnet dann ausgibt. In jedem Fall arbeiten ein Klient und ein Server zusammen: der Klientenprozeß, wie rsh oder telnet, wird vom Benutzer an einem Rechner aufgerufen und liefert die gewünschte Leistung. der Klient kontaktiert einen Service, wie shell oder daytime, auf einem (anderen) Rechner und läßt vom dafür zuständigen Serverprozeß, wie rshd oder inetd, die gewünschte Leistung erbringen. Die Programmierprobleme bestehen einerseits darin, daß der Klient und der Serverprozeß Verbindung aufnehmen müssen der Serverprozeß muß eigentlich existieren, bevor man mit ihm Verbindung aufnehmen kann und andererseits in der programmtechnischen Verpackung der Vorgänge.

7 Klienten- und Serverprogramme Da das Betriebssystem alle Peripheriegeräte verwaltet, braucht man letztlich (neue) Systemaufrufe, mit denen Prozesse auf verschiedenen Rechner Kontakt aufnehmen und Daten transferieren können. In C benötigt man reichlich verwickelte Strukturen. In TCL-DP sind die Abläufe prinzipiell gleich, aber durchschaubarer: {01/echo #!/usr/local/bin/dptcl -f # echo -- tcl-script for an echo client puts -nonewline "host: "; set host [gets stdin] puts -nonewline "port: "; set port [gets stdin] set data [lindex [dp_connect $host $port] 0] while {! [eof stdin] { puts $data [gets stdin] puts [gets $data] exit 0 { TCL ist eine Shell-artige Kommandosprache, TCL-DP enthält zusätzlich eingebaute Kommandos für Distributed Programming. Für den echo-klienten wesentlich ist, daß dp_connect eine Verbindung zu einem Rechner und einem Port (also einem File-Deskriptor bei einem Prozeß) aufbaut und als Resultat eine Liste liefert, deren erster Eintrag ein File-Deskriptor ist. echo kann so benutzt werden: $./echo host: linux port: 7 hi there, linux hi there, linux ^D $./echo host: localhost port: daytime Tue Apr 12 04:37:40 1994 ^C $

8 Ein eigener doecho-server muß vorher gestartet werden. Er kann ungefähr so programmiert werden: #!/usr/local/bin/dptcl -f # doecho -- tcl-script for an echo server set service [dp_connect -server 0] puts "echo server on port [lindex $service 1]" close stdout set call [lindex $service 0] set data [lindex [dp_accept $call] 0] catch { exit 0 while 1 { puts $data [gets $data] {01/doEcho { In dieser Form konstruiert dp_connect einen File-Deskriptor für einen Server und liefert als zweites Listenelement die vom System vergebene Port-Nummer. dp_accept nimmt den File-Deskriptor call und wartet, bis jemand anruft. Die davon resultierende Liste enthält als erstes Element dann den File-Deskriptor, über den Daten transferiert werden können. catch schnappt sich hier den Fehler, der beim Abbruch des echo-klienten ankommt. Das funktioniert dann etwa so: $ set `doecho &` $ echo "$@" echo server on port 2660 $./echo host: next port: 2660 hi there hi there ^D [1]+ Done doecho $ Über die Byte-Verbindung kann man nun Daten so zwischen Prozessen auf verschiedenen Rechnern austauschen, wie das auf einem Rechner mit (zwei!) Pipes möglich wäre. Es bleibt das Problem der Datenformate, Synchronisation, etc.

9 Klienten- und Serverprozeduren Remote Procedure Calls (RPC) sind eine höchst elegante Verpackung von Kommunikation über eine Byte-Verbindung. Abgesehen vom Aufwand der Einrichtung einer Verbindung hat der Klient den Eindruck, daß er lokale Prozeduren aufruft: #!/usr/local/bin/dptcl -f # rpc -- tcl-script to execute RPCs {01/rpc set server {; set host { # leere Liste proc server { { global server host if {$server == { { puts -nonewline "host: "; set host [gets stdin] puts -nonewline "port: "; set port [gets stdin] set server [dp_makerpcclient $host $port] return $server proc GetDate { { dp_rpc [server] GetDate proc GetUsers { { dp_rpc [server] GetUsers puts [GetDate] puts "$host:[getusers] user(s)" exit 0 { dp_makerpcclient baut eine Verbindung auf, über die mit dp_rpc ein Prozeduraufruf verschickt und Resultate empfangen werden können. Typischerweise verkleidet man die Remote Procedure mit einer gleichnamigen lokalen Prozedur.

10 #!/usr/local/bin/dptcl -f # dorpc -- tcl-script for an RPC server {01/doRpc puts "[pid] RPC server on port [dp_makerpcserver 0]" close stdout proc GetDate { { exec date # RPC: date proc GetUsers { { # RPC: numer of users exec who wc -l { Der Server ist in TCL-DP noch einfacher zu schreiben. dp_makerpcserver richtet die Verbindung ein und liefert die Port-Nummer. Im Server werden dann lokale Prozeduren per Namen für den Klienten ausgeführt. Die Prozeduren müssen natürlich geschlossen sein, das heißt, sie können nur auf globale Variablen im Server und auf Argumente vom Klienten zugreifen. Das funktioniert ungefähr so: $ set `dorpc &` $ echo "$@" 2008 RPC server on port 2672 $ rpc host: next port: 2672 Sat Apr 9 20:15:19 MET DST 1994 next: 7 user(s) $ kill $1 Bei korrekter Verpackung muß man die lokalen Prozeduren aus dem Server unverändert in den Klienten einfügen können, damit der Klient autark arbeiten kann. Eigentlich ist die Verpackung ideal aber wenn man beliebige Argumente über verschiedene Rechnerarchitekturen verschicken will, hat man zum Beispiel auch Probleme mit der Byte-Reihenfolge. Außerdem handelt man sich ein Sicherheitsproblem ein.

11 Verteilte Objekte Mit Prozeduren kann man ein primitives Telefonbuch in TCL so implementieren: set tel { {axel 2480 {bischof 2534 {gremeyer 2482 {jutta 2491 {gskalla 2486 {01/tel.tcl proc tel {name args { global tel set n [lsearch $tel "$name *"] if {$n >= 0 { return [lindex [lindex $tel $n] 1] if {[llength $args] { lappend tel [list $name [lindex $args 0]] return { Das Programm müßte man interaktiv verwenden, und es sammelt seine Daten nur während der Laufzeit in einer Liste von 2-elementigen Listen: $ dptcl % source tel.tcl % tel axel 2480 % tel gerhard % tel gerhard 2487 % tel gerhard 2487 %

12 Will man mehrere verschiedene Telefonbücher, muß man den Prozeduren das Telefonbuch als Argument geben. Man kann aber auch in TCL-DP so implementieren, daß man das Telefonbuch als Objekt ansieht, an das man die Anfragen in Form von Nachrichten schickt: {01/phoneBook.dp proc phonebook {book args { # constructor dp_objectcreateproc phonebook $book dp_objectslotset $book tel { {axel 2480 {bischof 2534 {gremeyer 2482 {jutta 2491 {gskalla 2486 eval $book configure $args; # fuer DP return $book proc phonebook.tel {book name args { # <book> tel <name> [number] set tel [dp_getf $book tel] set n [lsearch $tel "$name *"] if {$n >= 0 { return [lindex [lindex $tel $n] 1] if {[llength $args] { lappend tel [list $name [lindex $args 0]] dp_setf $book tel $tel return { Ein Objekt ist in TCL-DP eine Prozedur. Die Instanzenvariablen sind sogenannte Slots, auf die man mit entsprechenden Vokabeln eigentlich wie auf Strukturkomponenten zugreifen kann. Jetzt kann man mehrere Telefonbücher verwenden: $ dptcl % source phonebook.dp % phonebook inf inf % inf tel axel 2480 % inf tel gerda 2480 % inf tel gerda 2480 % phonebook math math % math tel gerda % math tel voges 2561 % inf tel voges %

13 Da man mit Objekten bereits über Nachrichten verkehrt, bietet sich an, Objekte auf verschiedene Rechner zu verteilen und die Nachrichten über RPC zu vermitteln. Wenn der Mechanismus entsprechend implementiert ist, sollte man zwischen lokalen und verteilten Objekten keinen Unterschied merken können. Bei TCL-DP benötigt die Klasse noch drei Methoden : {01/phoneBook.dp proc phonebook.configure {book args { # fuer DP eval dp_objectconfigure phonebook $book $args proc phonebook.slot-value {book slot { dp_objectslot $book $slot # fuer DP proc phonebook.destroy {book { # destructor dp_objectfree $book { Jetzt kann ein Serverprozeß ein Telefonbuch anlegen und auf Wunsch verteilen: {01/doTel #!/usr/local/bin/dptcl -f source phonebook.dp phonebook informatik puts "[pid] phonebook on port [dp_makerpcserver]" close stdout proc access { { global dp_rpcfile dp_distributeobject informatik $dp_rpcfile phonebook {

14 Ein Klient legt eine RPC-Verbindung an und bittet den Server durch Aufruf von access, ihm Zugriff auf das Telefonbuch zu geben. dp_makerpcclient verwendet dp_connect; ein leerer String wird als Namen des lokalen Rechners interpretiert. {01/tel #!/usr/local/bin/dptcl -f source phonebook.dp switch [llength $argv] { 2 { dp_rpc [dp_makerpcclient { [lindex $argv 0]] access puts [informatik tel [lindex $argv 1]] 3 { dp_rpc [dp_makerpcclient { [lindex $argv 0]] access informatik tel [lindex $argv 1] [lindex $argv 2] default { puts stderr "usage: tel port name \[number\]" exit 0 { Es geht hier nur um die Verpackung: entscheidend ist, daß nach dem Aufbau der Verbindung die Benutzung des verteilten Objekts informatik nicht von einer lokalen Benutzung zu unterscheiden ist das liegt an der Verwendung der besonderen Vokabeln dp_setf und dp_getf zum Zugriff auf die Slots. $ set `dotel &` $ echo "$@" 834 phonebook on port 2687 $ tel $5 axel 2480 $ tel $5 vornberger 2481 $ tel $5 vornberger 2481 $ kill $1

15 Portmapper Damit ein RPC-Klient seinen Server bequem finden kann, muß man natürlich Port und Rechner des Servers unsichtbar zur Verfügung stellen das ist die Aufgabe des portmapper, der an einer öffentlichen Adresse per RPC die Zugriffsinformation für RPC-Services liefert. {01/portMapper.dp # PMset <program> <host> <port> installs {<program> <host> <port> # PMset <program>?<host>? removes {<program> <host> * # PMfind <program> returns first {host port for <program> # PMfind <program> <host> returns {<host> port for <program> proc portmapper { { # client s connection global portmapper if {[llength $portmapper] > 1 { # connect upon first access set portmapper [eval dp_makerpcclient $portmapper] return $portmapper; # always return socket proc PMset {args { eval dp_rpc [portmapper] PMset $args proc PMfind {args { eval dp_rpc [portmapper] PMfind $args set portmapper {{ 12345; #!/usr/local/bin/dptcl -f # published {host port {01/doPortMapper source portmapper.dp set map [list [concat portmapper $portmapper]] dp_makerpcserver [lindex $portmapper 1] proc PMset {program {host * args { global map while {[set n [lsearch $map "$program $host *"]] >= 0 { set map [lreplace $map $n $n] if {[llength $args] { lappend map [list $program $host [lindex $args 0]] proc PMfind {prog {host * { global map if {[set n [lsearch $map "$prog $host *"]] >= 0 { return [lrange [lindex $map $n] 1 2] return {

16 Ähnlich wie im Telefonbuch speichern wir Programmname, Server-Adresse und Port als Liste in einer Liste map. Anders als das das offizielle Programm portmap tut, verwenden wir einen einzigen Portmapper im Netz, dessen Adresse zurest in der Variablen portmapper im Paket portmapper.dp gespeichert ist, das jeder Klient des Portmappers verwendet. Ein Portmapper-Klient wie unser Telefonbuch-Server meldet sich an, wenn er gestartet wird: {01/doTel2 #!/usr/local/bin/dptcl -f source portmapper.dp; # publish this host as server PMset phonebook [exec hostname] [dp_makerpcserver] dp_closerpc [portmapper] source phonebook.dp proc access {book { # [make and] distribute a phonebook global dp_rpcfile if {[info commands $book] == { { phonebook $book dp_distributeobject $book $dp_rpcfile phonebook { Mit access kann ein Telefonbuch-Klient den Server bitten, ein neues Telefonbuch anzulegen, falls es noch nicht existiert (es muß eine Prozedur sein!).

17 Ein Telefonbuch-Klient ist zuerst ein Portmapper-Klient und erfährt dort, wo er den Telefonbuch-Server finden kann: {01/tel2 #!/usr/local/bin/dptcl -f source portmapper.dp; set host [PMfind phonebook] dp_closerpc [portmapper] # find the phonebook server source phonebook.dp set books $argv; # skript arguments are phonebooks set server [eval dp_makerpcclient $host] foreach book $books { dp_rpc $server access $book while 1 { # cycle through phone books foreach book $books { while 1 { # ask for name?number? puts -nonewline "$book: "; set ask [gets stdin] if [eof stdin] { puts "" exit 0 dp_update if [llength $ask] { set answer [eval $book tel $ask] if {$answer!= "" { puts $answer else break { dp_update ist nötig, da sonst nur in der Hauptschleife implizit Anrufe verarbeitet werden. $ doportmapper & portmapper=$! $ dotel2 & tel2=$! $ tel2 inf math inf: voges inf: math: voges 2561 math: voges 2561 math: inf: voges inf: ^D $ kill $tel2 $portmapper

18 Network-Layer Es gibt verschiedene Kommandos, mit denen man sich Informationen auf dieser Ebene ansehen kann: $ arp -a linux (131.173.160.252) at 2:60:8c:3d:8d:3c esix (131.173.160.253) at 0:0:c0:20:72:2d arp zeigt und manipuliert die Informationen für ARP, also die Abbildung von IP- zu Ethernet-Adressen. $ ifconfig lo0 lo0: flags=69<up,loopback,notrailers,running> inet 127.0.0.1 netmask ff000000 $ ifconfig en0 en0: flags=63<up,broadcast,notrailers,running> inet 131.173.160.254 netmask fffff000 broadcast 131.173.175.255 ipconfig zeigt und manipuliert beim Systemstart die Einstellung der Interface-Struktur im Kern, also die Festlegung der eigenen IP-Adresse und die Parameter für eine Netz-Schnittstelle. $ rpcinfo -p esix program vers proto port 100000 3 udp 111 portmapper 100000 2 udp 111 portmapper 100000 3 tcp 111 portmapper 100000 2 tcp 111 portmapper 100003 2 udp 2049 nfs 100005 1 udp 1027 mountd 100005 1 tcp 1028 mountd rpcinfo zeigt, welche Programme beim offiziellen portmapper angemeldet sind, um zu zeigen, auf welchem Port sie RPC empfangen. Außerdem kann man die Prozedur 0 der Programme anrufen, um zu sehen, ob die Programme überhaupt antworten: $ rpcinfo -u esix 100003 program 100003 version 2 ready and waiting $ rpcinfo -t esix 100005 program 100005 version 1 ready and waiting $ rpcinfo -b 100005 1 131.173.160.254 next 131.173.160.254 next ^C

19 nfsstat zeigt speziell die Statistik der NFS-RPCs. $ nfsstat... Client nfs: calls badcalls nclget nclsleep 131 0 131 0 null getattr setattr root lookup readlink read 0 0% 38 29% 0 0% 0 0% 66 50% 0 0% 18 13% wrcache write create remove rename link symlink 0 0% 0 0% 0 0% 0 0% 0 0% 0 0% 0 0% mkdir rmdir readdir fsstat 0 0% 0 0% 4 3% 5 3% Mit spray kann man Erreichbarkeit und Antwortverhalten für RPCs untersuchen: $ spray next sending 1162 packets of lnth 86 to next... 248 packets (21.343%) dropped by next 605 packets/sec, 52033 bytes/sec

20 netstat zeigt verschiedene Netz-Datenstrukturen und Statistiken: $ netstat Active Internet connections Proto Recv-Q Send-Q Local Address Foreign Address (state) tcp 0 0 next.time esix.1304 TIME_WAIT tcp 0 0 next.1023 esix.login ESTABLISHED tcp 0 112 next.799 next.802 ESTABLISHED tcp 0 0 next.802 next.799 ESTABLISHED $ netstat 5 input (en0) output input (Total) output packets errs packets errs colls packets errs packets errs colls 51965 0 53531 211 0 105903 0 108410 836 0 0 0 0 0 0 0 0 0 0 0 27 0 26 0 0 76 0 74 0 0 318 0 320 0 0 637 0 641 0 0 ^C $ netstat -i Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll en0 1500 131.173.160 next 52352 0 53919 211 0 lo0 1536 loopback localhost 2013 0 2013 0 0 en0* 1500 none none 52352 0 53294 625 0 $ netstat -m 76/256 mbufs in use: 4 mbufs allocated to packet headers... $ netstat -s ip interrupt queue:... ip: 54228 total packets received 0 bad header checksums... icmp: 0 calls to icmp_error... tcp: 5571 packets sent 2398 data packets (531613 bytes) 10 data packets (9744 bytes) retransmitted... 5451 packets received 3128 acks (for 536117 bytes) 988 duplicate acks... udp: 0 incomplete headers 0 bad data length fields 0 bad checksums

21 Adressierung Im Netzwerk-Layer werden physikalische Adressen (zum Beispiel 6-Byte-Ethernet) mit logischen Adressen (4-Byte Internet) verknüpft. Mit Name-Service (NIS, DNS) kann man zu einem Rechnernamen die Internet-Adresse erfahren. Mit ARP kann man zu einer Internet- die Ethernet-Adresse erfahren. Internet-Adressen sind hierarchisch vergeben. Wenn ein Paket an eine bestimmte Internet-Adresse geschickt werden soll, zeigen die Route-Tabellen, wie man vorgehen muß. $ netstat -r Routing tables Destination Gateway Flags Refs Use Interface localhost localhost UH 2 490 lo0 131.173.160 next U 8 55705 en0 $ netstat -rn Routing tables Destination Gateway Flags Refs Use Interface 127.0.0.1 127.0.0.1 UH 2 1590 lo0 131.173.160 131.173.160.254 U 10 2957 en0 Die Zieladresse paßt entweder insgesamt oder in einem Netz-Teil (von links her) zu einer Destination; dann wird das Paket an die Ethernet-Adresse des zugehörigen Gateway geschickt. Normalerweise gibt es noch einen Eintrag default, an den die übrigen Pakete geschickt werden. Ob man einen Rechner erreicht, kann man mit ping prüfen. traceroute manipuliert die Pakete so, daß sie nur jeweils einen Rechner weit(er) kommen und zeigt, wie ein Rechner erreicht wird: $ ping esix PING esix: 56 data bytes 64 bytes from 131.173.160.253: icmp_seq=0. time=30. ms 64 bytes from 131.173.160.253: icmp_seq=1. time=2. ms ^C ----esix PING Statistics---- 2 packets transmitted, 2 packets received, 0% packet loss round-trip (ms) min/avg/max =/usr/local $ traceroute rzserv traceroute to rzserv (131.173.128.11), 30 hops max, 38 byte packets 1 rzrouter (131.173.160.254) 9 ms 3 ms 3 ms 2 neptun (131.173.17.254) 5 ms 4 ms 4 ms 3 rzserv (131.173.128.11) 7 ms 6 ms 6 ms

22 Netzwerk-Management snmp Bei NeXTSTEP 3.2 kann man in der NetInfo-Datenbasis etwa folgendes eintragen: locations/snmp/ enabled communities/ public/ yes networks 131.173.160 127 Jetzt wird beim Systemstart von /etc/rc aus das Programm /usr/etc/snmpd erfolgreich gestartet und folgende Anfragen sind möglich: $ snmp status localhost localhost (NeXT.1.1), Uptime: 0:13:03 NeXT Mach 3.2: Mon Oct 18 21:57:41 PDT 1993; root(rcbuilder):mk-149.30.15.obj~2/rc_m68k/release_m68k Name Speed Type Stat Ibyte Obyte Ierr Oerr Physical Address en0 other up 88KB 87KB <.1% <.1% 00:00:0F:00:B3:36 lo0 other up 1.6MB 1.6MB <.1% <.1% en0 10Mb ethernet up 88KB 87KB <.1% <.1% $ snmp localhost snmp> walk system system.sysdescr.0 NeXT Mach 3.2: Mon Oct 18 21:57:41 PDT 1993; root(rcbuilder):mk-149.30.15.obj~2/rc_m68k/release_m68k (OCTET STRING) system.sysobjectid.0.iso.org.dod.internet.private.enterprises.next.1.1 (OBJECT IDENTIFIER) system.sysuptime.0 0:02:41 (Timeticks, 16165) snmp> ^D $ snmpnetstat localhost Active Internet Connections Proto Recv-Q Send-Q Local Address Foreign Address (state) tcp 0 0 next.time esix.2413 TIMEWAIT tcp 0 0 next.700 next.703 ESTABLISHED tcp 0 0 next.700 next.761 ESTABLISHED tcp 0 0 next.703 next.700 ESTABLISHED tcp 0 0 next.761 next.700 ESTABLISHED Allgemein kann man in /etc/snmp.mib erahnen, welche Anfragen beantwortet werden: system interfaces at ip icmp tcp udp egp Grundsätzlich ist für SNMP eine erweiterbare, hierarchische Datenbasis vereinbart, in der Variablen einzeln oder in Gruppen abgefragt oder gesetzt werden können. NeXT verwendet PD-Software, um wenigstens die Netzaspekte abfragen zu lassen.

23 Monitore Für den Super-User gibt es verschiedene Programme, mit denen man den Netzverkehr auf der Basis von Internet-Adressen beobachten kann. etherfind und tcpdump wählen Pakete nach verschiedenen Kriterien und geben sie decodiert aus, traffic und etherman stellen den Verkehr grafisch dar. traffic

24 etherman

25 2 TCL John Ousterhouts Tool Command Language (TCL) ist eine zeilenorientierte, Shell-ähnliche Kommandosprache, deren Interpreter als C-Funktion in andere Programme eingebettet und mit neuen Kommandos in Form von C-Funktionen leicht erweitert werden kann. Sie kann deshalb als Standard und Basis für Kommandosprachen verwendet werden. Diese Beschreibung bezieht sich wie Ousterhouts Buch auf TCL Version 7.3 und TK Version 3.6. Lexikalische Aspekte Ein TCL-Skript besteht aus einem oder mehreren Kommandos, die durch Zeilentrenner oder Semikolon getrennt sind. Ein Kommentar reicht von # bis zum nächsten Zeilentrenner, aber nur, wenn # das erste Zeichen des ersten Worts eines Kommandos ist. Ein Kommando besteht aus einem oder mehreren Worten, die durch Leerzeichen oder Tabulatorzeichen getrennt sind. Jedes Zeichen eines TCL-Skripts wird bei jedem Durchgang durch den TCL-Interpreter exakt einmal bearbeitet, dabei wird exakt einmal ersetzt und/oder bewertet.

26 Ersatz für Variablen Mit $ wird der Wert einer Variablen abgerufen, die allerdings existieren muß: $ tclsh % set var 2 2 % expr $var*3 6 Der Variablenname ist fast beliebig, bei Bedarf kann er mit { abgetrennt werden. Der Wert einer Variablen ist immer eine Liste von Werten, die beim Ersatz jedoch eine Liste bleibt. Ein einzelner Wert ist immer ein String, der von Kommandos aber oft speziell interpretiert wird. Ersatz für Kommandos Mit [] wird der Wert des eingeschlossenen Kommandos abgerufen: % set 3 3 3 % set 66 [expr ${33*2] 66 Auch hier kann der Wert eine Liste sein, oder er kann Teil eines Worts werden: % set ab {a b a b % set c ${abc a bc % llength $c 2 Anscheinend wird von links her abgearbeitet man sollte also wohl eingebettete Nebeneffekte vermeiden: % set b 4 4 % set b [expr $b+ [set b 6]] 10 % Ersatz für Gegenschrägstrich Mit dem Gegenschrägstrich erreicht man dasselbe wie in C: Darstellen von Sonderzeichen; Verhindern, daß Zeichen wie ; $ [] { interpretiert werden, sowie Fortsetzen von Zeilen.

27 Zitieren mit Doppelanführungszeichen Innerhalb von Doppelanführungszeichen verlieren Leerzeichen, Tabulatorzeichen, Zeilentrenner und Semikolon ihre besondere Bedeutung, aber die drei Ersatz-Operationen werden nach wie vor vorgenommen. % puts "\$c enthaelt \"$c\"" $c enthaelt "a bc" Es entsteht allerdings eine Liste, deren Trennzeichen offenbar intern gespeichert werden: % set a "b c"; # mit tab b c % puts $a b c % llength $a 2 % puts "\$a enthaelt \"[lindex $a 0]\" und \"[lindex $a 1]\"" $a enthaelt "b" und "c" % set a "a b c" a b c % llength $a 3 % puts $a a b c % puts [lrange $a 1 2] b c Zitieren mit geschweiften Klammern Alles zwischen balancierten geschweiften Klammern wird nicht interpretiert, ausgenommen daß innere geschweifte Klammern gezählt werden, daß die Folge \{ weder gezählt noch verändert wird und daß fortgesetzte Zeilen bereits zusammengefügt werden: % puts {$a \{ \ b $a \{ b Aus dem Inhalt der geschweiften Klammern entsteht eine Liste, die dann oft als Folge von TCL-Kommandos interpretiert wird. % set body { puts $a puts $a % foreach a {1 2 3 $body 1 2 3

28 Worte Da jedes Zeichen nur einmal gelesen und ersetzt wird, sind die Argumente (Worte) der Kommandos leicht aus den Zwischenräumen im Quelltext ersichtlich: % set city "New York" New York % set bigcity New York wrong # args: should be "set varname?newvalue?" % set bigcity $city New York Wenn ein Wert eine Liste ist, die einzelne Argumente eines Kommandos werden sollen, kann man mit eval einen weiteren Durchgang durch den Interpreter einleiten: % eval set city "New York" wrong # args: should be "set varname?newvalue?" $ tee a.o b.o c.o < /dev/null $ tclsh % rm [glob *.o] rm: a.o b.o c.o: No such file or directory child process exited abnormally % eval rm [glob *.o] % exit $ ls *.o eval ist fast immer nötig, wenn eine variable Argumentliste mit $args übergeben werden soll oder wenn das Resultat einer glob-expansion einem Kommando übergeben wird. Außerdem kann man eine Art Zeiger auf Zeiger realisieren: % set g h h % set f g g % puts $f g % puts $$f $g % eval puts $$f h

29 Kommandos Das erste Wort eines Kommandos muß der Name einer internen oder definierten TCL-Prozedur sein. Für unbekannte Worte wird die Prozedur unknown aufgerufen, die beliebig definiert werden kann. Nach Voreinstellung werden auto-loading und auf der obersten Ebene bei interaktiver Benutzung auto-execute, history und Abkürzungen unterstützt siehe /usr/local/lib/tcl/init.tcl. auto-loading sucht auf den Pfaden in der Liste auto_path nach Dateien mit Namen tclindex, die mit dem Kommando auto_mkindex directory pattern erzeugt oder aktualisiert werden. Prozeduren, die von auto_mkindex in tclindex eingetragen wurden, werden beim ersten Zugriff automatisch gefunden und geladen. auto_execute führt ein UNIX-Kommando für ein unbekanntes TCL-Kommando so aus, als ob exec angegeben worden wäre, allerdings nur interaktiv auf der äußeren Ebene: % date Wed Apr 27 17:15:34 MET DST 1994 % foreach a {1 2 date Wed Apr 27 17:15:42 MET DST 1994 Wed Apr 27 17:15:42 MET DST 1994 % proc d { { date % d invalid command name "date" history ist ein Kommando, das von unknown mit Abkürzungen im Stil der Shells unterstützt wird: history history keep count history nextid history redo?event? history substitute old new?event? zeigt Liste legt Länge fest zeigt nächste Position führt nochmals aus ersetzt und führt nochmals aus!! history redo!event history redo event ^old^new history substitute old new