lecture-notes/inputs/network_programming/sockets.tex

\subsection{Einführung zu Sockets}

Das \vocab[Generisches API]{Generische API}
\begin{itemize}
  \item unterstützt \vocab[Nachrichten-orientiert]{Nachrichten-orientierte} und \vocab[Verbindungs-orientiert]{Verbindungs-orientierte} Kommunikation.
  \item ist betriebssystemunabhängig
  \item nutzt I/O Dienste des Betriebssystems
  \item unterstützt verschiedene Protokollfamilien
  \item ist unabhängig von der konkreten Adress-Repräsentation der kommunizierenden Endpunkte
  \item unterstützt ggf.~manche Clients und Server auf spezielle Weise
\end{itemize}

Es gibt verschiedene APIs für den Zugriff auf TCP / IP:
\begin{itemize}
  \item (Berkeley-) Sockets, diese werden wir uns genauer ansehen
  \item TLI (System V Transport Layer Interface)
  \item XTI (X/Open Transport Interface)
  \item Winsock
  \item MacTCP
  \item Asio C++ Library (plattformunabhängig)
\end{itemize}

\subsubsection{Benötigte Funktionen des Network API}
Ein Network API stellt grundsätzlich Folgendes zur Verfügung:

Vorbereitung:
\begin{itemize}
  \item Identifikation der beiden Endpunkte der Kommunikation
  \item Verbindungsaufbau (ggfs.~kein Verbindungsaufbau, d.h.~verbindungslos)
  \item Warten auf eingehende Verbindungswünsche (typisch für Server)
\end{itemize}

Datentransferphase:
\begin{itemize}
  \item Senden und Empfangen von Daten
  \item Fehlerbehandlung
\end{itemize}

Nachbereitung:
\begin{itemize}
  \item Ordentlicher Abbau einer Verbindung
  \item ggf.~Fehlerbehandlung
\end{itemize}

\subsubsection{Berkeley-Sockets}
\vocab{Berkeley-Sockets} stammen ursprünglich aus Berkeley-Unix, mittlerweile werden sie einfach Sockets genannt.
Diese werden wir uns genauer ansehen.

Ein Socket ist eine Datenstruktur innerhalb eines Programms und stellt eine \emph{abstrakte Repräsentation} eines kommunizierenden Endpunktes
dar.
Sockets sind durch Systemfunktionen implementiert und arbeiten ähnlich wie andere Unix I/O-Dienste.
Sockets unterstützen verschiedene Protokollfamilien und sind insbesondere unabhängig von der konkreten Adressdarstellung.

\subsubsection{Socket framework}

Mit einem Socket können wir vom User Space aus auf Funktionalität des Kernel Space, insbesondere
TCP oder UDP, und damit indirekt auf IP und Netzwerktreiber zugreifen. Der direkte Zugriff auf \ac{ip} benötigt in der Regel
privilegierte Rechte.

\subsubsection{Unix Descriptor Table}
Unix führt eine \vocab{Descriptor Table}, die jeweilige Datenstrukturen enthält (siehe auch \autoref{descriptortable}). 
Dieser kann sowohl Dateideskriptoren (wie bereits kennengelernt), als auch Socket
Descriptoren enthalten.

Ein \vocab{Socket Descriptor} ist ein normaler File Descriptor, dessen Eintrag in der Descriptor Table jedoch eine Address-Family, einen Service, Local IP, Remote IP, Local Port und Remote Port enthält.



\subsubsection{Socket Domain Families}

Die \vocab{Protokollfamilie} eines Sockets muss bei Initialisierung festgelegt werden.
Es gibt die folgenden Schlüssel:

\begin{itemize}
  \item \vocab{Internet Domain Sockets}, verfügbar mittels \ccintro{AF_INET}
  \item \vocab{Unix Domain Sockets}, mittels \ccintro{AF_UNIX} oder \ccintro{AF_LOCAL}
  \item \vocab{Novell IPX}, mittels \ccintro{AF_IPX}
  \item \vocab{AppleTalk} (buuuuh!), mittels \ccintro{AF_APPLETALK} 
\end{itemize}

\begin{remark}
  Beachte, dass alle diese macros mit \code{AF_} beginnen, dies steht für \enquote{address family}.
  Mittlerweile wird allerdings nicht mehr zwischen Protokollfamilien und Adressfamilien unterschieden.
\end{remark}

\subsubsubsection{Service Typ eines Sockets}
Ein Socket kann einen von drei Typen haben
\begin{description}
  \item[Stream]
    Schlüssel \ccintro{SOCK_STREAM}, Verbindungs- und Byte-Stream orientiert.
    Unter \code{AF_INET} wird \ac{tcp} eingesetzt. 
  \item[Datagram]
    Schlüssel \ccintro{SOCK_DGRAM}, verbindungslos und unzuverlässig.
    Unter \code{AF_INET} wird \ac{udp} eingesetzt.
\item[Direktzugriff]
    Schlüssel \ccintro{SOCK_RAW}.
    Dieser umgeht das Transportprotokoll und greift direkt auf das Kommunikationsprotokoll (im Fall von \code{AF_INET}  \ac{ip}) zu.
    In der Regel werden spezielle Rechte benötigt.
\end{description}


Die letzte Möglichkeit besteht zwar, erfordert allerdings viel aufwand,
weil IP selbst nicht ports spezifiziert (das machen \ac{udp}  / \ac{tcp} ),
und dies somit manuell geschehen muss.
Anwendung findet dies in speziellen Routern oder eigenen Protokollen.

\autoref{tab:protokollfamilien} zeigt die Protokollfamilien und den  Service-Typ eines sockets,
und die entsprechenden Protokolle, die verwendet werden.

\begin{table}[htpb]
  \centering
  \begin{tabular}{c | c | c | c | c | c}
  & \cc{AF_INET} & \cc{AF_INET6} & \cc{AF_LOCAL}, \cc{AF_UNIX} & \cc{AF_ROUTE} & \cc{AF_KEY} \\
  \hline
    \cc{SOCK_STREAM} & \ac{tcp} & \ac{tcp} & Ja & & \\
    \cc{SOCK_DGRAM} & \ac{udp} & \ac{udp} & Ja & & \\
    \cc{SOCK_RAW} & IPv4 & IPv6 & & Ja & Ja
  \end{tabular}
  \caption{Kombinationsmöglichkeiten von Protokollfamilie und Socket Type für Internetprotokolle}
  \label{tab:protokollfamilien}
\end{table}


\subsubsubsection{Erzeugung eines Sockets}
Vergleiche für die beiden Parameter auch \autoref{tab:protokollfamilien} 

Das Erzeugen eines sockets geschieht mit \ccintro{socket()}.

\begin{lstlisting}[gobble=2]
  #include <sys/types.h>
  #include <sys/socket.h>

  int socket(int domain, int type, int protocol);
  // domain gibt die Protokollfamilie an: AF_INET, AF_INET6, AF_LOCAL, ...
  // type gibt SOCK_STREAM, SOCK_DGRAM oder SOCK_RAW an
  // protocol setzt spezielle Werte im Protokoll-feld
  // wird aber bei TCP und UDP automatisch behandelt, und deswegen auf 0 gesetzt.

// Rueckgabewerte: ein socketdeskriptor, -1 im Fehlerfall
\end{lstlisting}

Solch ein Socket stellt nun abstrakte Ressourcen bereit, um zu kommunizieren,
kümmert sich jedoch noch nicht um Adressierung etc.

Um einen Socket zu benutzen, um empfangsbereit zu sein, verwendet man:

\begin{lstlisting}[gobble=2]
  #include <sys/types.h>
  #include <sys/socket.h>

  int bind(int sockfd, const struct sockaddr *myaddr, socklen_t addrlen);
  // sockfd: der behandlete socket file deskriptor
  // myaddr: ein Zeiger auf eine (generische) Adresse
  // addrlen: Laengenangabe des Adress-structs unter @myaddr

  // gibt -1 im Fehlerfall zurueck, 0 sonst
\end{lstlisting}

\subsubsubsection{Socket-Adressen}

Ein \ccintro{struct sockaddr} sieht wie folgt aus:

\begin{lstlisting}[gobble=2]
  typedef uint16_t sa_family_t;
  
  struct sockaddr {
    sa_family_t sa_family;    // address family
    char        sa_data[14];  // up to 14 bytes of direct address
  }
\end{lstlisting}

% \todoquestion{sehe ich das richtig, dass sowohl der socket als auch der addr die adressfamilie bekommen müssen?} Ja. Siehe https://stackoverflow.com/questions/5263262/why-does-struct-sockaddr-contain-a-address-family-field

\begin{remark}
  Auf manchen Betriebssystemen gibt es noch ein \ccintro[sin_len]{uint8_t sin_len}
  im \cc{struct sockaddr}, das interessiert uns jedoch ersteinmal nicht.
\end{remark}

\begin{table}[htpb]
    \centering
    \caption{Typen}
    \label{tab:types}
    \begin{tabular}{lll}
    \textbf{Datentyp} & \textbf{Beschreibung} & \textbf{Header}   \\
    \hline
    \ccintro{int8_t}, \ccintro{int16_t} & signed integer ($8 / 16 / 32 / 64$ bit) &  \code{sys/types.h}\\    
    \ccintro{int32_t},\ccintro{int64_t} \\    
    \ccintro{uint8_t}, \ccintro{uint16_t} & unsigned integer ($8 / 16 / 32 / 64$ bit) &  \code{sys/types.h}\\    
    \ccintro{uint32_t}, \ccintro{uint64_t}\\ 
    \hline
    \multirow{2}*{\ccintro{sa_family_t}} & address family of socket address structure,& \multirow{2}*{\code{sys/socket.h}} \\
                                        & normally \cc{uint16_t}& \\  
    \multirow{2}*{\ccintro{socklen_t}} & length of socket address structure,&\multirow{2}*{\code{sys/socket.h}} \\
                                       &  normally \cc{uint32_t} &\\ 
    \hline
    \ccintro{in_addr_t} & IPv4 address, normally \cc{uint32_t} & \code{netinet/in.h} \\
    \ccintro{in_port_t} & TCP or UDP port, normally \cc{uint16_t} & \code{netinet/in.h}\\  
    \ccintro{struct in6_addr} & IPv6 address & \code{netinet/in.h} 

    \end{tabular}
\end{table}

Die Adressen der Internet-Protokollfamilie sehen wie folgt aus:

\begin{lstlisting}
  struct in_addr {
    in_addr_t s_addr;   // 32 bit IPv4 address
  }

  struct sockaddr_in {
    sa_family_t sin_family;  // here: AF_INET
    in_port_t sin_port;      // 16-bit TCP / UDP port number. network byte order!
    struct in_addr sin_addr; // 32 bit IPv4 address. network byte order!
    char sin_zer[8];         // unused, total size 16 bytes
};
\end{lstlisting}

Das \cc{struct sockaddr_in} wird somit auf ein \cc{struct sockaddr} gecastet,
um an \cc{socket()} übergeben zu werden.

Unser socket enthält somit bereits IP-Adresse, Protokoll-Type und Portnummer,
um einen verbindungsaufbau zu ermöglichen.

\subsubsubsection{Network byte order}

Die Werte \cc{sin_port} sowie \cc{sin_addr} müssen in der sogenannten
\vocab{network byte order} abgelegt sein.

Das liegt daran, dass verschieden Systeme \vocab{Little Endian} oder \vocab{Big Endian}
benutzen können, und wir für die Netzwerkübertragung eine einheitliche Darstellung benötigen.

Die \vocab{Host Byte Order} ist die byte order des hosts. 

\begin{definition}
  Die \vocab{Network Byte Order} ist als Big Endian definiert. 
\end{definition}

\begin{warning}
  Beim spezifizieren von Netzwerk-Parametern müssen wir also auf die Endianness achten!
\end{warning}

Hierzu stehen folgende Hilfsfunktionen zur Verfügung:

\begin{lstlisting}
  uint16_t htons(uint16_t hostshort);
  uint32_t htonl(uint32_t hostlong);
  uint16_t ntohs(uint16_t netshort);
  uint32_t ntohl(uint32_t netlong);
\end{lstlisting}

Hierzu werden die Abkürzungen \emph host, \emph network, \emph short und \emph long benutzt.

\subsubsubsection{Komplettbeispiel: Öffnen eines sockets mit \ac{udp}}

\begin{lstlisting}[gobble=2]
  int fd, err;
  struct sockaddr_in addr;

  fd = socket(AF_INET,SOCK_DGRAM,0);
  if (fd<0) { ... }   // error handling

  addr.sin_family = AF_INET;
  addr.sin_port = htons(4711);
  addr.sin_addr.s_addr = htonl(INADDR_ANY);

  err = bind(fd, (struct sockaddr *) &addr,  sizeof(struct sockaddr_in));
  if (err<0) { ... }   // error handling
\end{lstlisting}

\begin{remark}
  Das macro \ccintro{INADDR_ANY} gibt an, dass das Betriebssystem die IP-Adresse
  automatisch bestimmt, und zwar die des eigenen Rechners.

  Analog kann auch die Portnummer als 0 spezifiziert werden,
  dann kümmert sich das Betriebssystem automatisch darum,
  einen geeigneten Port zuzuweisen. Diese ist $> 1023$.
\end{remark}

\subsubsubsection{Weitere Socket-Adress-Strukturen}

Die structs for die IPv6-Familie oder für Unix-Domain Sockets können auch
deutlich länger als 16 Byte sein. Deswegen ist die übergabe der Länge
des struct essentiell.


\subsubsubsection{Kommunikation über Sockets mit \ac{udp}}

Wir kennen bereits \code{socket()} und \code{bind()}.
Um nun zwischen Client und Server zu kommunizieren,
führt üblicherweise nur der Server ein \code{bindto()} aus,
und wartet mit \code{recvfrom()} auf eingehende Datagramme.

Mit \code{sendto()} können nun sowohl client als auch Server
Datagramme verschicken.
Auch der Client kann nun mit \code{recvfrom()} Daten empfangen.

Typischerweise befinden sich nun Client und Server in einem
Zyklus aus \vocab{Empfangen}, \vocab{Verarbeiten}, \vocab{Beantworten}.

Mit \code{close()} kann der Socket am Ende geschlossen werden.

\begin{warning}
  Es ist sehr wichtig, den Socket am Ende wieder zu schließen,
  sonst bleibt der Port auch über das Programmende eine
  gewisse Zeit im kernelspace, weil Sockets (grundsätzlich)
  kernel-persistence besitzen.
  
  Der Kernel schließt den socket allerdings nach einer
  gewissen Zeit ($\approx$ 1min.), das kann jedoch bereits
  nervig sein.
\end{warning}
\todoquestion{kann ich einen bestehenden socket übernehmen?}


\subsubsubsection{\code{sendto()}}

Der Aufruf von \code{sendto()} hat die Signatur:

\begin{lstlisting}[gobble=2]
  #include <sys/types.h>
  #include <sys/socket.h>

  int sendto(int sockfd, const void *buff, size_t nbytes,
             int flags, const struct sockaddr *to, socklen_t tolen);

    // sockfd: file descriptor des sockets
    // buff:   zu sendender Buffer
    // nbytes: Anzahl zu sendender Bytes
    // flags:  Optionen, spaeter behandlet
    // to:     Zeiger auf Zieladress-Struktur
    // tolen:  Laenge der Ziel-Adressstruktur
    // return: -1 bei Fehler, sonst Anzahl gesendeter Bytes
\end{lstlisting}


\begin{example}[Senden von Daten]
  \label{ex:senden-von-daten-udp}
  \begin{lstlisting}[gobble=2]
    // nimm an, dass wir den socket sockfd bereits erstellt haben
    // (nicht zwingend gebinded)

    char msg[64];
    int err;
    struckt sockaddr_in dest;

    strcpy(msg, "hello, world!");

    dest.sin_family = AF_INET;
    dest.sin_port   = htons(4711);
    dest.sin_addr.s_addr = inet_addr("130.37.193.13");

    err = sendto(
          sockfd, msg, strlen(msg) + 1, 0,
          (struct sockaddr*) &dest, sizeof(struct sockaddr_in)
    );
    if (err < 0) { ... } // Fehlerbehandlung

    ...
  \end{lstlisting}
\end{example}

\begin{remark}
  Man sollte auf jeden Fall den Fehlerstatus überprüfen.
  Die Anzahl der gesendeten bytes sollte vor allem dann
  überprüft werden, wenn man potenziell zu viele bytes
  gesendet hat.
\end{remark}

\subsubsubsection{Hilfsfunktionen für \ac{ip}-Adressen}

\ac{ip}-Adressen werden zur Verbesserung der Lesbarkeit üblicherweise
als \vocab{Dotted-Decimal-Schreibweise} durch 4 Dezimalzahlen dargestellt,
die jeweist 8 bit, also Zahlen von $0$ bis $255$.

Es stehen zwei Hilfsfunktionen zur Verfügung:

\begin{lstlisting}
  #include <arpa/inet.h>

  in_addr_t inet_addr(const char *dotted);  // Conversion of dotted address to in_addr_t
  char *inet_ntoa(struct in_addr network);  // Conversion of in_addr_t to dotted
\end{lstlisting}

\begin{warning}
  Der Aufruf von \code{inet_ntoa} returned die Adresse in einem
  statisch allokierten Buffer, der bei weiteren Aufrufen überschrieben wird.

  Damit ist der Aufruf insbesondere \alert{nicht} thread-safe.
\end{warning}

\begin{remark}[Der Vollständigkeit halber]
  Es gibt auch \code{inet_aton(const char *cp, struct in_addr *inp)},
  die ebenfalls von der dotted schreibweise konvertiert,
  und das Ergebnis im entsprechenden struct ablegt.

  Man hätte also in \autoref{ex:senden-von-daten-udp} auch folgendes schreiben
  können:

  \begin{lstlisting}
    // dest.sin_addr.s_addr = inet_addr("130.37.193.13");
    char dest_addr[15] = "130.37.193.13";
    inet_aton( &dest_addr, &dest.sin_addr );
  \end{lstlisting}
\end{remark}


\subsubsubsection{\code{recvfrom()} - Empfangen von Daten}

\begin{lstlisting}
  #include <sys/types.h>
  #include <sys/socket.h>

  int recvfrom(int sockfd, void *buff, size_t nbytes,
  int flags, struct sockaddr *from, socklen_t *fromlen);

  // sockfd: File Deskriptor des sockets
  // buff:   buffer fuer zu empfangende daten
  // nbytes: laenge des buffers
  // flags:  optionen, standard 0 (weiter spaeter)
  // from:   zeiger auf socket-adress-strucktur mit quelladresse (port + ip-adresse)
  // fromlen: Zeiger auf lange der adress-struktur.

  //return: -1 bei fehler, sonst laenge der empfangenen daten

  // das argument fromlen ist ein value-return argument, d.h.
  // es wird bei erfolgreichem funktionsaufruf geupdatet,
  // und zwar auf die tatsaechliche laenge der 
  // struct sockaddr *from struktur
  // war diese laenger als die urspruengliche eingabe von fromlen
  // wird die from - addresse abgeschnitten,
  // und fromlen auf den entsprechend groesseren wert
  // gesetzt
\end{lstlisting}

\begin{remark}
  Mit Quelle ist hierbei nicht gemeint, dass man \emph{nur} Datagramme
  von dieser Quelle akzeptiert.
  Diese ist unspezifiziert, die Quelladresse wird jedoch
  im \code{struct sockaddr *from} abgelegt.

  Der Aufruf von \code{recvfrom()} blockiert (im Normalfall),
  bis Daten empfangen wurden.

  Man kann \code{from} und \code{fromlen} auch auf \code{NULL} setzen,
  dann wird die Sender-Adressstruktur nicht gespeichert.
  Stattdessen kann man auch einfach \code{recv()} aufrufen,
  das die beiden argumente nicht erwartet.
\end{remark}

\begin{example}[Beispiel von \code{recvfrom()}]
\begin{lstlisting}[gobble=4]
    char msg[64];
    int len, flen;
    struck sockaddr_in from;

    flen = sizeof(struct sockaddr_in);

    len = recvfrom(
            sockfd, msg, sizeof(msg), 0,
            (struckt sockaddr*) &from, &flen);

    if (len < 0) { ... } // fehlerbehandlung

    printf("Received %d bytes from host %s with port %d: %s",
           len, inot_ntoa(from.sin_addr), ntohs(from.sin_port), msg);

  \end{lstlisting}
\end{example}

\begin{warning}
  Das obige Beispiel ist natürlich Sicherheitstechnisch völlig grauenhaft.
  Wenn wir nicht gerade einen string bekommen haben, könnte das
  printen mittels '\%s' der erhaltenen nachricht unseren gesamten speicher
  leaken / segfaulten / \ldots
\end{warning}

\begin{warning}
  Die manpage behauptet, dass überschüssige Daten eines Datagrammes,
  das zu lange für den angegebenen Buffer ist, je nach sockettyp
  verworfen werden können.

  In der Vorlesung wurden 2 Euro verwettet, weil fälschlicherweise
  geclaime wurde, 
  dass dies bei UDP nicht der Fall ist,
  mit einem weiteren \code{recvfrom()} kann dann der Rest der Nachricht
  abgerufen werden.

  UDP verliert überschüssige Daten.
\end{warning}


\subsubsubsection{Schließen eines sockets}

Funktioniert gleich wie bei files:

\begin{lstlisting}
  #include <unistd.h>

  int close(int sockfd);
\end{lstlisting}

\subsection{Kommunikation über Sockets mit \ac{tcp}}

Da \ac{tcp} ein Verbindungsorientiertes Protokoll ist,
sieht die Kommunikation etwas anderst aus.

Für einen Server stehen \code{listen()} und \code{accept()}
zur Verfügung, um auf eingehende Verbindungswünsche zu hören,
und sie zu akzeptieren.

Der Client verwendet \code{connect()}, um eine Verbindung aufzubauen.

Besteht die Verbindung, so stehen \code{read()} und \code{write()}
auf beiden Seiten zur Verfügung.

Mit \code{close()} schließt der Client die Verbindung,
dies kann beim server beim nächsten \code{read()} erkannt werden.

\todoimg{3.2 - 70}

\subsubsubsection{Servervorbereitung bei \ac{tcp}}

Nachdem ein Socket mit \code{socket()} erstellt und mit \code{bind()}
gebinded wurde, versetzt man ihn mit \code{listen()} in einen aktiven
Zustand, d.h.~dieser wartet auf Verbindungsaufbauten

\begin{lstlisting}
  #include <sys/socket.h>
  
  int listen(int sockfd, int backlog);

  // sockfd:  socket file deskriptor
  // backlog: maximale anzahl gleicher verbindungsaufbauten. typisch: 5

  //return: -1 bei fehler, 0 bei erfolg
\end{lstlisting}

\begin{remark}
  Der Parameter \code{backlog()} beschränkt nicht die Anzahl der möglichen
  Verbindungen, nur die Anzahl derjenigen, die
  eine Verbindung aufbauen, aber noch nicht akzeptiert wurden.
\end{remark}

\subsubsubsection{Clientvorbereitung bei \ac{tcp}}

Nachdem der client mit \code{socket()} einen socket erstellt hat,
kann er mit \code{connect()} einen Verbindungsaufbau beginnen.

\begin{lstlisting}
  #include <sys/types.h>
  #incldue <sys/socket.h>

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

  // sockfd: sockt file deskriptor
  // serv_addr: zeiger auf adresse des servers (die enthaelt ip + port)
  // addrlen: leange der adress struktur

  // return: -1 bei fehler, 1 bei erfolg
\end{lstlisting}


\subsubsubsection{Server: Akzeptieren von Verbindungen bei \ac{tcp}}

Hierzu steht \code{accept()} zur Verfügung.

\begin{lstlisting}
  #include <sys/types.h>
  #include <sys/socket.h>

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

  // sockfd: socket file deskriptor
  // addr: zeiger auf adress-struktur
  // addrlen: laenge der adress-struktur

  // return: *neuer* socket-deskriptor, der die verbindung darstellt,
  //         -1 bei Fehler
\end{lstlisting}

Auch hier wird \code{addrlen} als value-return dynamisch angepasst.

\begin{example}
\begin{lstlisting}[gobble=4]
    int sockfd, newsock, res;
    sockaddr_in client_addr;
    socklen_t addrlen;

    res = listen(sockfd,5);
    if (res<0) { ... } // fehlerbehandlung

    addrlen = sizeof(struct sockaddr_in);
    newsock = accept(sockfd,(struct sockaddr *) &client_addr, &addrlen);

    if (newsock < 0) { ... }
    else {
      printf("Received connection from %s!\n", inet_ntoa(client_addr.sin_addr);
    }
  \end{lstlisting}
\end{example}

\subsubsubsection{Schwebezustand im Verbindungsaufbau}
\todoimg{3.2 - s.76}

Führt ein Client \code{connect()} aus, so findet ein sog. 3-Wege-Handshake
statt.
Nach dem 2. Handshake kehrt \code{connect()} zurück.
Nach dem 3. Handshake kehrt ein evtl. vorhandener \code{accept()}
Aufruf unmittelbar zurück.

\begin{remark}
  Wir werden später betrachten, wie ein Server mit mehreren
  Verbindungen umgehen kann.
\end{remark}

\subsubsubsection{Senden von Daten bei \ac{tcp}}

Der Aufruf ist ähnlich wie der von \code{sendto()} im Falle von \ac{udp}.

\begin{lstlisting}
  #include <unistd.h>

  ssize_t write(int sockfd, const void *buff, size_t count);

  // sockfd: File deskriptor des sockets
  // buff: zu sendender buffer
  // count: laenge der zu sendenden daten

  // return: -1 bei fehler, sonst anzahl gesendeter bytes
\end{lstlisting}

\begin{remark}
  Die Anzahl der gesendeten bytes kann durchaus weniger als \code{count} sein.

  Mas sollte deswegen immer den Rückgabewert prüfen und ggfs.~restliche Daten
  erneut senden.
\end{remark}


\subsubsubsection{Empfangen von Daten bei \ac{tcp}}
Hierzu gibt es \code{read()}

\begin{lstlisting}[gobble=2]
  #include <unistd.h>

  ssize_t read(int sockfd, void *buff, size_t count);

  // sockfd: file deskriptor des sockets
  // buff: buffer, in den gelesen wird
  // count: groesse des buffers

  // return: -1 bei felher
  //         0: sonderfall: kennzeichnung von end of file
  //         >0 anzahl der empfangenen bytes
\end{lstlisting}


\begin{remark}
  Der Rückgabewert von \code{read()} kann natürlich kleiner als \code{count()} sein.

  Der return value $0$ für EOF signalisiert den Wunsch auf Verbindungsabbau,
  d.h.~der Kommunikationspartner hat \code{close()} aufgerufen.
\end{remark}


\subsubsubsection{Aufruf von \code{close()}}

\code{close()} \vocab{markiert} einen Socket zum schließen.
Erst wenn alle existierenden file-deskriptoren des sockets
geschlossen wurden, schließt das Betriebssystem diesen tatsächlich.

Bereits an den socket übergebene, aber von \ac{tcp} noch nicht
versendete Daten gehen beim schließen \emph{nicht} verloren.

\begin{remark}
  Es ist möglich, dass ein Prozess mit bestehender \ac{tcp}-Verbindung
  \code{fork()} aufruft, und der parent die verbindung schließt.
  Das child kann weiterhin die Verbindung nutzen.
\end{remark}

\subsubsubsection{Alternative zu \code{close()}: \code{shutdown()}}

Mit \code{shutdown()} kann man einseitig eine Verbindung schließen.

\begin{lstlisting}
  #include <sys/socket.h>

  int shutdown(int sockfd, int howto);
\end{lstlisting}

\code{howto} ist hierbei eines von \code{SHUT_RD}, \code{SHUT_WR} oder \code{SHUT_RDWR},
die kanonisch nur read, nur write, oder beide Teile der Verbindung schließen können.


\subsubsection{Sockets in Rust}

Wir geben einen groben Überblick über sockets in Rust,
um die Analogien auch über Programmiersprachen hinweg zu geben.


\subsubsection{Übersicht der Adressen bei \ac{udp}}

\todoimg{3.2 - 93, 94}

\subsubsection{Übersicht der Adressen bei \ac{tcp}}

\todoimg{3.2 - 95, 96}

\subsubsection{Hilfsfunktionen bei \ac{tcp} und \ac{udp}}

\ac{udp} und \ac{tcp} bestimmen die Adressen in der Regel automatisch,
dies umfasst

\begin{itemize}
  \item Portnummer beim Client
  \item IP-Adresse beim Client
  \item IP-Adresse beim Server
  \item ggfs.~Portnummer beim SEvrer
\end{itemize}

Die konkreten Adressen kann man mit \code{getsockname()} und \code{recvmsg()}
selbst auslesen.

Dies sollen hier jedoch nicht näher betrachtet werden.