1. Internet-Grundlagen und Überblickswissen OSI –Modell (1)

1. Internet-Grundlagen und Überblickswissen
 OSI 7-Schichtenmodell
 Verteilte Anwendungen,
allgemeines Client-Server-Modell
 Sockets, benannte Pipes und RPC
als Kommunikationsmodelle auf der IP-Schicht
 WWW – ein klassisches Client-Server-System (C/S) mit
HTTP als zustandsloses Verbindungsprotokoll in der
Anwendungsschicht
 Architektur von Web-Applikationen
 Möglichkeiten des clientseitigen Scriptings
 Möglichkeiten des serverseitigen Scriptings
 Multi-Tier-Architekturen von Web-Applikationen
Peter Sobe
Internettechnologien
1
OSI –Modell (1)
OSI-Referenzmodell:
Open Systems Interconnection Reference Model
Eingeführt 1983 von der ISO (Internationale
Normungsorganisation)
Zu dieser Zeit existierte TCP/IP bereits, das bis dahin
durch ein 4-Schichtenmodell erklärt wurde.
Ein Schichtenmodell ordnet verschiedenen NetzwerkTechniken jeweils eine Schicht zu. Die oberen Schichten
bauen auf der Funktionalität und den Schnittstellen der
unteren Schichten auf.
Peter Sobe
Internettechnologien
2
OSI –Modell (2)
Peter Sobe
Internettechnologien
3
OSI –Modell (3)
1: Bitübertragungsschicht – umfasst mechanische und
elektrische Elemente, das Übertragungsmedium und die
übertragungstechnischen Verfahren
2: Sicherungsschicht - Techniken zum Zugriff auf das
Übertragungsmedium, Datenflusskontrolle,
Fehlererkennung und Fehlerkorrektur
3: Vermittlungsschicht – Weiterleitung der
Datenübertragung über ein Kommunikationsnetz aus
mehreren Leitungssegmenten und Schaltstellen (Router)
4: Transportschicht – Ende-zu-Ende-Steuerung für
Datenströme
Peter Sobe
Internettechnologien
4
OSI –Modell (4)
5: Sitzungsschicht – synchronisierter Datenaustausch, weitere
Mechanismen wie z.B. RPC (Remote Procedure Call)
6: Darstellungsschicht – Herstellung einer
systemunabhängigen Darstellung der Daten,
ggf. Anpassung an verschiedene Darstellungsformate,
Zusätzlich: Datenkompression und Verschlüsselung
7: Anwendungsschicht – verschiedene Anwendungen, wie z.B.
Dateitransfer (SCP,FTP), Email, Webserver/Webbrowser
Peter Sobe
Internettechnologien
5
Einfacheres 4-Schichten-Modell (1)
Angelehnt an TCP/IP mit Internetschicht und Transportschicht
logischer Datenaustausch
Rechner 1
4
3
2
1
Anwendungsschicht
Transportschicht
Internetschicht
Rechner 2
http, ftp,
smtp, pop,
....
4
TCP
3
IP
2
1
Netzzugangsschicht
Anwendungsschicht
Transportschicht
Internetschicht
http, ftp,
smtp, pop,
....
TCP
IP
Netzzugangsschicht
realer Datenaustausch mit elektr.
Signalen
Peter Sobe
Internettechnologien
6
Einfacheres 4-Schichten-Modell (2)
Die beiden entscheidenden Schnittstellen, die Internetschicht
und die Transportschicht gut zu erkennen. Darüber liegt dann
die Anwendungsschicht, die die bekannten Internetdienste
enthält.
Der Name Internettechnologien kommt natürlich von der
Internetschicht. Man rechnet alles, was direkt auf diese
Internetschicht aufsetzt oder darüber liegt zu den
Internettechnologien. In der Literatur ist oft der Begriff WebTechnologie zu finden.
Peter Sobe
Internettechnologien
7
Client-Server-Modell –
Grundlage für die Internettechnologien
Wir betrachten zwei Rechner, die über das Netz verbunden sind.
Auf jedem Rechner läuft eine Anwendung, die beide miteinander
kooperieren, d.h. Daten austauschen.
Eine Anwendung wird als Server bezeichnet, die andere als
Client. Der Server stellt einen Dienst bereit und der Client ist die
Anwendung, die den Dienst in Anspruch nimmt.
Gefordert:
Ein Protokoll, das bestimmt wie der Datenaustausch zwischen
Server und Client funktioniert.
 Zeitliche Abfolge der Nachrichten und Regeln für Client
und Server
 Inhalt und Format der einzelnen Nachrichten
Peter Sobe
Internettechnologien
8
Client-Server-Modell –
Grundlage für die Internettechnologien
Werden im Internet Dienste von allgemeinem Interesse zur
Verfügung gestellt, müssen die Protokolle publiziert werden.
Oft werden dann auch Clients zur Verfügung gestellt, über die
solche Dienste genutzt werden können.
Zugangspunkte für Dienste (Adressen) müssen bekannt sein:
 Adresse des Servers (IP-Adresse)
 Unterscheidung der Zugangspunkte, wenn ein Server mehr
als einen Dienst bereit stellt (Port)
Die Adressierung ist Aufgabe der
 Vermittlungsschicht (Schicht 3, Network Layer) im OSI-Modell
 IP-Schicht (Internet Schicht) im TCP/IP-Schichtenmodell
Peter Sobe
Internettechnologien
9
Client-Server-Modell –
Adressierung der Server
Ein Dienst wird mit einer so genannten Portnummer versehen.
Portnummer und Rechner (IP-Nummer) bilden ein Socket und
sind im Internet eindeutig definiert. Damit gelingt es beim
Datenversand im Internet durch TCP das Ziel der Daten, den
Server, eindeutig zu adressieren.
Server: www.htw-dresden.de IP-V4-Adr.: 141.56.16.49
WWW-Server an Port 80
FTP-Server an Ports 20,21
Peter Sobe
Internettechnologien
10
Client-Server-Modell –
Adressierung der Clients
Ein Client wird durch seine IP-Adresse ausgewiesen.
Jede Verbindung wird clientseitig einem anderem Port zugeordnet.
Damit kann der Client mehrere Verbindungen gleichzeitig aufrecht
erhalten.
Ports für Client-Prozesse werden durch Portmapper dynamisch
vergeben. Der Client-Port wird dem Server beim Verbindungsaufbau mitgeteilt.
Eine TCP-Verbindung (Socket-Verbindung) ist demnach durch
das 4-Tupel
(Server-IP-Addr, Server_Port, Client-IP-Addr, Client-Port)
gekennzeichnet.
Peter Sobe
Internettechnologien
11
Client-Server-Modell –
Szenarien (1)
Ein Server, mehrere Clients:
Clients
C1-IP-Adr,
C1-Port
Server
Server-IP-Adr,
Server-Port
C2-IP-Adr,
C2-Port
C3-IP-Adr,
C3-Port
Wenn Clients auf unterschiedlichen Rechnern laufen, dann
unterscheiden sich C1-IP-Adr, C2-IP-Adr und C3-IP-Adr.
Wenn Clients auf dem gleichen Rechner laufen (z.B. mehrere
Nutzer), dann unterscheiden sich ihre Port-Nummern,
z.B. C2-Port ≠ C1-Port
Peter Sobe
Internettechnologien
12
Client-Server-Modell –
Szenarien (2)
Ein Client, mehrere Server:
Server
Client
S1-IP-Adr,
S1-Port
Client-IP-Adr,
Client-Port
S2-IP-Adr,
S2-Port
Wenn Server auf unterschiedlichen Rechnern laufen, dann
unterscheiden sich S1-IP-Adr und S2-IP-Adr.
Wenn verschiedene Server auf dem gleichen Rechner laufen, dann
unterscheiden sich ihre Port-Nummern, z.B. S2-Port ≠ S1-Port.
→ Nachrichten unterschiedlicher Verbindungen sind immer
unterscheidbar.
Peter Sobe
Internettechnologien
13
TCP und UDP (1)
TCP (Transmission Control Protocol) –
Verbindungsorientiertes Protokoll aus OSI Schicht 4
 setzt Adressierung und Paket-Vermittlung voraus (IP)
 arbeitet intern wie dargestellte Socket- und PipeKommunikation
 TCP garantiert Reihenfolge der Daten und Fehlerfreiheit – bei
verlorenen Paketen werden diese wiederholt übertragen
 Auf TCP bauen viele Internetdienste auf, z.B. HTTP, FTP
Peter Sobe
Internettechnologien
14
TCP und UDP (2)
UDP (User Datagram Protocol) ist das verbindungslose
Pendant zu TCP. Das verbindungslose UDP kann schneller
sein.
 setzt Adressierung und Paket-Vermittlung voraus (IP)
 einzelne Pakete werden übertragen, ohne explizite
Verbindung
 keine Reihenfolgegarantie
 Pakete können verloren gehen
 einige Dienste, wie z.B. Audio-Streaming verwenden UDP
Peter Sobe
Internettechnologien
15
Client-Server-Kommunikation –
per Socket-Verbindung (1)
Eine Socket-Verbindung ist eine verbindungsorientierte
Kopplung zwischen zwei Prozessen, typischerweise einem
Server und einem Client.
Die Verbindung wird explizit aufgebaut, danach kann
bidirektional kommuniziert werden. Die Verbindung wird
geschlossen, wenn sie nicht mehr benötigt wird.
Vergleichbar mit Telefongespräch!
Prozess-2
Prozess-1
Peter Sobe
Internettechnologien
16
Client-Server-Kommunikation –
per Socket-Verbindung (2)
Phasen einer Socket-Verbindung als Sequenz-Diagramm
Client
Server
es = socket ()
bind (es, address) … Angabe des Ports
s = socket ()
connect(s, address)
… IP-Adresse und Port
listen(es)
s = accept(es)
write(s, …)
read(s, …)
write(s, …)
read(s, …)
write(s, …)
read(s, …)
close(s)
Peter Sobe
close(s)
Internettechnologien
17
Client-Server-Kommunikation –
per Socket-Verbindung (3)
• Der Server bindet eine Dienst an einen bekannten Port (bind)
und akzeptiert Verbindungen (accept).
• Ein Client verbindet sich mit einem Dienst an einem
bekannten Port (connect).
• Beide Prozesse können Daten senden und empfangen.
Funktionen: write() / read() oder send() / recv()
• Welcher Prozess wann sendet und wann empfängt, muss
durch das Protokoll zwischen Server und Client geklärt sein.
• Ein Server erzeugt typischerweise nach dem Annehmen einer
Verbindung (accept) einen neuen Thread für die Verbindung.
Der verbleibende Thread nimmt wieder neue Verbindungen
an (Multi-Client Server).
Peter Sobe
Internettechnologien
18
Beispiel für ein socketbasiertes C/S-System (1)
Beispiel:
 Im folgenden Bild die beiden Fenster links: zwei Client-Prozesse
 Fenster rechts: Server-Anwendung mit zwei Prozessen, die über die
Ports 7707 und 7708 einen Dienst anbieten
 Dienst besteht in der verteilten Speicherung von Daten
 Hier auf einem einzelnen Rechner demonstriert
 Clients werden im Bild nacheinander bedient
 Gleichzeitige Bedienung von Clients ist möglich (aber nicht gezeigt)
 Kann auf unterschiedlichen Rechnern im Internet ausgeführt werden
(sofern verbunden, sofern Client- bzw. Server-Binaries installiert,
sofern Ports durch Firewall offen sind)
P. Sobe
Internettechnologien
19
Beispiel für ein socketbasiertes C/S-System (2)
P. Sobe
Internettechnologien
20
C-Quellcode des Server-Programms (1)
Server source code (C language, important parts only):
int entry_sock;
entry_sock = socket(AF_INET,SOCK_STREAM,0);
/*connect sock_address with local address and a unique port */
sock_address.sin_port = htons( (unsigned short int)(port_base +
process_id*proc_inc));
sock_address.sin_addr.s_addr = INADDR_ANY;
// everyone may connect
sock_address.sin_family = AF_INET;
rc = bind(entry_sock, (void*)&sock_address, sizeof(sock_address));
P. Sobe
Internettechnologien
21
Quellcode des Server-Programms (2)
Server source code (C language, important parts only) continued:
listen(entry_sock, BACKLOG);
do {
// wait for a new connection
addrlen = sizeof(client_sock_address);
new_sock = accept(entry_sock, (void*)&client_sock_address, &addrlen );
/* connection_fun starten */
params_not_copied=1;
pthread_create(&connection_thread,NULL,(void*)&connection_fun,NULL);
/* wait for thread until parameters got copied*/
do { } while(params_not_copied);
} while(1);
P. Sobe
Internettechnologien
22
Quellcode des Server-Programms (3)
Server source code (C language, important parts only) continued:
void connection_fun(void *param){
selected = new_sock;
params_not_copied=0;
…
// communicate with client according a user-specified protocol
read(selected,&pmessage, MSG_LEN);
write(selected,&pmessage, MSG_LEN);
Erklärung:
pmessage ist hier die
Datenstruktur, die zum
Nachrichtenaustausch dient.
Sie ist MSG_LEN Bytes lang.
close(selected);
}
P. Sobe
Internettechnologien
23
Quellcode des Client-Programms
Client source code (C language, important parts only):
sock = socket(AF_INET,SOCK_STREAM,0);
serv_addr.sin_addr.s_addr = inet_addr(server_ipaddress);
serv_addr.sin_port
= htons(server[i].port);
serv_addr.sin_family
= AF_INET;
rc = connect(sock, (struct sockaddr *) &serv_addr, sizeof(serv_addr));
printf("client connected to %s:%d rc=%d \n", server_ipaddress, server[i].port, rc);
write(sock, &pmessage, MSG_LEN);
read(sock, &pmessage, MSG_LEN);
close( sock );
P. Sobe
Internettechnologien
24
„Benannte Pipe“ als Kommunikationskanal (1)
Die „benannte Pipe“ (NamedPipe) ist ein alternativer Mechanismus,
zwei Prozesse über das Netzwerk zu verbinden.
Eine „benannte Pipe“ kann wie eine Datei angesehen werden,
die auf der Seite des Server-Rechners eingerichtet ist und einen Kanal
zwischen zwei verteilten, kooperierenden Prozessen darstellt. Einer
schiebt Daten in den Kanal hinein (Schreiben) und der andere holt sich
diese Daten auf der anderen Seite aus dem Kanal heraus (Lesen).
Auf der Clientseite wird über eine URL \\hostname\pipe\pipename der
Eingang des Kanals als Datei-Equivalent bereitgestellt.
Der Datenaustausch läuft danach wie eine normale Dateioperation auf
einem lokalen Rechner ab. Auf der Serverseite wird nur der pipename
als Handle zum lokalen Eingang des Kanals bereitgestellt. Damit wird
der Kommunikationskanal als eine Art virtuelle Datei angesehen und
der Datenaustausch über normale Dateioperationen realisiert.
Peter Sobe
Internettechnologien
25
Pipe als Kommunikationskanal (2)
Aktion
erzeugt
Pipe
Wa rtet auf
ankomm end
e
Verbi ndung
em pfängt
Daten
Sendet
Daten
Löst die
Verbi ndung
Schließt
Handle
Legende:
Aktion
CreateNamedPipe()
WaitNamedPipe()
Wa rtet auf
Pipe verfü gbar
Schließt
Datei an
Pipe an
ConnectNamedP ipe()
CreateFile()
ReadFile()
WriteFile()
sendet
Daten
WriteFile()
ReadFile()
em pfängt
Daten
DisconnectNamedP ipe()
CloseHandl e()
Schließt
Handle
CloseHandle()
Ablaufsteuerung vom Protokoll der Kooperation a
bhängig
Austausch Daten
notwendiger Ablauf
Peter Sobe
Internettechnologien
-
26
Pipe als Kommunikationskanal (3)
Pipe-Funktionen des Servers
Erzeugen von Pipes - CreateNamedPipe()
Der Server muss auf seinem Rechner die Pipe erzeugen und dabei die
Funktionalität angeben. Bei der Erzeugung gibt er statt seinem eigenen
Computernamen einen Punkt an und legt den Pipenamen fest,
z. B.: \\.\pipe\p1
Beim Server dient der Punkt (.) als Rechnername. Beim Client muss
dann anstatt des Punkts der Rechnername angegeben werden.
Beispiel als C-Quelltext:
hPipe=CreateNamedPipe("\\\\.\\pipe\\p1", PIPE_ACCESS_INBOUND,
PIPE_WAIT, PIPE_UNLIMITED_INSTANCES,
256,256,1000,NULL);
Pufferlängen für Ein- und Ausgabe sind 256 Bytes, als Time-out Zeit gilt 1000
ms und es sind keine Sicherheitsattribute gesetzt.
Peter Sobe
Internettechnologien
27
Pipe als Kommunikationskanal (4)
Warten auf Client-Verbindungen - ConnectNamedPipe()
Mit der ConnectNamedPipe()-Funktion leitet der Server einen Warteprozess
auf eine Clientanforderung ein. Der erste Parameter ist das Pipe-Handle, der
zweite Parameter ist NULL oder enthält einen Pointer auf eine overlappedStruktur.
Beispiel: ConnectNamedPipe(hPipe,NULL);
Aufheben der Client-Verbindungen - DisConnectNamedPipe()
Mit der DisConnectNamedPipe()-Funktion beendet der Server eine
Verbindung zu einem Client. Der einzige Parameter ist das Pipe-Handle. Der
Rückkehrwert ist bei Erfolg verschieden von 0.
Beispiel: DisConnectNamedPipe(hPipe);
Schließen des Pipe-Handles - CloseHandle()
Mit der CloseHandle ()-Funktion schließt der Server das Handle zu einer Pipe.
Beispiel: CloseHandle(hPipe);
Peter Sobe
Internettechnologien
28
Pipe als Kommunikationskanal (5)
Pipe-Funktionen des Client
Warten auf die Verfügbarkeit der Pipe - WaitNamedPipe()
Mit der WaitNamedPipe()-Funktion wartet der Client auf die Pipe, die der
Server erzeugen muss. Der erste Parameter enthält sowohl host- als auch
pipe-Namen in der Form \\hostname\pipe\pipename. Der zweite Parameter
enthält eine time-out-Angabe.
Anschluß an eine Pipe - CreateFile()
Mit der CreateFile()-Funktion realisiert der Client das Öffnen der Pipe als eine
Datei. Der erste Parameter enthält das pipe-Handle in der Form
\\hostname\pipe\pipename.
Beispiel:
hPipe=Create(“\\\\iserver.informatik.htw-dresden.de\\pipe\\p1“,
GENERIC_WRITE, 0, NULL,OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL,
NULL );
Peter Sobe
Internettechnologien
29
Pipe als Kommunikationskanal (6)
Datenaustausch mit der Pipe
Der Client bedient sich hier normaler Datei-Operationen der Windowsoder Unix-Plattform. Im Wesentlichen kommen dabei die ReadFile()und WriteFile()-Funktionen zum Einsatz. Wir verweisen hier auf die
Beispiele, wo einige Varianten verwendet wurden bzw. auf die
Systemdokumentation.
Beispiel: WriteFile( hPipe, text, strlen(text)+1, &dwW, NULL );
Bemerkung: text ist hier die Adresse eines Speicherbereichs, der die
zu übertragende Nachricht enthält!
In einigen Fällen ist es zweckmäßig, nach der Schreiboperationen die
Pipe-Funktion FlushFileBuffers() aufzurufen. Der einzige Parameter ist
das Pipe-Handle. Damit wird gewartet, bis die kooperierende
Anwendung alle Informationen gelesen hat.
Peter Sobe
Internettechnologien
30
Pipe als Kommunikationskanal (9)
Beenden der Verbindung mit der Pipe – CloseHandle()
Der Client beendet die Verbindung mit der Pipe durch Aufruf der
CloseHandle()-Funktion.
Peter Sobe
Internettechnologien
31
Remote Procedure Call (1)
A new paradigm hides message transfer: Birrell and Nelson,
1984
Remote procedure call (RPC):
• A program calls a subroutine or procedure in another address
space
• RPC is initiated by a client: procedure call and wait for return
• request message to server (hidden)
• server calls procedure locally and transfers the parameters
• response message (hidden)
• client continues operation
• Sun RPC (UNIX), later Microsoft RPC,
• later CORBA and Java RMI for object-oriented languages
Peter Sobe
Internettechnologien
32
Remote Procedure Call (2)
RPC:
Client
Server
rc=calculate(p1,p2,p3, &solution);
calculate
wait …
client- und server-Stub
Peter Sobe
Internettechnologien
33
Remote Procedure Call (3/3)
client-stub: provides proximity
procedures that collect
parameters and compose
messages to server, receive
responses and copy back results
server stub: receives messages,
extracts parameters and calls
corresponding procedures on the
server side, results are sent back to
the client
r = calc(a,b);
Stub: receive and call
local procedure
Stub
int calc(int x, int y)
res = calc(par1,par2);
OS and network stack
OS and network stack
Verschiedene RPC-Infrastukturen:
Sun RPC (UNIX), later Microsoft RPC, CORBA and Java RMI for object-oriented
languages, XML-RPC, SOAP-PHP-Webservice
P. Sobe
Internettechnologien
34
RPC am Beispiel von CORBA
CORBA
Common Object Request Broker Architecture (ORB)
 a distributed service for communication between objects
 a specification, programming language independent –
but typically C++ or Java
IDL (interface definition language) for specifications of the
interfaces
Every special CORBA implementation: ORB and IDL compiler,
related to a programming language
P. Sobe
Internettechnologien
35
CORBA – Interface specification
Workflow:
Step 1 – manually:
Specification of interface with IDL –language (C-like)
Step 2 – automated:
IDL compiler generates a skeleton (server object) and stubs
(local objects that can be used by the clients).
The skeleton and stubs fit to the applied ORB
Step 3 – manually:
Implementation of client and server classes, using generated
stubs and skeletons
P. Sobe
Internettechnologien
36
CORBA – Interface specification
IDL example:
Example taken from:
A. Vogel and K. Duddy: Java Programming
with CORBA.
Wiley and Sons Inc., 1997
P. Sobe
module RoomBooking {
interface Meeting {
// A meeting has two read-only attributes:
// the meeting purpose and the paricipants
readonly attribute string purpose;
readonly attribute string participants;
interface MeetingGenerator {
// method creates meeting objects
Meeting CreateMeeting (in string purpose,
in string participants);
};
};
interface Room {
enum Slot{ am9, am10, am11, pm12,
pm1, pm2, pm3, pm4};
const short MaxSlots=8;
typedef Meeting Meetings(MaxSlots);
exception NoMeetingInThisSlot{};
exception SlotAlreadyTaken{};
Meetings View();
void Book(in Slot a_slot, in Meeting a_meeting);
void Cancel(in Slot a_slot);
};
};
37
Internettechnologien