20.3 Elementare TCP-Socket-Funktionen - Pearson Bookshop

20.3 Elementare TCP-Socket-Funktionen 681 

20.3 Elementare TCP-Socket-Funktionen 

Abbildung 20.5 zeigt die elementaren Socket-Funktionen, die bei einer typischen TCP- 

Client/Server-Realisierung benötigt werden. Diese elementaren Socket-Funktionen werden 

nachfolgend beschrieben. 

TCPServer 

socket() 

bind() 

TCPClient 

socket() 

listen() 

accept() 

hier blockiert, bis 

Client verbindet 

read() 

Aufbau der Verbindung 

ClientAnforderung 

connect() 

write() 

write() 

read() 

close() 

ServerAntwort 

Verbindungsabbruch (EOF) 

read() 

close() 

Abbildung 20.5: Elementare TCP-Socket-Funktionen für eine TCP-Client/Server-Realisierung 

20.3.1 Kreieren eines Sockets mit Funktion socket 

Um ein Socket anzulegen, steht die Funktion socket zur Verfügung. 

#include 

#include 

int socket(int domain, int typ, int protokoll); 

gibt zurück: Socketdeskriptor (bei Erfolg); -1 bei Fehler 

Parameter domain: 

domain legt die zu benutzende Protokoll- bzw. Adressfamilie fest. Hierfür ist eine der 

Konstanten aus Tabelle 20.4 anzugeben. Es kann dabei für domain entweder die Konstante, 

die mit PF_ (Protokollfamilie) oder die mit AF_ (Adressfamilie) beginnt, angegeben 

werden. Das Vorhandensein von zwei möglichen Konstanten für die gleiche Protokollart 

ist historisch begründet, da ursprünglich eine Protokollfamilie mehrere Adressfamilien 

unterstützen sollte.

682 20 Netzwerkprogrammierung mit Sockets 

 

 

Die PF_-Konstante sollte dabei beim Anlegen des Sockets und die AF_-Konstante in 

den Socket-Adressstrukturen verwendet werden. 

Da jedoch bisher keine Protokollfamilie mehrere Adressfamilien unterstützt, sind die 

entsprechenden PF_-Konstanten gleich den AF_-Konstanten, wobei in der Vergangenheit 

meist die AF_-Konstanten verwendet wurden. 

Hier werden wir uns an die POSIX-Vorgabe halten: PF_-Konstanten beim Anlegen von 

Sockets und AF_-Konstanten in den Adressstrukturen. Zu erwähnen ist noch, dass es für 

Unix Domain Protokolle neben der AF_- und PF_-Unterscheidung noch zwei Varianten 

gibt: _UNIX bzw. _LOCAL. Auch das ist historisch begründet: die _UNIX-Konstanten wuden 

früher angegeben. Der heutige Standard empfiehlt die Verwendung der neu eingeführten 

_LOCAL-Variante. 

Protokollfamilie Adressfamilie Protokollart 

PF_UNIX, PF_LOCAL AF_UNIX, AF_LOCAL Unix Domain Protokolle (zur lokalen 

Kommunikation) 

PF_INET AF_INET IPv4-Protokolle 

PF_INET6 AF_INET6 IPv6-Protokolle 

PF_IPX AF_IPX IPX Novell Protokolle 

PF_X25 AF_X25 X.25/ISO-8208 Protokoll 

PF_AX25 AF_AX25 Amateur Radio AX.25 Protokoll 

PF_PACKET AF_PACKET Low level Paket-interface 

Tabelle 20.4: Einige häufig benutzte Protokoll- und Adressfamilien 

Unter Linux befinden sich alle möglichen Angaben zu domain in der Datei /usr/include/ 

bits/socket.h. 

Während man bei der in 20.2.2 vorgestellten Funktion socketpair für den Parameter 

domain nur AF_LOCAL bzw. PC_LOCAL angeben kann, kann die Funktion socket verwendet 

werden, um Sockets einer beliebigen Protokollfamilie anzulegen. 

Parameter typ: 

Für den Parameter typ kann man eine der folgenden Konstanten angeben: 

SOCK_STREAM Stream-Socket (siehe auch Seite 657) 

SOCK_DGRAM Datagram-Socket (siehe auch Seite 657)


SOCK_SEQPACKET 

SOCK_RAW 

ähnlich zu SOCK_STREAM mit dem Unterschied, dass Daten in der gleichen 

Paketgröße empfangen werden, in der sie geschrieben werden, was bei 

SOCK_STREAM nicht zutrifft, da hier die Daten nur als Bytestream ankommen 

und der Empfänger nicht weiß, ob diese durch ein write oder mehrere 

write-Aufrufe in das Socket geschrieben wurden. SOCK_SEQPACKET wird bei 

Protokollen wie X.25 oder AX.25 verwendet. 

Raw-Socket 

Es sind zwar noch weitere Angaben möglich, aber diese sind nur für sehr spezifische 

Anwendungen von Interesse. Unter Linux befinden sich alle möglichen Angaben zu typ 

in der Datei /usr/include/bits/socket.h. 

Parameter protokoll: 

Der Parameter protokoll wählt das zu benutzende Protokoll aus der mit den ersten beiden 

Parametern festgelegten Protokollfamilie aus. Üblicherweise gibt man hier 0 an und 

lässt den Systemkern das Standardprotokoll für die entsprechende Protokollfamilie auswählen. 

Für PF_INET bzw. PF_INET6 ist TCP das Standard-Stream-Protokoll und UDP das 

Standard-Datagram-Protokoll. Weitere Protokollnummern können bei Bedarf in /etc/ 

protocols nachgeschlagen werden. 

Nicht alle möglichen Kombinationen von domain- und typ-Angaben sind gültig. Tabelle 

20.5 zeigt die wichtigsten gültigen Kombinationen zusammen mit dem dabei verwendeten 

Protokoll. 

AF_INET AF_INET6 AF_LOCAL 

SOCK_STREAM TCP TCP Lokales Stream-Socket 

SOCK_DGRAM UDP UDP Lokales Datagram-Socket 

SOCK_RAW IPv4 IPv4 nicht gültig 

Tabelle 20.5: Kombinationen von domain- und typ-Angaben bei der socket-Funktion 

Ein mit socket kreiertes Socket ist noch nicht initialisiert. Für das Socket wird bei seiner 

Erzeugung lediglich ein bestimmtes Protokoll festgelegt, es wird aber noch nicht mit 

einer Ressource verbunden, so dass ein lesender oder schreibender Zugriff auf ihn noch 

nicht möglich ist. 

Es ist nun die Aufgabe einer Seite, üblicherweise des Serverprozesses, eine Verbindung 

vorzubereiten und darauf zu warten, dass irgendjemand sich mit ihm verbindet. Clientprozesse 

erzeugen ihrerseits ein Socket, teilen dem System die gewünschte Adresse mit 

und versuchen dann eine Verbindung aufzubauen. Die Verbindung ist hergestellt, wenn 

der Server, der auf einen Client wartet, den Verbindungsversuch akzeptiert. Danach können 

der Server- und Clientprozess über das Socket miteinander kommunizieren. Ist ein 

Socket richtig initialisiert, kann auf ihn wie auf jeden anderen Filedeskriptor mit den elementaren 

E/A-Funktionen, wie z.B. read oder write, zugegriffen werden.


Die Reihenfolge, in der Server- und Clientprozess die entsprechenden Funktionen aufrufen 

müssen, um eine Verbindung herzustellen, ist in Abbildung 20.5 veranschaulicht. 

Nachfolgend werden diese Funktionen näher vorgestellt. 

20.3.2 Zuordnen einer lokalen Protokolladresse mit Funktion bind 

(Server) 

Die Funktion bind ordnet einem Socket eine lokale Protokolladresse zu, was bei Internet- 

Protokollen die Kombination aus einer IPv4- bzw. IPV6-Adresse mit einer 16-Bit TCPoder 

UDP-Portnummer ist. 

#include 

#include 

int bind(int sockfd, struct sockaddr *my_addr, socklen_t addrlen); 

gibt zurück: 0 (bei Erfolg); -1 bei Fehler 

sockfd gibt den Socketdeskriptor des entsprechenden Sockets an. 

Der zweite Parameter ist die Adresse der entsprechenden Socket-Adressstruktur und der 

dritte Parameter die Größe dieser Adressstruktur. 

In *my_addr kann beim Aufruf von bind die IP-Adresse und die Portnummer gezielt 

gesetzt sein. Es ist jedoch auch möglich, dass eine dieser beiden Komponenten oder auch 

beide auf 0 gesetzt sind, was bedeutet, dass man es dem Kernel überlässt, was er dafür 

wählt. Statt dem Wert 0 sollte man der Komponente sin_addr die Konstante INADDR_ANY 

(htonl(INADDR_ANY)) und der Komponente sin6_addr die Variable sin6addr_any 

zuweisen, die meist den Wert 0 repräsentieren. Solche INADDR_ANY- bzw. sin6addr_any- 

Adressen bezeichnet man als Wildcard-Adressen. 

Tabelle 20.6 fasst diese Möglichkeiten mit den daraus resultierenden Zuordnungen 

zusammen. 

Angabe 

Auswirkung 

sin_addr, sin6_addr 

sin_port, sin6_port 

Wildcard 0 Kernel wählt IP-Adresse und kurzlebige 

Portnummer 

Wildcard ungleich 0 Kernel wählt IP-Adresse; Portnummer 

festgelegt 

lokale IP-Adresse 0 festgelegte IP-Adresse; Kernel wählt kurzlebige 

Portnummer 

lokale IP-Adresse ungleich 0 festgelegte IP-Adresse und Portnummer 

Tabelle 20.6: Unterschiedliche Möglichkeiten und Auswirkungen bei Spezifikation der Protokolladresse


Server binden beim Start deren bekannte Ports. Verzichtet ein TCP-Client bzw. -Server 

darauf, wählt der Kernel beim Aufruf von connect bzw. listen für das Socket einen kurzlebigen 

Port aus. Kurzlebige Portnummern sind bei Clients üblich. 

Um die lokale Protokolladresse eines Sockets zu ermitteln, steht die Funktion getsockname 

(siehe auch 20.3.5) zur Verfügung. 

Programm 20.6 (sockname.c) verdeutlicht nochmals die Vergabe der Werte aus Tabelle 20.6. 

#include "netzprog.h" 

int 

main(int argc, char *argv[]) 

{ 

struct sockaddr_in sa; 

int 

i, sock, len_sa = sizeof(sa); 

if (argc != 2) 

fehler_meld(FATAL, "usage: %s IPv4-Nr", argv[0]); 

printf("%15s | %10s | %20s |\n", "IP-Adresse", "Portnummer", "Resultat"); 

for (i=1; i


Nachdem man Programm 20.6 (sockname.c) kompiliert und gelinkt hat: 

cc -o sockname sockname.c netzprog.c fehler.c 

zeigt es abhängig von der übergebenen IPv4-Adresse die entsprechend resultierende IP- 

Adresse und Portnummer, wie z.B.: 

$ ./sockname 127.23.182.9 

IP-Adresse | Portnummer | Resultat | 

0.0.0.0 | 33970 | 0.0.0.0/33970 | 

0.0.0.0 | 12345 | 0.0.0.0/12345 | 

127.23.182.9 | 33971 | 127.23.182.9/33971 | 

127.23.182.9 | 12345 | 127.23.182.9/12345 | 

$ 

20.3.3 Warten auf Verbindungsanforderungen mit listen und accept 

(Server) 

Nachdem ein Socket mit bind durch einen Serverprozess an eine Protokolladresse gebunden 

wurde, teilt der Serverprozess durch einen Aufruf der Funktion listen dem System 

mit, dass er bereit ist, mit anderen Prozessen über dieses Socket Verbindungen einzugehen. 

Bevor aber wirklich eine Verbindung für ein Socket, das mit listen vom Serverprozess 

abgehört wird, aufgebaut wird, muss der Serverprozess den Verbindungsversuch 

seitens des Clients mit dem Aufruf der Funktion accept akzeptieren. 

Ruft der Serverprozess accept vor einem Verbindungsversuch seitens des Clients auf, so 

blockiert normalerweise accept so lange, bis der Client einen Verbindungswunsch äußert. 

Um eine solche Blockierung bei accept zu unterbinden, muss das Socket mit fcntl als 

nicht blockierend markiert werden. In diesem Fall kehrt accept sofort mit einer entsprechenden 

Fehlernummer zurück. Um festzustellen, ob ein Verbindungswunsch seitens 

des Clients ansteht, was man mit pending bezeichnet, kann die Funktion select verwendet 

werden. Die beiden Funktionen listen und accept sind wie folgt deklariert: 

#include 

#include 

int listen(int sockfd, int backlog); 


int accept(int sockfd, struct sockaddr *addr, socklen_t *addrlen); 

gibt zurück: Socketdeskriptor des akzeptierten Sockets (bei Erfolg); -1 bei Fehler 

Beide Funktionen erwarten als ersten Parameter den Socketdeskriptor des entsprechenden 

Sockets. 

Der Parameter backlog legt die maximal erlaubte Anzahl von anstehenden (pending) Verbindungswünschen 

seitens des Clients fest. Wird dieses Maximum erreicht, so werden 

weitere Verbindungsversuche seitens des Clients abgelehnt, wobei dies dem Client mit


dem Fehler ECONNREFUSED mitgeteilt wird. BSD legte früher als maximale Größe von 

backlog 5 fest. Bei heutigen Servern im Internet, die Hunderttausende von Anforderungen 

in der Stunde erhalten, muss man für backlog einen größeren Wert angeben, wie etwa 

16, 20 oder noch größer. 

Die Funktion accept macht aus einer anstehenden Verbindung eine wirkliche Verbindung, 

die auch einen neuen Socketdeskriptor erhält. Dieser neue Socketdeskriptor, der 

als Rückgabewert geliefert wird, erbt alle Attribute vom Socket, das zuvor mit listen 

abgehört wurde. 

Den als erstes Argument übergebenen Socketdeskriptor bezeichnet man als horchenden 

Socket und den von accept zurückgegebenen als verbundenen Socket. Auf dem horchenden 

Socket kann der Server weitere Verbindungsanforderungen akzeptieren, wobei jedes Mal 

ein neues verbundenes Socket mit einem neuen Socketdeskriptor zur Verfügung gestellt 

wird. Beendet der Server die Bedienung eines Clients, wird nur das jeweilige verbundene 

Socket geschlossen. 

Die Parameter addr und addrlen geben die Adressen an, in die vom Systemkern die 

Adresse des Clients zu schreiben ist. Es ist zu beachten, dass der Parameter addrlen zwei 

Funktionen hat: Beim Aufruf legt er die Länge der übergebenen Adressstruktur addr fest, 

und bei der Rückkehr von accept enthält er die aktuelle Anzahl von Bytes, die in addr 

geschrieben wurden. Deswegen ist dieser Parameter auch als Zeiger deklariert. 

20.3.4 Aufbauen einer Verbindung zum Server mit connect (Client) 

Auch ein Client könnte nach dem Erzeugen eines Sockets mit der Funktion bind diesem 

Socket eine Adresse zuweisen. Da diese lokale Adresse aber normalerweise für den 

Client nicht von Interesse ist, lässt er diesen Schritt oft aus und überlässt es dem Systemkern, 

irgendeine passende Adresse für das Socket zu finden. In jedem Fall muss jedoch 

ein Client die Funktion connect aufrufen, um eine Verbindung zum Server herzustellen. 

#include 

#include 

int connect(int sockfd, const struct sockaddr *serv_addr, socklen_t addrlen); 


Die Parameter beim connect-Aufruf spezifizieren das zu verbindende Socket und die Zieladresse 

des Servers. 

Hat ein Prozess die Arbeit mit einem Socket beendet, sollte er dieses mit close schließen, 

um die damit verbundenen Ressourcen wieder freizugeben.


20.3.5 Ermitteln der lokalen bzw. der fremden Protokolladresse 

Um die lokale oder die mit einem Socket verbundene fremde Protokolladresse zu erfragen, 

stehen die beiden folgenden Funktionen zur Verfügung: 

#include 

int getsockname(int sockfd, struct sockaddr *addr, socklen_t *addrlen); 

int getpeername(int sockfd, struct sockaddr *addr, socklen_t *addrlen); 

geben zurück: 0 (bei Erfolg); -1 bei Fehler 

getsockname liefert über addr die lokale und getpeername die fremde Protokolladresse zu 

sockfd. 

Da beide Funktionen die Struktur addr füllen und den Parameter addrlen auf die Länge 

der Struktur setzen, muss für addrlen bei beiden beim Aufruf ein Zeiger (Adresse) angegeben 

werden. 

Diese beiden Funktionen werden in folgenden Situationen benötigt: 

getsockname 

 

 

 

in einem Client nach dem Aufruf von connect (ohne einen bind-Aufruf). In diesem 

Fall liefert getsockname die lokale IP-Adresse und Portnummer, die der Kernel dieser 

Verbindung zugeordnet hat. 

nach einem bind-Aufruf mit Portnummer 0. In diesem Fall liefert getsockname die 

vom Kernel zugewiesene lokale Portnummer. 

in einem Server nach einem bind mit einer Wildcard-Adresse und einem dann erfolgreichen 

accept-Aufruf. In diesem Fall liefert getsockname die der Verbindung zugeteilte 

lokale IP-Adresse. Für sockfd muss hier der Socketdeskriptor des verbundenen 

Sockets (nicht des horchenden) angegeben werden. 

getpeername 

in einem Server, der nach einem fork im Kindprozess exec aufruft, um hier ein anderes 

Serverprogramm, wie z.B. telnet zu laden. In diesem Fall steht die Socket-Adressstruktur 

mit der Adresse des Peers dem neuen Server nicht mehr zur Verfügung, wohl aber bleibt 

der Socketdeskriptor über den exec-Aufruf hinweg geöffnet. Um nun die IP-Adresse und 

Portnummer zu ermitteln, muss hier getpeername aufgerufen werden. 

Die folgende Funktion liefert die Adressfamilie zum Socket sockfd zurück: 

int sockfd_family(int sockfd) { 

union { 

struct sockaddr sa; /* MAXSOCKADDR = maximal mögliche */ 

char daten[MAXSOCKADDR]; /* Socket-Adressstruktur in Bytes */ 

} un; 

socklen_t len = MAXSOCKADDR;


} 

if (getsockname(sockfd, (struct sockaddr *)un.daten, &len) < 0) 

return -1; 

return un.sa.sa_family; 

Diese Funktion nehmen wir wieder genauso wie die folgenden Funktionen in der Programmdatei 

netzprog.c auf: 

void my_shutdown(int fd, int wie) { 

if (shutdown(fd, wie) < 0) 

fehler_meld(FATAL_SYS, "shutdown-Fehler"); 

} 

void my_getpeername(int sockfd, struct sockaddr *addr, socklen_t *addrlen) { 

if (getpeername(sockfd, addr, addrlen) < 0) 

fehler_meld(FATAL_SYS, "getpeername-Fehler"); 

} 

void my_getsockname(int sockfd, struct sockaddr *addr, socklen_t *addrlen) { 

if (getsockname(sockfd, addr, addrlen) < 0) 

fehler_meld(FATAL_SYS, "getsockname-Fehler"); 

} 

int my_socket(int family, int type, int protocol) { 

int n; 

if ( (n = socket(family, type, protocol)) < 0) 

fehler_meld(FATAL_SYS, "socket-Fehler"); 

return n; 

} 

void my_bind(int sockfd, const struct sockaddr *addr, socklen_t addrlen) { 

if (bind(sockfd, addr, addrlen) < 0) 

fehler_meld(FATAL_SYS, "bind-Fehler"); 

} 

void my_listen(int sockfd, int backlog) { 

if (listen(sockfd, backlog) < 0) 

fehler_meld(FATAL_SYS, "listen-Fehler"); 

} 

int my_accept(int sockfd, struct sockaddr *addr, socklen_t *addrlen) { 

int n; 

while ( (n = accept(sockfd, addr, addrlen)) < 0) 

if (errno != EPROTO && errno != ECONNABORTED) 

fehler_meld(FATAL_SYS, "accept-Fehler"); 

return n; 

} 

void my_connect(int sockfd, const struct sockaddr *addr, socklen_t addrlen) { 

if (connect(sockfd, addr, addrlen) < 0) 

fehler_meld(FATAL_SYS, "connect-Fehler"); 

} 

20.3.6 Eine einfache iterative TCP-Client/Server-Realisierung 

Programm 20.7 (server2.c) zeigt einen Server, der auf Clientanforderungen wartet. Beim 

Ankommen einer Clientanforderung schickt er dem Client einen Text mit einer Zufallszahl, 

den dieser dann ausgeben kann.


#include 


int 


{ 

char *serv_addr, *serv_port; /* IP-Adresse und Portnummer */ 

struct sockaddr_in adr_serv, adr_clnt; /* Server- und Clientadressstr. */ 

int 

n, len_inet; 

int serv_sock, clnt_sock; /* Server- und Clientsocket */ 

char puffer[MAX_ZEICHEN]; /* String für Serverantwort */ 

srand(time(NULL)); 

serv_addr = (argc >= 2) ? argv[1] : "127.0.0.1"; /* IP-Adresse */ 

serv_port = (argc >= 3) ? argv[2] : "9876"; /* Portnummer */ 

/*... Verbindungs-Socket erzeugen */ 

serv_sock = my_socket(PF_INET, SOCK_STREAM, 0); 

/*... Socket mit eigenen Adressen verknüpfen */ 

memset(&adr_serv, 0, sizeof(adr_serv)); 

adr_serv.sin_family = AF_INET; 

adr_serv.sin_port = htons(atoi(serv_port)); 

if (strcmp(serv_addr, "*")) { 

adr_serv.sin_addr.s_addr = inet_addr(serv_addr); 

if ( adr_serv.sin_addr.s_addr == INADDR_NONE ) 

fehler_meld(FATAL, "Ungültige Adresse"); 

else 

adr_serv.sin_addr.s_addr = htonl(INADDR_ANY); /* wildcard */ 

/*... Socket eine Protokolladresse zuordnen */ 

my_bind(serv_sock, (struct sockaddr *)&adr_serv, sizeof(adr_serv)); 

/*... Socket in passiven Zustand für Verbindungsannahmen versetzen */ 

my_listen(serv_sock, 10); 

printf("... Akzeptiere Verbindungen auf Port %d\n", ntohs(adr_serv.sin_port)); 

while (1) { 

/*... Verbindung von Client akzeptieren */ 

len_inet = sizeof(adr_clnt); /* Auf connect seitens Clients warten */ 

clnt_sock = my_accept(serv_sock, (struct sockaddr *)&adr_clnt, &len_inet); 

n = sprintf(puffer, "--------------------------------------\n" 

"Verbindung von Client %s (Port %d) akzeptiert\n" 

".......... Deine Glückszahl ist %d\n" 

"--------------------------------------\n", 

inet_ntoa(adr_clnt.sin_addr), ntohs(adr_clnt.sin_port), 

rand()%100+1); 

my_write(clnt_sock, puffer, n, ""); /* Client die Antwort schicken */ 

my_close(clnt_sock); /* Verbindung zum Client schließen */


} 

} 

exit(0); /* wird aufgrund der Endlosschleife nie ausgeführt */ 

Programm 20.7 (server2.c): Server, der Clients einen Text mit einer Zufallszahl schickt 

Nachdem man Programm 20.7 (server2.c) kompiliert und gelinkt hat: 

cc -o server2 server2.c netzprog.c fehler.c 

kann man den Server im Hintergrund starten: 

$ ./server2 & [Server im Hintergrund starten] 

... Akzeptiere Verbindungen auf Port 9876 

[1] 2608 

$ 

Nun kann man mit telnet Clientanforderungen an diesen Server schicken; voreingestellt 

sind die IP-Nummer: 127.0.0.1 und die Portnummer 9876: 

$ telnet 127.0.0.1 9876 

Trying 127.0.0.1... 

Connected to 127.0.0.1. 

Escape character is '^]'. 

-------------------------------------- 

Verbindung von Client 127.0.0.1 (Port 32938) akzeptiert 

.......... Deine Glückszahl ist 99 

-------------------------------------- 

Connection closed by foreign host. 

$ telnet 127.0.0.1 9876 

Trying 127.0.0.1... 



-------------------------------------- 



-------------------------------------- 


$ kill %1 [Server beenden] 

[1]+ Beendet ./server2 

$ 

Startet man einen gerade beendeten Server zu schnell wieder, kann ein Fehler auftreten, 

wie z.B.: 

$ ./server2 & 

bind-Fehler: Address already in use 

[2] 2971 

[2] Exit 1 ./server2 

$ 

Das liegt daran, dass die TCP-Implementierungen der meisten Unix-Systeme üblicherweise 

Einschränkungen bezüglich der Wiederbenutzung eines Verbindungspunktes


(lokaler Port am lokalen Rechner) machen. So gilt z.B. für TCP-Ports, dass diese erst nach 

zwei Minuten wieder verwendet werden können. Mit der Option SO_REUSEADDR beim Aufruf 

der Funktion setsockopt kann man festlegen, dass diese Einschränkung aufzuheben 

ist und der entsprechende TCP-Port innerhalb einer kurzen Zeit wieder benutzt werden 

kann. Darauf wird in Kapitel 20.6 näher eingegangen. 

In den obigen Ablaufbeispielen konnte der gestartete Server nur über die fest vergebene 

IP-Adresse 127.0.0.1 kontaktiert werden. Gibt man beim Aufruf als Argument '*' an, 

wird eine wildcard-IP-Nummer verwendet, so dass der Server nicht nur über die lokale 

IP-Adresse 127.0.0.1 kontaktiert werden kann, sondern auch von einem fremden Rechner, 

da in diesem Fall über die externe Adresse die Anforderung an die lokale Adresse 

weitergeschickt wird: 

$ ./server2 '*' & [Server im Hintergrund starten] 

[1] 8212 


$ telnet 127.0.0.1 9876 

Trying 127.0.0.1... 



-------------------------------------- 



-------------------------------------- 


$ /sbin/ifconfig [Erfragen der externen IP-Adresse des Rechners] 

eth0 Protokoll:Ethernet Hardware Adresse 00:E0:7D:7D:16:98 

inet Adresse:192.168.69.6 Bcast:192.168.69.255 Maske:255.255.255.0 

inet6 Adresse: fe80::2e0:7dff:fe7d:1698/64 Gültigkeitsbereich:Verbindung 

....... 

lo Protokoll:Lokale Schleife 

inet Adresse:127.0.0.1 Maske:255.0.0.0 

inet6 Adresse: ::1/128 Gültigkeitsbereich:Maschine 

....... 

$ telnet 192.168.69.6 9876 

Trying 192.168.69.6... 



-------------------------------------- 



-------------------------------------- 


$ 

Nun probieren wir, den Server von einem fremden Rechner über seine IP-Adresse 

192.168.69.6 zu kontaktieren: 

Rechner birne $ telnet 192.168.69.6 9876 

Trying 192.168.69.6... 


Escape character is '^]'.


-------------------------------------- 



-------------------------------------- 


Rechner birne $ 

Durch die Verwendung von wildcard-IP-Nummern ist also der Server nicht mehr nur 

über eine feste IP-Nummer kontaktierbar. 

Beenden wir noch unseren Server: 



$ 

Statt des telnet-Kommandos soll nun ein eigenes Clientprogramm (siehe Programm 20.8 

(client2.c)) erstellt werden. 


int 


{ 

char *serv_addr, *serv_port; /* IP-Adresse und Portnummer */ 

struct sockaddr_in adr_serv; /* Serveradressstruktur */ 

int n, sock; /* Socket */ 

char puffer[MAX_ZEICHEN]; /* String für Serverantwort */ 

serv_addr = (argc >= 2) ? argv[1] : "127.0.0.1"; /* IP-Adresse */ 

serv_port = (argc >= 3) ? argv[2] : "9876"; /* Portnummer */ 

/*... Socket erzeugen */ 

sock = my_socket(PF_INET, SOCK_STREAM, 0); 

/*... Socket mit eigenen Adressen verknüpfen */ 

memset(&adr_serv, 0, sizeof(adr_serv)); 

adr_serv.sin_family = AF_INET; 

adr_serv.sin_port = htons(atoi(serv_port)); 

adr_serv.sin_addr.s_addr = inet_addr(serv_addr); 

if ( adr_serv.sin_addr.s_addr == INADDR_NONE ) 

fehler_meld(FATAL, "Ungültige Adresse"); 

/*... Verbindung zum Server aufbauen */ 

my_connect(sock, (struct sockaddr*)&adr_serv, sizeof(adr_serv)); 

printf("... Verbindung zu Server %s (Port %d) aufgebaut\n", 

inet_ntoa(adr_serv.sin_addr), ntohs(adr_serv.sin_port)); 

/*... Serverantwort lesen */ 

n = my_read(sock, &puffer, sizeof(puffer)-1, ""); 

puffer[n] = '\0'; /* \0-terminieren */ 

printf("%s\n", puffer);


} 

my_close(sock); /* Socket schließen und Client beenden */ 

exit(0); 

Programm 20.8 (client2.c): Client, der eine Anforderung an den Server schickt 

Nachdem man Programm 20.8 (client2.c) kompiliert und gelinkt hat: 

cc -o client2 client2.c netzprog.c fehler.c 


$ ./server2 '*' & [Server im Hintergrund starten] 


[1] 8314 

$ 

und dann unser Clientprogramm verwenden, um Clientanforderungen an den Server zu 

schicken: 

$ ./client2 127.0.0.1 

... Verbindung zu Server 127.0.0.1 (Port 9876) aufgebaut 

-------------------------------------- 



-------------------------------------- 

$ ./client2 192.168.69.6 


-------------------------------------- 



-------------------------------------- 



$ 

20.3.7 Eine einfache parallele TCP-Client/Server-Realisierung 

In Programm 20.7 (server2.c) wurde der Server iterativ realisiert. Für einen einfachen 

Server wie diesen, der nur wenig Bearbeitungszeit für die Antwort (Füllen eines kleinen 

Text-Puffers, der eine Zufallszahl enthält) benötigt, ist dies ausreichend. Benötigt der Server 

aber mehr Zeit für die Bearbeitung der Clientanforderung, so müssen neu ankommende 

Clientanforderungen warten, bis er mit der Beantwortung dieser einen 

Anforderung fertig ist. In diesem Fall sollten die Clientanforderung gleichzeitig (parallel) 

bedient werden, was mit dem Kreieren von Kindprozessen mittels fork möglich ist. 

Programm 20.9 (server3.c) zeigt eine erste (noch fehlerhafte) Realisierung eines solchen 

parallel arbeitenden Servers. 

1 #include 

2 #include "netzprog.h"


3 

4 /*.... hier wird noch Code eingefügt */ 

5 

6 int 

7 main(int argc, char *argv[]) 

8 { 

9 char *serv_addr, *serv_port; /* IP-Adresse und Portnummer */ 

10 struct sockaddr_in adr_serv, adr_clnt; /* Server- und Clientadressstr. */ 

11 int n, len_inet; 

12 int serv_sock, clnt_sock; /* Server- und Clientsocket */ 

13 char puffer[MAX_ZEICHEN]; /* String für Serverantwort */ 

14 pid_t pid; 

15 

16 serv_addr = (argc >= 2) ? argv[1] : "127.0.0.1"; /* IP-Adresse */ 

17 serv_port = (argc >= 3) ? argv[2] : "9876"; /* Portnummer */ 

18 

19 /*... Verbindungs-Socket erzeugen */ 

20 serv_sock = my_socket(PF_INET, SOCK_STREAM, 0); 

21 

22 /*... Socket mit eigenen Adressen verknüpfen */ 

23 memset(&adr_serv, 0, sizeof(adr_serv)); 

24 adr_serv.sin_family = AF_INET; 

25 adr_serv.sin_port = htons(atoi(serv_port)); 

26 if (strcmp(serv_addr, "*")) { 

27 adr_serv.sin_addr.s_addr = inet_addr(serv_addr); 

28 if ( adr_serv.sin_addr.s_addr == INADDR_NONE ) 

29 fehler_meld(FATAL, "Ungültige Adresse"); 

30 } else 

31 adr_serv.sin_addr.s_addr = htonl(INADDR_ANY); /* wildcard */ 

32 

33 /*... Socket eine Protokolladresse zuordnen */ 

34 my_bind(serv_sock, (struct sockaddr *)&adr_serv, sizeof(adr_serv)); 

35 

36 /*... Socket in passiven Zustand für Verbindungsannahmen versetzen */ 

37 my_listen(serv_sock, 10); 

38 printf("... Akzeptiere Verbindungen auf Port %d\n", ntohs(adr_serv.sin_port)); 

39 


41 

42 while (1) { 

43 srand(time(NULL)); 

44 

45 /*... Verbindung von Client akzeptieren */ 

46 len_inet = sizeof(adr_clnt); /* Auf connect seitens Clients warten */ 

47 if ( (clnt_sock = accept(serv_sock, (struct sockaddr *)&adr_clnt, 

48 &len_inet)) == -1) { 

49 /*.....................................*/ 


51 /*.....................................*/ 

52 fehler_meld(FATAL_SYS, "accept-Fehler"); 

53 } 

54 

55 if ( (pid = fork()) == -1)


56 fehler_meld(FATAL_SYS, "fork-Fehler"); 

57 

58 else if (pid == 0) { /*..................................... Kindprozess */ 

59 my_close(serv_sock); /* dupliziertes Serversocket schließen */ 

60 

61 sleep(2+rand()%5); /* Lange Bearbeitungszeit simulieren */ 

62 n = sprintf(puffer, "...Client %s akzeptiert; Glückszahl: %d\n", 

63 inet_ntoa(adr_clnt.sin_addr), rand()%100+1); 

64 

65 my_write(clnt_sock, puffer, n); /* Client die Antwort schicken */ 

66 my_close(clnt_sock); /* Dupliziertes Clientsocket schließen */ 

67 exit(0); /* Kindprozess beenden */ 

68 } /*............................................... Ende von Kindprozess */ 

69 

70 my_close(clnt_sock); /* Clientsocket im Elternprozess schließen */ 

71 } 

72 exit(0); /* wird aufgrund der Endlosschleife nie ausgeführt */ 

73 } 

74 /*.........................................................................*/ 

75 /*.... */ 

76 /*.... */ 


78 /*.... */ 

79 /*.... */ 

80 /*.... */ 

81 /*.........................................................................*/ 

Programm 20.9 (server3.c): Server, der parallel ankommende Clientanforderungen bearbeitet 

Nachdem man Programm 20.9 (server3.c) kompiliert und gelinkt hat: 

cc -o server3 server3.c netzprog.c fehler.c 




[2] 6917 

$ 

Nun kann man Clients starten (identisch zu Programm 20.8 (client2.c)): 

$ ./client2 127.0.0.1 


...Client 127.0.0.1 akzeptiert; Glückszahl: 3 

$ ./client2 127.0.0.1 



$ ./client2 127.0.0.1 



$


Auf den ersten Blick scheint alles richtig zu funktionieren. Allerdings sieht man bei diesem 

Ablaufbeispiel nicht, dass mit jeder Clientanforderung ein Zombieprozess im System 

verbleibt, nämlich der für jede Clientanforderung kreierte Server-Kindprozess, was man 

an folgender Ausgabe erkennen kann: 

$ ps -l 

F S UID PID PPID C PRI NI ADDR SZ WCHAN TTY TIME CMD 

.................. 

0 S 500 6917 2185 0 75 0 – 339 schedu pts/23 00:00:00 server3 

0 Z 500 6921 6917 0 75 0 – 0 exit pts/23 00:00:00 server3 



.................. 

$ 

Da wir den exit-Status des Server-Kindprozesses nicht mittels waitpid erfragen, bleibt 

jeder gestartete Server-Kindprozess als Zombie im System erhalten, was natürlich bei vielen 

Clientanforderungen früher oder später zu einer Belastung des Systems wird. Erst 

wenn der Serverprozess beendet wird, was eventuell Tage, Wochen oder auch Monate 

dauern kann, verschwinden auch die Zombie-Prozesse. 

$ kill %2 


$ ps -l 

.................. [nun keine Zombies mehr vorhanden] 

$ 

Dieses Problem der Zombies lässt sich beheben, indem man das Signal SIGCHLD abfängt, 

das bei Beendigung jedes Kindprozesses geschickt wird. Dazu müssen wir die folgenden 

Codezeilen im Programm 20.9 (server3.c) einfügen: 

4 void sig_kind(int signr); /* Signalhandler zum Abfangen des SIGCHLD-Signals */ 

... 

40 my_signal(SIGCHLD, sig_kind); 

... 

74 void sig_kind(int signr) { 

75 pid_t pid; 

76 int status; 

77 

78 while ( (pid = waitpid(-1, &status, WNOHANG)) > 0) /* Zombies verhindern */ 

79 fprintf(stderr, ".... Kind %d hat sich beendet\n", pid); 

80 return; 

81 } 

Die Funktion my_signal ist in netzprog.c wie folgt realisiert: 

sigfunc *my_signal(int signr, sigfunc *func) { 

struct sigaction act, oldact; 

act.sa_handler = func; 

sigemptyset(&act.sa_mask); 

act.sa_flags = 0;


#ifdef SA_RESTART 

if (signr == SIGALRM) 

act.sa_flags |= SA_RESTART; /* unterbrochenen Systemaufruf 

automatisch wieder starten */ 

#endif 

if (sigaction(signr, &act, &oldact) < 0) 

fehler_meld(FATAL_SYS, "sigaction-Fehler"); 

} 

return oldact.sa_handler; 

Starten wir jetzt unseren Server wieder im Hintergrund und dann entsprechend Clients, 

erleben wir wieder eine Überraschung: 



[2] 7111 

$ ./client2 127.0.0.1 



.... Kind 7115 hat sich beendet 

accept-Fehler: Interrupted system call 

[2]- Exit 1 server3 [Server beendet sich] 

$ 

Nun werden zwar keine Zombies mehr erzeugt, dafür bricht aber der Server unmittelbar 

nach der ersten Clientanforderung ab. Dieser Abbruch resultiert aus der Tatsache, dass 

beim Eintreffen des Signals SIGCHLD der accept-Aufruf für die Ausführung der Signalhandlers 

sig_kind unterbrochen wird, so dass diese Funktion als Rückgabewert -1 liefert 

und errno in diesem Fall auf EINTR gesetzt ist. Da dieser Spezialfall nicht abgefangen 

wird, wird fehler_meld aufgerufen und der Serverprozess beendet. 

Um diesen Abbruch zu vermeiden, müssen die Zeilen 49 bis 51 wie folgt ergänzt werden: 

47 if ( (clnt_sock = accept(serv_sock, (struct sockaddr *)&adr_clnt, 

48 &len_inet)) == -1) { 

49 if (errno == EINTR) /*... Wenn unterbrochen --> accept neu aufrufen */ 

50 continue; 

51 else 

52 fehler_meld(FATAL_SYS, "accept-Fehler"); 

53 } 

20.3.8 Besonderheiten beim Lesen und Schreiben in 

Stream-Sockets 

Beim Lesen bzw. Schreiben in Stream-Sockets (wie z.B. TCP-Sockets) gilt es einige Besonderheiten 

zu beachten, die bei normalen Dateien nicht gelten. Ein read bzw. write auf ein 

Stream-Socket kann weniger Bytes lesen bzw. schreiben als erwartet, was nicht zwangsläufig 

ein Fehler ist, da hier eventuell nur eine interne Puffergrenze überschritten wurde. 

Mit erneuten Aufrufen von read bzw. write können in solchen Fällen die noch verbliebe-


nen Bytes gelesen bzw. geschrieben werden. Während ein solches unvollständiges Lesen 

jederzeit vorkommen kann, kann ein unvollständiges Schreiben nur bei nicht-blockierenden 

Sockets auftreten. Deshalb verwenden wird die folgenden eigenen Funktionen zum 

Schreiben in bzw. zum Lesen aus Sockets, die wieder in der Programmdatei netzprog.c 

aufgenommen werden. 

ssize_t write_sock(int fd, const void *puffer, size_t n) { 

 

size_t verbleiben = n; 

ssize_t geschrieben; 

const char *zgr = puffer; 

while (verbleiben > 0) { /* schreibt n Bytes nach fd */ 

if ( (geschrieben = write(fd, zgr, verbleiben)) 0) { /* liest n Bytes von fd */ 

if ( (gelesen = read(fd, zgr, verbleiben)) < 0) { 

if (errno == EINTR) 

gelesen = 0; /* neuer read-Versuch */ 

else 

fehler_meld(FATAL_SYS, "read_sock-Fehler"); 

} else if (gelesen == 0) 

break; /* EOF */ 

verbleiben -= gelesen; 

zgr += gelesen; 

} 

return n-verbleiben; 

} 

static ssize_t lies_ein_puffer_zeichen(int fd, char *zgr) { 

static int noch_im_puffer = 0; 

static char lese_puffer[MAX_ZEICHEN]; 

static char *lese_zgr; 

if (noch_im_puffer


if (noch_im_puffer == 0) 

return 0; 

lese_zgr = lese_puffer; 

} 

noch_im_puffer--; 

*zgr = *lese_zgr++; 

return 1; 

} 

ssize_t readline_sock(int fd, void *puffer, size_t maxlen) { 

int i, n; 

char zeich, *zgr = puffer; 

} 

for (i=1; i < (int)maxlen; i++) { 

if ( (n = lies_ein_puffer_zeichen(fd, &zeich)) == 1) { 

*zgr++ = zeich; 

if (zeich == '\n') 

break; /* Zeilenende */ 

} else if (n == 0) { 

if (i == 1) 

return 0; /* EOF gleich am Anfang (keine Daten) */ 

else 

break; /* EOF; es wurden Daten gelesen */ 

} else 

fehler_meld(FATAL_SYS, "readline-Fehler"); 

} 

*zgr = '\0'; /* 0 terminieren */ 

return i; 

20.3.9 Verwendung von Standard E/A-Funktionen für Sockets 

Öffnen eines Socketdeskriptors mit fdopen zum Lesen und Schreiben (Vorsicht) 

Neben den elementaren E/A-Funktionen wie read, write usw. können auch Standard 

E/A-Funktionen wie fprintf, fscanf usw. verwendet werden, um auf Sockets zuzugreifen. 

Dazu muss man sich mit der Funktion fdopen nur einen FILE-Zeiger zu einem Socketdeskriptor 

zur Verfügung stellen lassen. Naheliegend wäre hier eine Implementierung 

wie die folgende, die jedoch falsch ist, wenn man in das Socket sowohl schreibt als auch 

aus ihm liest: 

int sockfd; /* Socketdeskriptor */ 

FILE *fz; /* FILE-Zeiger */ 

sockfd = socket(PF_INET, SOCK_STREAM, 0); 

fz = fdopen(sockfd, "r+"); /* r+ = Lesen und Schreiben auf Socket (falsch) */ 

if (fz == NULL) 

fehler_meld(FATAL_SYS, "fdopen-Fehler"); 

Bei dieser nahe liegenden Implementierung treten jedoch Schwierigkeiten auf, denn auf 

eine Ausgabeoperation kann hier nur dann eine Eingabeoperation folgen, wenn dazwi-


schen fflush, fseek, fsetpos oder rewind aufgerufen wird. Umgekehrt kann auf eine Eingabeoperation 

nur dann eine Ausgabeoperation folgen, wenn dazwischen fseek, fsetpos 

oder rewind aufgerufen wird, es sei denn, die Eingabeoperation hat EOF gelesen. Das 

Problem hier ist nun, dass die Funktionen fseek, fsetpos oder rewind ihrerseits lseek aufrufen, 

und dieser Aufruf schlägt bei Sockets fehl. 

Deswegen ist von dieser Implementierung abzuraten, und statt dessen die nachfolgend 

vorgestellte Methode zu verwenden. 

Getrennte FILE-Zeiger zum Lesen und Schreiben 

Statt eines FILE-Zeigers, der wie zuvor gleichzeitig Lesen und Schreiben ermöglicht, empfiehlt 

es sich, zwei unterschiedliche FILE-Zeiger zu verwenden: Einen zum Lesen und 

einem zum Schreiben aus dem Socket, wie z.B.: 

int sockfd; /* Socketdeskriptor */ 

FILE *lese_fz; /* FILE-Zeiger zum Lesen */ 

FILE *schreib_fz; /* FILE-Zeiger zum Schreiben */ 

sockfd = socket(PF_INET, SOCK_STREAM, 0); 

lese_fz = fdopen(sockfd, "r"); /* FILE-Zeiger zum Lesen aus Socket */ 

if (lese_fz == NULL) 

fehler_meld(FATAL_SYS, "fdopen-Fehler (Lesen)"); 

schreib_fz = fdopen(dup(sockfd), "w"); /* FILE-Zeiger zum Schreiben auf Socket */ 

if (schreib_fz == NULL) 

fehler_meld(FATAL_SYS, "fdopen-Fehler (Schreiben)"); 

Das Duplizieren des Socketdeskriptors bei schreib_fz ist notwendig, da unterschiedliche 

Streams auch unterschiedliche Filedeskriptoren verwenden sollten. So ist es möglich mit 

fclose nur die Lese- bzw. Schreibhälfte des Sockets zu schließen. Ohne Duplizierung würden 

bei einem fclose beide geschlossen. 

Es gibt nun mehrere Möglichkeiten, das Socket zu schließen: 

 

Alleiniges Schließen der Schreibhälfte 

fflush(schreib_dz); /* Übertragen der noch im Scheibpuffer stehenden Daten */ 

shutdown(fileno(schreib_dz), SHUT_WR); /* Schließen der Schreibhälfte */ 

fclose(schreib_dz); /* FILE-Schreibzeiger schließen */ 

 

Alleiniges Schließen der Lesehälfte 

shutdown(fileno(lese_dz), SHUT_RD); /* Schließen der Lesehälfte */ 

fclose(lese_dz); /* FILE-Lesezeiger schließen */ 

 

Gleichzeitiges Schließen der Schreib- und Lesehälfte 

fclose(schreib_dz); /* FILE-Schreibzeiger schließen */ 

shutdown(fileno(lese_dz), SHUT_RDWR); /* Schließen der Lese- und Schreibhälfte */ 

fclose(lese_dz); /* FILE-Lesezeiger schließen */


Der shutdown-Aufruf ist hierbei nur notwendig, wenn man mit fork Kindprozesse kreiert 

hat und sicherstellen will, dass eventuell in einem anderen Prozess offene Socketdeskriptoren 

auch geschlossen werden. 

Abfangen der Fehlernummer EINTR 

Bereits in Kapitel 20.3.7 (beim accept-Aufruf) wurde darauf hingewiesen, dass gewisse 

Systemaufrufe beim Auftreten eines Signals unterbrochen werden, damit die Signalhandler-Funktion 

ausgeführt werden kann. In diesem Fall liefert die entsprechende Funktion 

einen Fehler als Rückgabewert und setzt errno auf die Fehlernummer EINTR. Dies muss 

abgefangen werden, und die entsprechende Funktion dann erneut aufgerufen werden, 

wie z.B.: 

do { 

clearerr(lese_dz); /* Fehler-Flag löschen */ 

zeich = fgetc(lese_dz); 

} while (ferror(lese_dz) && errno == EINTR); /* getc bei EINTR neu starten */ 

if (ferror(lese_dz) 

fehler_meld(FATAL_SYS, "fgetc-Fehler"); 

Typische Funktionen, die durch Signale unterbrochen werden können und bei denen 

man EINTR abfangen sollte, sind: 

connect accept read write readv 

writev recvfrom sendto select poll 

Pufferung bei den Standard E/A-Funktionen 

In Kapitel 3.5 wurde die intern stattfindende Pufferung bei Standard E/A-Funktionen 

beschrieben. Wenn z.B. Voll- bzw. Zeilenpufferung eingestellt ist, so werden die entsprechenden 

Zeichen erst wirklich in das Socket geschrieben, wenn der Puffer voll ist bzw. 

ein Neuezeilezeichen vorkommt. Dies muss man beachten, denn sonst kann dies zu Problemen 

führen, dass die gesendeten Daten im Puffer bleiben und der Leseversuch auf der 

anderen Seite für immer blockiert ist, da er vergeblich auf ankommende Daten wartet. In 

solchen Fällen muss man die Daten aus den entsprechenden Puffer entweder mit fflush 

explizit in das Socket schreiben lassen oder aber mit setbuf bzw. setvbuf eine andere Pufferung 

für den entsprechenden Stream (FILE-Zeiger) einstellen. 

Beispiel zur Verwendung der Standard E/A-Funktionen bei Sockets 

Hier realisieren wir zunächst eine eigene Funktion mkadr, die die als String übergebene 

Host-Adresse adr_str (Domainame oder IP-Adresse) und das ebenfalls als String übergebene 

protocol in eine entsprechende Adressstruktur umwandelt, die es über den Parameter 

sa zurückliefert. Die Länge dieser Adressstruktur liefert mkadr über den Parameter 

salen. Diese Funktion mkadr wird wieder in die Programmdatei netzprog.c aufgenommen:


int mkadr(char *adr_str, char *protocol, void *sa, socklen_t *salen) { 

char *tmp_addr = strdup(adr_str); /* String 'adr_str' duplizieren */ 

char *host = strtok(tmp_addr, ":"); 

char *port = strtok(NULL, "\n"); 

struct sockaddr_in *sin = (struct sockaddr_in *)sa; 

struct hostent *hname = NULL; 

struct servent *sname = NULL; 

char *rest; 

long portnr; 

/*... Voreinstellungen evtl. setzen */ 

if (host == NULL) host = "*"; 

if (port == NULL) port = "*"; 

if (protocol == NULL) protocol = "udp"; 

/*... Initialisieren der Adressstrukturen */ 

memset(sin, 0, *salen); 

sin->sin_family = AF_INET; 

sin->sin_port = 0; 

sin->sin_addr.s_addr = htons(INADDR_ANY); 

/*... Host-Adresse füllen */ 

if (isdigit(*host)) { /*... Numerische Adresse */ 

if (inet_pton(AF_INET, host, &sin->sin_addr) h_addrtype != AF_INET) 

return -1; 

sin->sin_addr = *(struct in_addr *)hname->h_addr_list[0]; 

 

/*... Portnummer festlegen */ 

if (isdigit(*port)) { /*... Numerische Portnummer */ 

portnr = strtol(port, &rest, 10); 

if ( (rest != NULL && *rest) || (portnr < 0L || portnr >= 32768)) 

return -2; 

sin->sin_port = htons((short)portnr); 

} else if (strcmp(port,"*")) { /*... Symbolische Portnr. (nicht '*') */ 

if ( (sname = getservbyname(port, protocol)) == NULL) 

return -2; 

sin->sin_port = (short)sname->s_port; 

} 

*salen = sizeof(*sin); 

} 

free(tmp_addr); 

return 0; 

Für adr_str kann Folgendes angegeben werden: 

hostname:service


wobei für hostname Folgendes erlaubt ist: 

IP-Nummer, wie z.B. 127.0.0.1 

 

 

Domainname, wie z.B. www.fh-nuernberg.de 

ein * für wildcard (INADDR_ANY) 

Die Angabe des Doppelpunktes und des service ist optional. Ist service angegeben, muss 

auch der Doppelpunkt angegeben werden. Für service kann Folgendes angegeben werden: 

Portnummer, wie z.B. 8080 

Ein Service-Name, wie z.B. telnet 

ein * für die Portnummer 0; in diesem Fall wird vom bind-Aufruf eine entsprechende 

Portnummer zugeteilt. 

Beispiele möglicher Angaben für hostname:service sind: 

www.fh-nuernberg.de:8080 

127.0.0.1:telnet 

ftp.suse.de:ftp 

Unter Verwendung dieser Funktion mkadr realisiert das Programm 20.10 (server4.c) 

einen Server, dem man Zahlen bis 9999 in Textschreibweise schicken kann, und der dann 

die entsprechende Zahl dazu in numerischer Form ermittelt und zurückschickt. 

#include 


static char *bindeWort[] = { "und", "hundert" }; 

static char *bisZwanzig[] = { 

"ein", "eins", "zwei", "drei", "vier", 

"fünf", "sechs", "sieben", "acht", "neun", 

"zehn", "elf", "zwölf", "dreizehn", "vierzehn", 

"fünfzehn", "sechzehn", "siebzehn", "achtzehn", "neunzehn" }; 

static char *bis100[] = { "zwanzig", "dreissig", "vierzig", "fünfzig", 

"sechzig", "siebzig", "achtzig", "neunzig" }; 

static void server_antwort(char *zeile, FILE *dz); 

static int suche(int nr, char *string); 

int 


{ 

char 

*serv_adr="127.0.0.1:8765"; 

struct sockaddr_in adr_serv, adr_clnt; /* Server- und Clientadressstr. */ 

int 

len_inet; 

int serv_sock, clnt_sock; /* Server- und Clientsocket */ 

FILE *lese_dz, *schreib_dz; /* Lese-/Schreib FILE-Zeiger */


char puffer[MAX_ZEICHEN]; /* E/A-Puffer */ 

if (argc >= 2) 

serv_adr = argv[1]; 

len_inet = sizeof(adr_serv); 

if (mkadr(serv_adr, "tcp", &adr_serv, &len_inet) < 0 || 

adr_serv.sin_port == 0) 

fehler_meld(FATAL, "falsche Adresse oder Portnummer"); 

/*... Verbindungs-Socket erzeugen */ 

serv_sock = my_socket(PF_INET, SOCK_STREAM, 0); 

/*... Socket eine Protokolladresse zuordnen */ 

my_bind(serv_sock, (struct sockaddr *)&adr_serv, len_inet); 

/*... Socket in passiven Zustand für Verbindungsannahmen versetzen */ 

my_listen(serv_sock, 10); 

while (1) { 

/*... Verbindung von Client akzeptieren */ 

len_inet = sizeof(adr_clnt); /* Auf connect seitens Clients warten */ 

clnt_sock = my_accept(serv_sock, (struct sockaddr *)&adr_clnt, &len_inet); 

/*... FILE-Zeiger zum verbundenen Clientsocket anlegen */ 

if ( (lese_dz = fdopen(clnt_sock, "r")) == NULL || 

(schreib_dz = fdopen(clnt_sock, "w")) == NULL) 

fehler_meld(FATAL_SYS, "fdopen-Fehler"); 

/*... Zeilenpufferung für lese_dz und schreib_dz einstellen */ 

setvbuf(lese_dz, puffer, _IOLBF, sizeof(puffer)); 

setvbuf(schreib_dz, puffer, _IOLBF, sizeof(puffer)); 

while (fgets(puffer, sizeof(puffer), lese_dz) != NULL) 

server_antwort(puffer, schreib_dz); 

fclose(schreib_dz); /* Schreibzeiger schließen */ 

fclose(lese_dz); /* Lesezeiger schließen */ 

} 

exit(0); /* wird aufgrund der Endlosschleife nie ausgeführt */ 

} 

static void server_antwort(char *zeile, FILE *dz) { 

int ergeb=0, i=1; 

char *wort = strtok(zeile, " \r\t\n"); 

while (wort != NULL) { 

if (i % 2 == 0) 

ergeb *= suche(i, wort); 

else 

ergeb += suche(i, wort); 

i++; 

wort = strtok(NULL, " \r\t\n"); 

} 

fprintf(dz, " ===> %d\n", ergeb);


fflush(dz); 

} 

static int suche(int nr, char *string) { 

int i; 

if (nr%2==0) { 

for (i=0; i 92 

zwölf 

===> 12 

drei hundert sieben und ein und zwanzig 

===> 328 

drei hundert ein und zwanzig 

===> 321


^] [Eingabemodus beenden] 

telnet> c [telnet beenden] 

Connection closed. 


[1] Beendet server4 

$ 

20.3.10 Übung 

Paralleler Server, der Zeit in einem vom Client angeforderten Format schickt 

Erstellen Sie ein paralleles Serverprogramm (tageszeit.c) und ein zugehöriges Clientprogramm 

(client.c). Das Clientprogramm soll dabei dem Serverprogramm einen entsprechenden 

Zeitformat-String (man strftime) schicken, den das Serverprogramm mit der 

aktuellen Zeit entsprechend dem geschickten Zeitformat-String füllt, und dem Client 

zurückschickt, der diese empfangene Zeit dann nur noch ausgibt. Zusätzlich soll das 

Clientprogramm noch die Mikrosekunden der aktuellen Zeit mit gettimeofday ermitteln 

und ausgeben. 

Nachdem man den Server im Hintergrund gestartet hat mit 

$ ./tageszeit & 

.... 

$ 

könnte man das folgende bash-Skript verwenden, das 100 Clientanforderungen an den 

Server schickt: 

i=1 

while [ "$i" -le 100 ] 

do 

./client 127.0.0.1 9876 & 

i=$(expr $i + 1) 

done 

so dass sich z.B. die folgende Ausgabe ergibt: 

$ ./clients 

064.Tag des Jahres; 12:50:09 (0.408) 

Thursday; 04.03.04; 12:50:09 (0.420) 

Thursday; 04.03.04; 12:50:09 (0.432) 

Thursday; 04.03.04; 12:50:09 (0.443) 

064.Tag des Jahres; 12:50:09 (0.468) 

Thursday; 04.03.04; 12:50:09 (0.480) 

064.Tag des Jahres; 12:50:09 (0.492) 

...... 

Thursday; 04.03.04; 12:50:10 (0.902) 

Thursday; 04.03.04; 12:50:10 (0.922) 

064.Tag des Jahres; 12:50:10 (0.942) 

064.Tag des Jahres; 12:50:10 (0.963) 

Thursday; 04.03.04; 12:50:10 (0.983) 

$


Kopieren von Dateien über TCP-Sockets 

Erstellen Sie ein Serverprogramm copysrv.c, das an einem Socket auf das Ankommen 

von Daten wartet, diese liest und in eine Datei datei_1 schreibt. Wird das Socket seitens 

des Clientprogramms copycli.c, das die Daten schickt, geschlossen, wartet der Server auf 

eine neue Verbindungsanforderung seitens des Clients. Die dann hier geschickten Daten 

schreibt das Serverprogramm in eine Datei datei_2 usw. 

Beim Serverprogramm muss man als Argument die IP-Adresse und Portnummer angeben, 

was auch für das Clientprogramm zutrifft, dem man aber zusätzlich als weitere 

Argumente die Namen der zu kopierenden Dateien auf der Kommandozeile mitteilen 

muss. 

Nachdem man diese beiden Programme kompiliert und gelinkt hat: 

cc -o copysrv copysrv.c netzprog.c fehler.c 

cc -o copycli copycli.c netzprog.c fehler.c 

kann man sie testen, wie es z.B. nachfolgend gezeigt ist. 

Ablaufbeispiel am lokalen Rechner 

Zunächst startet man das Serverprogramm in einem Terminalfenster: 

$ ./copysrv 127.0.0.1:8765 

In einem anderen Terminalfenster ruft man dann das Clientprogramm auf: 

$ ./copycli 127.0.0.1:8765 iban.txt route.txt test.txt 

...Datei 'iban.txt' (51 Bytes) geschickt 

...Datei 'route.txt' (256 Bytes) geschickt 

...Datei 'test.txt' (44235082 Bytes) geschickt 

$ 

Im Terminalfenster des Servers erscheinen nun folgende Meldungen: 

...Datei 'datei_1' (51 Bytes) von '127.0.0.1' 



Startet man das Clientprogramm wiederum in einem anderen Terminalfenster, wie z.B.: 

$ ./copycli 127.0.0.1:8765 ping.txt s819.txt 

...Datei 'ping.txt' (769 Bytes) geschickt 

...Datei 's819.txt' (1121 Bytes) geschickt 

$ 

erscheinen im Terminalfenster des Servers folgende Meldungen: 



Strg-C 

$

20.4 Elementare UDP-Socket-Funktionen 709 

Ablaufbeispiel, wo Dateien von einem entfernten Rechner geschickt werden 

Zunächst startet man das Serverprogramm am lokalen Rechner: 

$ ./copysrv 192.168.69.6:7777 

Nun startet man das Clientprogramm an einem entfernten Rechner, wie z.B.: 

Rechner birne $ ./copycli 192.168.69.6:7777 abakus.pdf sortalgo.pdf 

...Datei 'abakus.pdf' (242394 Bytes) geschickt 

...Datei 'sortalgo.pdf' (152177 Bytes) geschickt 

Rechner birne $ 

Es erscheinen dann im Terminalfenster des Servers am lokalen Rechner folgende Meldungen: 



Strg-C 

$ 

20.4 Elementare UDP-Socket-Funktionen 

Während es sich bei TCP um ein verbindungsorientiertes, zuverlässiges Stream-Protokoll handelt, 

ist UDP ein verbindungsloses, unzuverlässiges Datagram-Protokoll. Hier werden die elementaren 

UDP-Socket-Funktionen beschrieben, die für eine UDP-Client/Server-Realisierung 

benötigt werden. 

20.4.1 Überblick 

Abbildung 20.6 zeigt die elementaren Socket-Funktionen, die bei einer typischen UDP- 

Client/Server-Realisierung benötigt werden. Anders als bei TCP baut der Client bei UDP 

keine Verbindung mit dem Server auf. Statt dessen sendet der Client mit sendto nur ein 

Datagramm an den Server, das die Adresse des Ziels, nämlich des Servers, enthält. 

Ebenso baut auch der Server keine Verbindung zum Client auf, sondern ruft statt dessen 

die Funktion recvfrom auf, die wartet, bis Daten (Datagramme) von irgendwelchen 

Clients eintreffen. recvfrom liefert dabei die Protokolladresse des Clients zusammen mit 

dem Datagramm zurück, so dass der Server den Absender kennt und seine Antwort an 

den richtigen Client zurückschicken kann. 

Bei einer verbindungslosen Kommunikation wird der Server meist iterativ implementiert: 

Er empfängt eine Anforderung nach der anderen und schickt die Antworten an die 

entsprechenden Clients zurück. Hierbei ist es nicht wichtig, ob mehrere Anfragen vom 

gleichen Client oder aber von unterschiedlichen Clients stammen. Aber auch beim UDP- 

Protokoll gilt, dass ein iterativer Server nur geeignet ist, wenn der Server nicht zu lange 

für die Bearbeitung einer Anforderung benötigt.

20.3 Elementare TCP-Socket-Funktionen - Pearson Bookshop

Verwandeln Sie Ihre PDFs in ePaper und steigern Sie Ihre Umsätze!

Template löschen?

Als Template speichern ?