Schichtenmodelle Netzkommunikation - Sockets -RPCs ...weber/sysprog/script/kap5-sockets.pdf ·...

Systemprogrammierung SS 2010 © H. Weber, HS RMNetzwerkprogrammierung Folie 1

5. Netzwerkprogrammierung

SchichtenmodelleNetzkommunikation - Sockets- RPCs- Server-Modelle


5.1 Schichtenmodelle - Definitionen

Schichtenmodelle zerlegen Aufgaben in verschiedene AbstraktionsebenenJede Ebene und die Weiterleitung/Schnittstelle von einer Ebene in die nächste Ebene ist definiertZiel des OSI Schichtenmodells:

Referenzmodell für die „Verbindung offener Systeme“Interoperabilität zwischen Herstellern (Hardware und Software)Unterteilung des Kommunikationsprozesses in eine Reihe von separaten Schichten, wobei sich die der jeweiligen Schicht zugewiesenen Funktionen auf die Funktionen der benachbarten Schicht stützenInterner Aufbau der Schicht ist offen (Entwicklern überlasses Detail), Funktion der Schicht und die Schnittstellen zwischen den Schichten sind definiert

Unterteilung in Funktionsgruppen:Hardware Schichten (inkl. Treiber) Logische Schichten (Bildung von Netzen und virtuellen Verbindungen über Netzwerkgrenzen hinaus)Anwendungsschichten (bedient sich des Netzes, ohne daß die verwendete Hardware von Bedeutung ist)


Arbeitsstation Arbeitsstation

Kommunikation

802.x-Header LLC-Header IP-Header TCP-Header Telnet Daten 802.x Trailer

LLC-Header IP-Header TCP-Header Telnet Daten

IP-Header TCP-Header Telnet Daten

TCP-Header Telnet Daten

TelnetProtokoll

TerminalEmulation

Telnet Daten

Beispiel: Telnetsession

Application

Presentation

Session

Transport

Network

Data Link

Physical

Anwendung

Darstellung

Sitzung

Transport

Netzwerk

DatenübertragungSicherung

PhysikalischeSchicht

5.1 Schichtenmodelle - Aufbau


5.1 Schichtenmodelle - Erklärung

Physikalische Schicht (Physical Layer)Übergabe und Empfang des Bitstroms an physikalisches Medium (Draht, LWL,...)Definition der elektrischen Signale der HardwareEthernet, Standleitungen,... (802.x)Spezifikation der Verbindungsleitungen

Datenübertragungs-, Sicherungsschicht (Data Link Layer)Verantwortlich für fehlerfreie Kommunikation zwischen zwei NetzknotenZ.B. MAC Adressen bei Ethernet oder Token RingTreiber für BetriebssystemMTU (Maximum Transfer Unit)

Netzwerkschicht (Network Layer)Verbindung der Netzknoten zwischen den Rechnern zu einem Netzwerk (über die Netzwerkgrenzen hinweg)Routing und FlußkontrolleLogische Adressen für die einzelnen Netzwerkschnittstellen (NIC)Zerlegung des Datenstroms in Datagramme passender Größe (Fragmentierung, entsprechend dem verwendeten Protokoll, bsp. MTU – Ethernet 1518 Byte)


5.1 Schichtenmodelle - Erklärung

Transportschicht (Transport Layer)Bereitstellung von Transportprotokollen für AnwendungsentwicklerVerbindungsorientierte und verbindungslose Portokolle

Sitzungsschicht (Session Layer)Definition der DatenstrukturenEnde-zu-Ende Kommunikationsprozeß (aktiver Prozeß des einen Hosts kommuniziert mit aktivem Prozeß des anderen kommunizierenden Hosts)In TCP/IP beschreiben Ports und Sockets den Weg, über den Applikationen kommunizierenAuthentisierung und Verrechnung

Darstellungsschicht (Presentation Layer)Definition des Formats der eigentlichen DatenBspw. Kompression, Zeichencodeumsetzung (ASCII, EBCDIC, usw.), Verschlüsselung (Veschlüsselung und Entschlüsselung der Übertragung; z. B. DES)

Anwendungsschicht (Application Layer)Definition des eigentlichen anwendungsspezifischen ProtokollsBsp: SMTP, FTP, TFTP, HTTP(S), Telnet, DNS, SNMP, ...


5.1 Schichtenmodelle - ARPA

AR

PA S

chic

hten

mod

ellProcess/

Application

Host-to-Host

Internet

NetworkInterface

Schichten 5 bis 7 werden in der Prozeß- und Anwendungs-Schicht zusammengefaßtSchicht 4 (TCP und UDP) entspricht der Host-to-Host Schicht Schicht 3 (IP, ICMP) entspricht der Internet-SchichtSchicht 1 und 2 werden als Netzwerkschnittstellen-Schicht (Network Access Layer, Local NetworkLayer) bezeichnet

OSI

Sch

icht

enm

odel

l

Application

Presentation

Session

Transport

Network

Data Link

Physical

Anfang der 70er Jahre entwickelte die Advanced Research Projects Agency einSchichtenmodell zur Beschreibung der Kommunikation von Rechner-systemen bestehend aus vier Schichten. Dieses Modell ist die Grundlage für die TCP/IP Protokollimplementierung.


Internet-Schicht:Übertragung von Paketen von einem Host zu einem anderen HostPakete enthalten die Adressinformation für die Datenübertragung durch das NetzwerkRealisierung durch das Internet Protokoll (RFC 791); definiert werden:

Quell- und ZieladresseTime to Live (TTL)Flags (z.B. DF – don‘t fragment)Fragment OffsetVersionsnummerProtokollnumer

Zerlegung und Wiederzusammenführung von PaketenKeine Sicherstellung des EmpfangsPakete, die einen Fehler verursachen, werden ignoriert und verworfen

5.1 Schichtenmodelle – Internet-Schicht


Version Type of Service Total Length

Identifier Fragment Offset

Time to Live Protocol Header Checksum

Source Address

Destination Address

Options & Padding

Data

IHL

Flags

...

0 8 16 24 31 Bitstelle

IP H

eade

rIP

Dat

a

...



IP Header:Versionsnummer: 4 Bit – meist Version 4 (IPv4), wird zukünftig durch Version 6 (IPv6) abgelöstLänge des Headers: 4 Bit – Festlegung der durch die verschiedenen Optionen variablen Länge des Headers (in 4 Byte-Einheiten)Type of Service: 8 Bit – definiert die Priorität eines IP PaketsGesamtlänge: 2 Byte – von IP Header und Daten (2 Byte definieren maximale Paketgröße auf 65536 Byte = 64 kByte)Identification: 16 Bit – für Zusammensetzen fragmentierter IP Pakete genutztFlags: 3 Bit – Fragmentierungsinformation; erstes Bit ohne Bedeutung; zweites Bit (DF) 0=fragmentierbar, 1=nicht fragmentierbar; drittes Bit (MF) 0=letztes Fragment, 1=mehr Fragmente folgenFragment Offset: 13 Bit – zeigt an, an welcher Stelle ein fragmentiertes IP Paket ursprünglich standTime to Live: 8 Bit – zeigt die maximale Anzahl von Routerhops (oder Sekunden) an; jeder Router, den das IP Paket durchläuft, dekrementiertdiesen Wert; der Router, der den Wert auf Null setzt, verwirft das Paket



IP Header:Protocol ID: 8 Bit – identifiziert, welches Protokoll der höheren Schichten dem IP Header folgt (Bsp.: 1dec ICMP, 6dec TCP, 17decUDP, 89dec OSPF)Prüfsumme: 16 Bit – Prüfsumme des IP HeadersAusgangs- (Source) und Ziel- (Destination) adresse: je 4 Byte

Optionen und Padding: 32 Bit – Debug-, Meß- und Sicherheitsfunktionen (z.B. Zeitpunkt, zu dem sich das Datenpaket in einem bestimmten Router befunden hat) und Padding zum Auffüllen der 32 Bit mit NullenDaten: enthält die eigentlichen Nutzdaten

Reserviert240 – 255Klasse EIP-Multicast Adressen gemäß RFC 1112224 – 239Klasse D

2562.097.1528 Bit21 Bit192 – 223Klasse C65.53616.38416 Bit14 Bit128 – 191Klasse B

16.777.21612824 Bit7 Bit0 – 127Klasse A

Anzahl Hosts

Anzahl Netze

HostanteilNetzanteilErstes Byte



Host-zu-Host-Schicht:Zuordnung der IP Datagramme zu den jeweiligen Prozessen mittels UDP bzw. TCP PortsRouting auf den Zielsystemen

User Datagram Protocol, UDP:Sicherung (Quittierung) für die einzelnen Datenpakete wird den Applikationen überlassenReihenfolge der IP Pakete muß duch die Applikation kontrolliert und ggf. berichtigt werdenSchnelles, verbindungsloses ProtokollVerwendung: DNS, NFS, TFTP, RIP, SNMP

Transport Control Protocol, TCP:Verbindungsaufbau Ende-zu-Ende (von Port zu Port), ohne Festlegung des Wegs in der Internet-SchichtReihenfolge der IP Pakete wird kontrolliert und ggf. in die richtige Reihenfolge sortiertGesichertes, verbindungsorientiertes Protokoll

5.1 Schichtenmodelle – Host-zu-Host-Schicht


UDP Header:Minimaler Protokolloverhead

Ausgangs- (optional) und ZielportLänge des gesamten UDP DatenpaketsChecksumme über das gesamte Datenpaket (optional; abhängig davon, ob höheres Protokoll eine Checksumme verlangt) wird unter Berücksichtigung des Pseudoheaders, bestehend aus Ausgangs- und Zieladresse sowie Protokollfeld des IP Headers, berechnet

Source Port Destination Port

Length

Data ...


UD

P M

essa

ge

Checksum

5.1 Schichtenmodelle – Host-zu-Host-Schicht


TCP Header:Adressierung der Applikation über Portnummer Datenpakete werden nummeriert (Sequenznumber) und bestätigt (Acknowledgement Number)Tree Way Handshake zum VerbindungsaufbauFlußkontrolle ist vorgesehen

Source Port Destination Port

Acknowledgement Number


TCP

Mes

sage

Offset Window

Checksum

Options

Data ...

Urgent Pointer

Sequence Number

Reserviert Code

Padding

5.1 Schichtenmodelle – Host-Host-Schicht


Nutzung der TCP bzw. UDP Daten in Applikationen

Application

Presentation

Session

Transport

Network

Data Link

Physical Physikalische Verbindung

Process/Application

Host-to-Host

Internet

NetworkInterface

Sicherung

IP

TCP UDP

RARP

telnet

FTP

SMTP

HTTP SNMPTFTP

BootP

DNS

DHCP

ARP

ICMP RIPOSPF

5.1 Schichtenmodelle – Prozeß- und Anwendungsschicht


5.1 Schichtenmodelle - Protokolle

Application

Presentation

Session

Transport

Network

Data Link

Physical

Process/Application

Host-to-Host

Internet

NetworkInterface

OSI Schichtenmodell

ARPA Schichtenmodell

HypertextTransfer

FileTransfer

ElectronicMail

TerminalEmulation

DomainNames

FileTransfer

Client/Server

NetworkManage-

mentHypertextTransferProtocol(HTTP)

RFC 2068

FileTransferProtocol

(FTP)

RFC 959

SimpleMail

TransferProtocol(SMTP)

RFC 821

TelnetProtocol

RFC 854

DomainName

System(DNS)

RFC 1034,1035

TrivialFile

TransferProtocol(TFTP)

RFC 783

Sun Micro-systems

Network FileSystem

(NFS)RFCs 1014,1057, 1094

Simple Network

ManagementProtocol(SNMP)

RFC 1157,1901-10,2271-75

Transmission Control Protocol (TCP)RFC 793

User Datagram Protocol (UDP)RFC 768

Address ResolutionARP RFC 826

RARP RFC 903

Internet ControlMessage Protocol (ICMP)

RFC 792

Internet Protocol (IP)

RFC 791Network Interface Cards:

Ethernet, Token Ring, ARCNET, MAN, WANRFC 894, RFC 1042, RFC 1201 und andere

ÜbertragungsmedienTwisted Pair, Coax, LWL, Wireless Media u.a.

Protokoll-Implementierung


5.1 Schichtenmodelle - Kommunikationsschichten: Unix

Stream-System für ProtokollschichtenSchicht = Treiber, leicht austauschbar

7 Anwendung named pipes, rlogin, …6 Präsentation XDR

5 SitzungBS-Schnittstelle: sockets

4 Transport3 Netzwerk2 Datenverbindung1 Phys. Verbindung Ethernet

TCP/IP

ports, IP Adresse


5.2 Netzkommunikation

Namensgebung im InternetEindeutige IP-Adresse: z.B. 141.2.15.25, 32 Bits, notiert in 4 Dezimalzahlen je 0..254 (Bytes) (IP 4)Name: mailhub.informatik.fh-wiesbaden.de server.LocalNet.domain.countryZuordnung IP-Nummer Name wird auf speziellen Rechner gehalten (dynamic name server DNS)Vergabe und Zuordnung der IP-Adresse durch zentrale Instanzen

byte 0 byte 1 byte 2 byte 3

reserviert1111

Rechner IdNetz Id011

Rechner IdNetz Id01

Multicast0111

Rechner IdNetz Id0A

B

C

D

E


5.2 Netzkommunikation - Ports

Konzept „Kommunikationspunkte“Beispiel TCP/IP: well known port numbers

Dienst Portnummer ProtokollTelnet 23 TCPFTP 21 TCPSMTP 25 TCPrlogin 513 TCPrsh 514 TCPportmap 111 TCPrwhod 513 UDPportmap 111 UDP


5.2 Netzkommunikation - Sockets

Arten von Sockets:- UNIX Domain Sockets

lokal, Repräsentation im Dateisystem- Internet Domain Sockets

verteilt, Repräsentation über IP-Adresse + Portnummer


5.2 Netzkommunikation – Sockets

Stream-Sockets:• Verlässliche Kommunikation (i.d.R eines Bytesroms) zwichen zwei Endpunkten

• Verbindungsorientierter Transportdienst

• Im Fall von Internet-Domain-Sockets ist TCP das benutzte Default-Protokoll

Datagram-Sockets:• Unzuverlässige Kommunikation von Einzelnachrichten (best effort delivery)

• Verbindungsloser Datagram-Dienst

• Im Fall von Internet-Domain-Sockets ist UDP das benutzte Default-Protokoll

Raw Sockets:•Erlauben Zugriffe auf untergelagerte Protokolle wie IP, ICMP, ...(hier nicht weiter betrachtet)



Socket-Adressen Datentypen• Include-Dateien:

#include <sys/types.h>#include <sys/sockets.h>

• Internet-Adresse:

struct in_addr { u_long s_addr; };

• Socket-Adresse (allg. Typ, in System Calls benutzt):

struct sockaddr {u_short sa_family; /* hier AF_xxxx */char sa_data[14]; /* bis 14B typ-spez.Adresse */ };

• Socket-Adresse (Internet-Typ):

struct sockaddr_in { u_short sin_family; /* hier AF_INET, o. AF_UNIX */u_short sin_port; /* Port-Numer in network byte order */struct in_addr sin_addr; /* IP-Adresse in network byte order */char sin_zero[8]; /* unbenutzt */ };

• Cast: struct sockaddr_in my_addr; ...(struct sockadd*) &my_addr



Überblick über Systemaufrufe

socket( ) Erzeugenbind( ) Adresse oder Namen zuordnenlisten( ) Server: Socket auf Akzeptieren von

Clients vorbereitenaccept( ) Server: Warten auf Verbindungsanfrageconnect( ) Client: Verbindung aufbauensend( ) / write( ) Sendenrecv / read( ) Empfangenshutdown( ) Verbindung schliessenclose( ) Socket zerstörensendto( ) / recvfrom( ) UDP senden/empfangenselect( ) Warten auf Eintreffen eines von

mehreren I/O-Ereignissen



Verbindungsorientierte Kommunikation mit TCP/IP

Client Server


5.2 Netzkommunikation – SocketsVerbindungslose Kommunikation mit UDPClient Server



Erzeugen eines Sockets

• int socket(int family, int type, int protocol)

Erzeugt einen Socket in der Internet-Domäne (family = AF_INET) oder der UNIX-Domäne (AF_UNIX) vom Typ Stream-Socket(type = SOCK_STREAM), Datagram-Socket (SOCK_DGRAM) oder Raw-Socket (SOCK_RAW) zur Verwendung mit dem Protokoll protocol und liefert einen Deskriptor für den erzeugten Socket.Für protocol wird i.a. der Wert 0 übergeben. Dann wird das Default-Protokoll gewählt. In der Internet-Domäne ist dies TCP für einen Stream-Socket bzw. UDP für einen Datagram-Socket. Es ist noch keine Adresse zugeordnet. Der Socket ist nicht gebunden.

Beispiele:

sd = socket(AF_INET, SOCK_STREAM, 0)sd = socket(AF_INET, SOCK_DGRAM, 0)



Binden einer Socket-Adresse

• int bind(int sd, struct sockaddr *addr, int addrlen)

Bindet die in der struct sockaddr übergebene, von der Domäne des betrachteten Sockets abhängige Adresse an den Socket.Internet-Domäne: struct sockaddr_inUNIX-Domäne: FilenameDer Socket wird im TCP/IP Protokoll-Modul registriert.Für Clients in verbindungsorientierter Kommunikation nicht notwendig.

Beispiel:

r = bind(sd,(struct sockaddr)* my_addr, sizeof(my_addr))



Socket vorbereiten auf Verbindungsanfragen

• int listen(int sd, int qlength)

Zeigt dem TCP/IP-Modul an, dass TCP-Verbindungen über den Socket sdangenommen werden sollen. qlength gibt die maximale Länge der Warteschlange eingehender Verbindungsanfragen an, für die ein accept aussteht. Dies ist nicht die Gesamtzahl von möglichen Clients.Nur auf der Serverseite notwendig-

Beispiel:

r = listen(sd, 10)


5.2 Netzkommunikation - Sockets

Warten auf Verbindungsanfragen

• int accept(int sd, struct sockaddr * claddr, int *addrlen)

Blockiert, bis eine Verbindungsanfrage eines Clients am Socket sd anliegt.Dann wird ein neuer Socket erzeugt und dessen Deskriptor zurückgegeben.Damit entsteht eine private Verbindung zwischen Client und Server.Der Socket sd steht für weitere Verbindungsanforderungen zur Verfügung.Die Identität des Clients (entfernte Socket-Adresse) steht in der Struktur claddr zur Verfügung, deren Länge wird in addrlen zurückgegeben.Nur auf der Serverseite bei verbindungsorientierter Kommunikation notwendig.

Beispiel:

sndnew = accept(sd, struct sockaddr* clientaddr,*clientaddrlen)



Verbindungsanfrage

• int connect(int sd, struct sockaddr *saddr,int saddrlen)

Aktive Verbindungsanfrage eines Clients über seinen Socket sd an den durch die Adresse in saddr mit Länge saddrlen adressierten Server.Dies ist nur für die Client-Seite bei verbindungsorientierter Kommunikation notwendig.

Beispiel:

r = connect(sd, &saddr, sizeof(saddr))


5.2 Netzkommunikation – SocketsSenden / Empfangen

• int write(int sd, char *buf, int len)

• int send(int sd, char *buf, int len, int flag)

Der write-Aufruf wird wie bei File-Deskriptoren benutzt. Der send-Aufruf besitzt einen zusätzlichen Parameter flag für spezielle Optionen.

•int read(int sd, char *buf, int nbytes)

•int recv(int sd, char *buf, int nbytes, int flag)

Der read-Aufruf wird wie bei File-Deskriptoren benutzt. Der recv-Aufrufbesitzt einen zusätzlichen Parameter flag für spezielle Optionen. Beispiel:

count = write(sd, buf, len)count = read(sd, buf, len)count = send(sd, buf, len, sflag)count = recv(sd, buf, len, rflag)



Schliessen einer Verbindung

• int shutdown(int sd, int how)

Geordnetes Schliessen einer Verbindung, how gibt an, ob sich das TCP/IP-Modul auch nach dem Schliessen noch um die Verbindung kümmern soll.

Der Socket-Deskriptor bleibt bestehen und muß gegebenenfalls mitclose zerstört werden.

Beispiel:

r = shutdown(sd, 2)



I/O-Multiplexing

• int select(int nfdsp1, int *rdmask, int wrmask, int *exmask, struct timeval *tmout)

Warten auf das Eintreffen eines von mehreren I/O-Ereignissen. Dies bietet die Möglichkeit zum Umgang mit mehreren Socket/File-Deskriptoren in einem Prozess, um so lange zu warten, bis an einem Deskriptor einer vorgebbaren Menge ein Ereignis eintritt (z.B. Socketwird lesbar) oder ein Timeout abgelaufen ist. Die Wartezeit kann zeitlich begrenzt werden oder unbefristet sein.



Die fd-Mengen werden über Bitmasken spezifiziert, wozu z.B. die FD_SET-Makros dienen. Bei der Rückkehr ist readmask verändert und enthält die Bitmaske der Deskriptoren, für die Ereignisse eingetreten sind, der Rückgabewert gibt die Anzahl dieser Deskriptoren an.

Beispiel:

int sd1, sd2; fd_set fds; FD_ZERO(&fds); sd1 = socket(AF_INET,...); FD_SET(sd1,&fds);sd2 = socket(AF_INET,...); FD_SET(sd2,&fds);rv = select(sd2+1, &fds, NULL, NULL, timeout);



Hilfsfunktionengethostname() Ermitteln des eigenen Hostnamensgethostid() Ermitteln der eigenen IP-Adressegethostbyname() Ermitteln der IP-Adresse eines

Rechners bei gegebenem Hostnamengetservbyname() Ermitteln der Portnummer bei

gegebenem Dienstnamengetsockopt() Ermitteln der Optionen eines Socketssetsockopt() Setzen von Socket-Optionen


5.2 Netzkommunikation - RPC

Remote Procedure Calls RPCRemote Method Invocation RMI Java!Remote Function Call RFC

Form: wie normaler Prozedur/Methodenaufruf, Ausführungdurch Netzwerkdienst & Transport bleiben verborgenClient-Server Standardmechanismus!

SyntaxformenStub-Procedure ComputeWetter(heute) → RemoteProc(Wetter,heute)Argument RemoteProc(Wetter,heute)

Client Server

Anwender- RPC- Prozeßprozeß

RPC-Prozeduren RPC-Prozeduren Prozeduraufruf

Transport Transport Original-Prozeduren



RPC-Systeme

• ONC (Sun) RPCs (UNIX / portabel)

• DCE RPCs (allgemein)

• MS Windows RPCs (ähnlich DCE)

• MS DCOM (Windows)

• .NET Remoting

• CORBA (objektorientiert, portabel bzgl. Sprache und Plattform)

• JAVA RMI (sprachspezifisch)

• XML-RPC / SOAP (XML-codierte Daten über http)



RPCRPC--AblaufAblauf

Client Stub Netzwerk Stub ServerProzeduraufruf

Argumente wartet ..Packen/konv. RPC

Argumenteentpacken/konv.

warten … Prozeduraufruf Original-Rückkehr ablauf

ErgebnisseRPC return Packen/konv.

ErgebnisseAuspacken/konv.

RETURN



Transport der Argumente: soll maschinenunabhängig sein!Problem: Hardwareformat von Zahlen

Big endian Motorola 680X0, IBM 370

höherwertig niederwertigByte0 Byte1 Byte2 Byte3

höherwertig niederwertigByte3 Byte2 Byte1 Byte0

Little endian Intel 80X86, VAX, NS32000

Lösung data marshaling, z.B. mit XML, Java Serialisierung, ...

auch für compiler data alignment (Adreßgrenzen bei records, Wortadressierung, ...)



Beispiel Unix (ONC RPC)Spezielle C-Bibliotheken /lib/libc.a; SystemV: /usr/lib/librpc.aAnwendung: NFS über RPC Schichtenmodell RPC/XDR external data representation

Pmap_.., ath_.., xdr_..Details des Protokolls: Vorsicht!

clnt_. ../ svc_...Parameter des Transportprotokoll TCP/IP setzen/lesenBerechtigungen setzen/lesen

Client: anmelden mit registerrpc()Client: callrpc() Server: svr_run()

RPC bei DCE: Compiler für spezielle Interface Definition Languge. RPC durch stub-Aufrufe und Laufzeitbibliothek für Transport



• Verwendung des RPC-Protokoll-Compilers rpcgen

• Zu schreiben: Spezifikationsdatei mul.x

• rpcgen mul.x -> generiert: mul.hmul_clnt.c <- Client-Stubmul_xdr.c <- XDR-Transformationenmul_svc.c <- Server-Stub

• Zu programmieren: Client-Hauptprogram mul.cServer-Funktion mul_svc_proc.c


5.2 Netzkommunikation – Server-Modelle

Wo entstehen in Client-Server-Systemen Qualitäts- und Effizienzprobleme?Im Bereich des Servers !Wann?- Bei zu lang dauernder Antwort des Servers- Bei zu vielen gleichzeitigen Clients- Bei zu starker Beanspruchung des Server-Rechners

Server

Client 1

Client 2

Client n-1

Client n

...


5.2 Netzkommunikation – Server-Modelle

Iterativer ServerServer mit select-TechnikKonkurrenter Server mit ProzeßmodularitätKonkurrenter Server mit Thread-ModularitätKonkurrenter Server mit Pool von n wiederverwendbaren Prozessen(unterschiedliche Techniken bezüglich Einsatz und Schutz des accept, eventuell zusätzliche Synchronisierung notwendig je nach Betriebssystem)Konkurrenter Server mit Pool von n wiederverwendbaren Threads(verschiedene Thread-Arten: KLT, ULT, unterschiedliche Techniken bzgl. Einsatz und Schutz des accept)

Ziel: LeistungssteigerungEs werden hier nur Socket-basierte Server betrachtet, bei RPCs sind ähnliche Vorgehensweisen möglich

Schichtenmodelle Netzkommunikation - Sockets -RPCs ...weber/sysprog/script/kap5-sockets.pdf ·...

Documents

Transcript of Schichtenmodelle Netzkommunikation - Sockets -RPCs ...weber/sysprog/script/kap5-sockets.pdf ·...