UNIX PROGRAMMING

- SUSHANT PAUDEL
OUTLINE
• Sockets Introduction
• Socket Address Structures
• Values Result arguments
• Byte ordering and Manipulation functions
• Fork and exec functions
• Concurrent Servers
• UNIX /INTERNET domain socket
• Socket System Calls
WHAT IS UNIX PROGRAMMING?
UNIX
• Unix is an operating system that was developed in the
1970s
• It is known for its stability, security, and versatility.
• It is widely used in servers, workstations, and embedded
systems.
• Unix provides a command-line interface (CLI) where users
can interact with the system using commands and scripts.
KEY CONCEPTS AND COMPONENTS OF UNIX
PROGRAMMING
• Shell: The Unix shell is a command-line interpreter that allows users to interact with the operating
system. It provides a command prompt where users can enter commands to perform tasks, execute
programs, and manipulate files and directories.
• Programming Languages: Unix supports various programming languages, including C, C++, Python,
Perl, and Shell scripting languages like Bash. These languages are commonly used to develop
applications and scripts for Unix systems.
• Networking: Unix systems have built-in support for networking, allowing programmers to develop
applications that communicate over networks. This includes creating network sockets, establishing
connections, and exchanging data using protocols such as TCP/IP.
• Tools and Utilities: Unix provides a rich set of tools and utilities that aid in programming and
development. These include compilers, debuggers, text editors (such as vi or emacs), version control
systems (such as Git), and various command-line tools for tasks like text processing, file manipulation,
and system administration.
SOCKET ADDRESS STRUCTURE
● A socket address structure is a special structure that stores the
connection details of a socket.
● It mainly consists of fields like IP Address, Port Number and Protocol
family.
● Socket Address Family determines the format of the address structure
○ Members of AF_INET address family are IPv4 addresses.
○ Members of AF_INET6 address family are IPv6 addresses.
○ Members of AF_UNIX address family are names of Unix domain sockets
○ Members of AF_IPX address family are IPX addresses, and so on.
● The name of each socket starts with socketaddr_ followed by its unique
name.
SOCKET
● Sockets allow communication between two different processes on the
same or different machines.
● A Unix Socket is used in a client-server application framework.
● A server is a process that performs some functions on request from a
client.
● Most of the application-level protocols like FTP, SMTP, and POP3 make
use of sockets to establish connection between client and server and
then for exchanging data.
IPV4 SOCKET ADDRESS STRUCTURE
● An IPv4 socket address structure, commonly called an "Internet socket address structure," is named sockaddr_in
and is defined by including the <netinet/in.h> header.
● Figure in next slide shows the POSIX definition of IPv4 socket address structure
● POSIX or “Portable Operating System Interface for uniX” is a collection of standards that define some of the
functionality that a (UNIX) operating system should support.
● Datatypes required by Posix
IPV4 SOCKET ADDRESS STRUCTURE
GENERIC SOCKET ADDRESS STRUCTURE
● A socket address structures is always passed by reference when passed
as an argument to any socket functions
● But any socket function that takes one of these pointers as an argument
must deal with socket address structures from any of the supported
protocol families.
● A problem arises in how to declare the type of pointer that is passed.
● A generic socket address structure was defined in the <sys/socket.h>
header, which was shown below.
IPV6 SOCKET ADDRESS STRUCTURE
● The IPv6 socket address is defined by including the <netinet/in.h> header
IPV6 SOCKET ADDRESS STRUCTURE
● The SIN6_LEN constant must be defined if the system supports the length member for socket
address structures.
● The IPv6 family is AF_INET6, whereas the IPv4 family is AF_INET.
● The members in this structure are ordered so that if the sockaddr_in6 structure is 64-bit aligned,
so is the 128-bit sin6_addr member. On some 64-bit processors, data accesses of 64-bit values are
optimized if stored on a 64-bit boundary.
● The sin6_flowinfo member is divided into two fields:
○ The low-order 20 bits are the flow label
○ The high-order 12 bits are reserved
● The sin6_scope_id identifies the scope zone in which a scoped address is meaningful, most
commonly an interface index for a link-local address
NEW GENERIC SOCKET ADDRESS STRUCTURE
● A new generic socket address structure was defined as part of the IPv6
sockets API, to overcome some of the shortcomings of the existing struct
sockaddr.
● Unlike the struct sockaddr, the new struct sockaddr_storage is large
enough to hold any socket address type supported by the system.
● The sockaddr_storage structure is defined by including the
<netinet/in.h> header
NEW GENERIC SOCKET ADDRESS STRUCTURE
The sockaddr_storage type provides a generic socket address structure that is different from struct sockaddr in two ways:

1. If any socket address structures that the system supports have alignment requirements, the sockaddr_storage
provides the strictest alignment requirement.
○ alignment requirement, is an integer value of type size_t representing the number of bytes between
successive addresses.
2. The sockaddr_storage is large enough to contain any socket address structure that the system supports.
VALUE-RESULT ARGUMENTS
● When a socket address structure is passed to any socket function, it is
always passed by reference. That is, a pointer to the structure is passed.
● The length of the structure is also passed as an argument.
● But the way in which the length is passed depends on which direction
the structure is being passed:
○ from the process to the kernel, or
○ vice versa.
VALUE-RESULT ARGUMENTS(PASS A SOCKET ADDRESS STRUCTURE FROM
THE PROCESS TO THE KERNEL. )

● Three functions, bind, connect, and sendto, pass a socket address structure from the
process to the kernel.
● One argument to these three functions is the pointer to the socket address structure
and another argument is the integer size of the structure
VALUE-RESULT ARGUMENTS(PASS A SOCKET ADDRESS STRUCTURE FROM THE
PROCESS TO THE KERNEL. )
● Since the kernel is passed both the pointer and the size of what the pointer points
to, it knows exactly how much data to copy from the process into the kernel.
VALUE-RESULT ARGUMENTS(PASS A SOCKET ADDRESS
STRUCTURE FROM THE KERNEL TO THE PROCESS. )
● Four functions, accept, recvfrom, getsockname, and getpeername, pass a socket
address structure from the kernel to the process, the reverse direction from the
previous scenario.
● Two of the arguments to these four functions are the pointer to the socket address
structure along with a pointer to an integer containing the size of the structure
VALUE-RESULT ARGUMENTS(PASS A SOCKET ADDRESS STRUCTURE FROM THE KERNEL TO THE PROCESS. )
VALUE-RESULT ARGUMENTS(PASS A SOCKET ADDRESS STRUCTURE FROM THE KERNEL TO THE PROCESS. )

● The reason that the size changes from an integer to be a pointer to an

integer is because the size is both a value when the function is called (it
tells the kernel the size of the structure so that the kernel does not write
past the end of the structure when filling it in) and a result when the
function returns (it tells the process how much information the kernel
actually stored in the structure). This type of argument is called a value-
result argument.
VALUE-RESULT ARGUMENTS
● When using value-result arguments for the length of socket address
structures,
○ if the socket address structure is fixed-length , the value returned by the kernel
will always be that fixed size: 16 for an IPv4 sockaddr_in and 28 for an IPv6
sockaddr_in6, for example.
○ But with a variable-length socket address structure (e.g., a Unix domain
sockaddr_un), the value returned can be less than the maximum size of the
structure (
BYTE ORDERING
● Consider a 16-bit integer that is made up of 2 bytes.
● There are two ways to store the two bytes in memory:
○ with the low-order byte at the starting address, known as little-endian byte order, or
○ with the high-order byte at the starting address, known as big-endian byte order.

eg:0x1234

Memory Addr ->->->

Little-endian
34 --- 12

Big-endian
12 --- 34
BYTE ORDERING FUNCTIONS
● We must deal with these byte ordering differences as network
programmers because networking protocols must specify a network
byte order.
● For example, in a TCP segment, there is a 16-bit port number and a 32-
bit IPv4 address.
● The sending protocol stack and the receiving protocol stack must agree
on the order in which the bytes of these multibyte fields will be
transmitted. The Internet protocols use big-endian byte ordering for
these multibyte integers.
CONVERSION OF NETWORK TO HOST BYTE ORDER AND VICE VERSA

● We use the following four functions

to convert between these host
byte and network byte orders.
● In the names of these functions,
○ h stands for host,
○ n stands for network,
○ s stands for short, and
○ l stands for long.
BYTE MANIPULATION FUNCTIONS
● There are two groups of functions that operate on multibyte fields, without
interpreting the data, and without assuming that the data is a null-terminated C
string.
● We need these types of functions when dealing with socket address structures
because we need to manipulate fields such as IP addresses, which can contain
bytes of 0, but are not C character strings.
● The functions beginning with str (for string), defined by including the <string.h>
header, deal with null-terminated C character strings.
● The first group of functions, whose names begin with b (for byte), are from 4.2BSD.
and are still provided by almost any system that supports the socket functions.
● The second group of functions, whose names begin with mem (for memory), are
from the ANSI C standard and are provided with any system that supports an ANSI C
library.
BYTE MANIPULATION FUNCTIONS
● bzero sets the specified number of
bytes to 0 in the destination. We
often use this function to initialize a
socket address structure to 0.
● bcopy moves the specified number
of bytes from the source to the
destination.
● bcmp compares two arbitrary byte
strings.
○ The return value is zero if the two
byte strings are identical; otherwise,
it is nonzero.
BYTE MANIPULATION FUNCTIONS (ANSI STANDARD)
● memset sets the specified number of bytes to
the value c in the destination.
● memcpy is similar to bcopy, but the order of the
two pointer arguments is swapped.
○ bcopy correctly handles overlapping fields, while
the behavior of memcpy is undefined if the
source and destination overlap.
● memcmp compares two arbitrary byte strings
and returns 0 if they are identical.
○ If not identical, the return value is either
greater than 0 or less than 0, depending on
whether the first unequal byte pointed to by
ptr1 is greater than or less than the
corresponding byte pointed to by ptr2
FORK() AND EXEC()

● Every application(program) comes into execution

through means of process,
● process is a running instance of a program.
● Processes are created through different system calls,
most popular are fork() and exec()
FORK()

pid_t pid = fork();

● fork() creates a new process by duplicating the calling process,
● The new process, referred to as child, is an exact duplicate of the calling process, referred to as parent, except for
the following :
○ The child has its own unique process ID, and this PID does not match the ID of any existing process group.
○ The child’s parent process ID is the same as the parent’s process ID.
○ The child does not inherit its parent’s memory locks and semaphore adjustments.
○ The child does not inherit outstanding asynchronous I/O operations from its parent nor does it inherit any asynchronous I/O
contexts from its parent.

● Return value of fork()

○ On success, the PID of the child process is returned in the parent, and 0 is returned in the child.
○ On failure, -1 is returned in the parent, no child process is created, and errno is set appropriately
EXEC()
● The exec() family of functions replaces the current process image with a new process
image.
● It loads the program into the current process space and runs it from the entry point.
● The exec() family consists of following functions,
int execl(const char *path, const char *arg, ...);

int execlp(const char *file, const char *arg, ...);

int execle(const char *path, const char *arg, ..., char * const
envp[]);
int execv(const char *path, char *const argv[]);
int execvp(const char *file, char *const argv[]);
int execvpe(const char *file, char *const argv[], char *const envp[]);
FORK VS EXEC

● fork starts a new process which is a copy of the one that calls
it, while exec replaces the current process image with another
(different) one.
● Both parent and child processes are executed simultaneously
in case of fork() while Control never returns to the original
program unless there is an exec() error.
CONCURRENT SERVERS

● When a client request can take longer to service

● we do not want to tie up a single server with one client
● we want to handle multiple clients at the same time.
● The simplest way to write a concurrent server under Unix is to
fork a child process to handle each client.
CONCURRENT SERVER
 ● When a connection is
established, accept returns,
OUTLINE OF A CONCURRENT SERVER the server calls fork, and the
child process services the
client (on connfd, the
connected socket) and the
parent process waits for
another connection (on
listenfd, the listening socket).

● The parent closes the

connected socket since the
child handles the new client.

● the function doit does

whatever is required to
service the client.

● When this function returns,

we explicitly close the
connected socket in the child
● Status of client/server before call to
accept returns.
○ Immediately after accept returns, we have the
scenario shown in second figure
● Status of client/server after return from
accept.
● Status of client/server after fork returns.
○ listenfd and connfd, are shared
(duplicated) between the parent and
child.
● Status of client/server after parent and
child close appropriate sockets.
○ The child is handling the connection with
the client and the parent can call accept
again on the listening socket, to handle
the next client connection.
SOCKET SYSTEM CALLS

bind
● The bind system call assigns a name to an unnamed socket.
#include <sys/types.h>
#include <sys/socket.h>

int bind(int sockfd, struct sockaddr *myaddr, int addrlen);

● The first argument is the socket descriptor returned from socket system call.
○ Each socket within the network has a unique name associated with it called a socket descriptor
● The second argument is a pointer to a protocol-specific address and
● The third argument is the size of this address.
SOCKET SYSTEM CALLS

Connect
● A client process connects a socket descriptor following the socket system call to establish a connection with a
server.
#include <sys/types.h>
#include <sys/socket.h>

int connect(int sockfd, struct sockaddr *servaddr, int addrlen);

○ The sockfd is a socket descriptor that was returned by the socket system call.
○ The second and third arguments are a pointer to a socket address,
○ The third argument is the size of this address.
● The connect system call does not return until the connection is established, or an error is returned to the
process.
SOCKET SYSTEM CALLS

Listen
● This system call is used by a connection-oriented server to indicate that it is willing to receive connections .
#include <sys/types.h>
#include <sys/socket.h>

int listen(int sockfd, int backlog);

● It is usually executed after both the socket and bind system calls, and immediately before the accept system
call.
● The backlog argument specifies how many connection requests can be queued by the system while it waits for
the server to execute the accept system call.
● This argument is usually specified as 5, the maximum value currently allowed.
SOCKET SYSTEM CALLS
accept
● After a connection-oriented server executes the listen system call described above, an actual connection
from some client process is waited for by having the server execute the accept system call.

#include <sys/types.h>

#include <sys/socket.h>

int accept(int sockfd, struct sockaddr *peer, int *addrlen);

● accept takes the first connection request on the queue and creates another socket with the same properties
as sockfd.
● If there are no connection requests pending, this call blocks the caller until one arrives.
● The peer and addrlen arguments are used to return the address of the connected peer process (the client).
● addrlen is called a value-result argument: the caller sets its value before the system call, and the system call
stores a result in the variable.
● For this system call the caller sets addrlen to the size of the sockaddr structure whose address is passed as
the peer argument.
SOCKET SYSTEM CALLS
send, sendto, recv and recvfrom
These system calls are similar to the standard read and write system calls, but
additional arguments are required.
#include <sys/types.h>
#include <sys/socket.h>
int send(int sockfd, char *buff, int nbytes, int flags);

int sendto(int sockfd, char *buff, int nbytes, int flags, struct sockaddr *to, int
addrlen);

int recv(int sockfd, char *buff, int nbytes, int flags);

int recvfrom(int sockfd, char *buff, int nbytes, int flags, struct sockaddr *from,
int *addrlen);
SOCKET SYSTEM CALLS

close
● The normal Unix close system call is also used to close a socket.

int close(int fd);

● If the socket being closed is associated with a protocol that promises
reliable delivery (e.g., TCP or SPP), the system must assure that any data
within the kernel that still has to be transmitted or acknowledged, is
sent.
UNIX DOMAIN SOCKET AKA UDS OR IPC SOCKET
● A Unix domain socket aka UDS or IPC socket (inter-process communication socket)
is a data communications endpoint for exchanging data between processes
executing on the same host operating system.
● It is also referred to by its address family AF_UNIX.
● Valid socket types in the UNIX domain are:
● SOCK_STREAM (compare to TCP) – for a stream-oriented socket
● SOCK_DGRAM (compare to UDP) – for a datagram-oriented socket that preserves
message boundaries (as on most UNIX implementations, UNIX domain datagram
sockets are always reliable and don't reorder datagrams)
● SOCK_SEQPACKET (compare to SCTP) – for a sequenced-packet socket that is
connection-oriented, preserves message boundaries, and delivers messages in the
order that they were sent
ELEMENTARY SOCKET SYSTEM CALL
● To do network I/O, the first thing a process must do is to call the socket system call, specifying the type of
communication protocol desired.

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

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

The valid combinations are shown as follows.
THE UNIX FILESYSTEM
● The process table
○ Managing processes is one of the kernel's biggest responsibilities.
○ It decides which process actually gets to run on the CPU (or CPUs) at any point in time.
○ The kernel keeps a data structure (in kernel space) to track information about processes: the process
table.
● File I/O
○ When a process opens a file and reads or writes, we can identify several entities involved:
■ The actual file on the harddrive,
■ the kernel's record that stores in memory (i.e. RAM) basic file info - like permissions, location on the
harddrive, etc,
■ the kernel's record relating to that processes's connection to the file (after all, many processes may be
reading from the file at the same time, or maybe the same process has several different connections reading
from the file simultaneously, but at different locations), and
■ the number that the process uses to tell the kernel which file-connection it's trying to read-from/write-to.
○ The basic system calls for dealing with file I/O are
■ open, which requests that a connection to a file be made;
■ close, which requests that a connection to a file be closed;
■ read, which requests that some bytes be read from a file via a specified connection; and
■ write, which requests that some bytes be written to a file via a specified connection.
THE UNIX FILESYSTEM
● Unix I/O: file descriptors
○ Unix's model of of files is simple:
○ files are just sequences of bytes.
○ User programs may impose structure or meaning on those bytes
● System Open File Table
○ The system needs to keep track of each "connection" to a file.
○ Since distinct processes may even share a connections (say two processes wanted to write to
the same log file, each adding new data to the end of the file), the "connection" information
cannot be kept inside the process table. So the kernel keeps a data structure called the system
open-file table which has an entry for each connection. Each entry contains the connection
status, e.g. read or write, the current offset in the file, and a pointer to a vnode, which is the
OS's structure representing the file, irrespective of where in the file you may currently be
looking. (Note: Linux names their vnode-ish data structure "generic inodes".)
THE UNIX FILESYSTEM

● Vnode Table
○ The kernel keeps yet another table, the Vnode table, which has an entry for
each open file or device.
○ Each entry, called a Vnode, contains information about the type of file and
pointers to functions that operate on the file.
○ Typically for files, the vnode also contains a copy of the inode for the file,
which has "physical" information about the file, e.g. where exactly on the disk
the file's data resides
PASSING FILE DESCRIPTORS

• Passing file descriptors between processes allows sharing of resources.

• It enables one process to share a file descriptor with another process, granting
access to the same file or resource.
• This mechanism is often used for inter-process communication or accessing
shared files or sockets.
• Passing file descriptors involves specific system calls such as sendmsg() and
recvmsg().
• It is a powerful feature in Unix programming that enables efficient resource
sharing and communication between processes.
PASSING FILE DESCRIPTOR (REFERENCES)

https://www.sobyte.net/post/2022-01/pass-fd-over-domain-socket/\
https://www.sobyte.net/post/2022-01/pass-fd-over-domain-socket/
https://flylib.com/books/en/3.224.1.265/1/
OUTLINE

• I/O models (blocking, non-blocking, multiplexing, signal driven, asynchronous)

• Socket option, getsockopt, setsockopt, fenti
• Daemon Process, Syslogd Daemon, syslog function, ioctl operation, ioctl function
• Socket operations
• UNIX and Internet domain socket implementation.
I/O MODELS
There are normally two distinct phases for an input/output operation:
● Waiting for the data to be ready. This involves waiting for data to arrive on the
network. When the packet arrives, it is copied into a buffer within the kernel.
● Copying the data from the kernel to the process. This means copying the (ready)
data from the kernel's buffer into our application buffer
There are five I/O models available under Unix:
● blocking I/O
● nonblocking I/O
● I/O multiplexing (select and poll)
● signal driven I/O (SIGIO)
● asynchronous I/O (the POSIX aio_ functions)
BLOCKING I/O
● Blocking I/O is the traditional I/O model where a program waits until the I/O operation
completes.
● When a program performs a blocking I/O operation, it halts its execution until the operation
finishes.
● It means that the program is blocked from doing other tasks until the I/O operation is
complete.
● Blocking I/O is straightforward to use but can lead to inefficiencies if multiple I/O operations
need to be performed concurrently.
● By default, all sockets are blocking
BLOCKING I/O MODEL
BLOCKING I/O MODEL

● The process calls recvfrom and the system call does not
return until the datagram arrives and is copied into
our application buffer, or an error occurs.
● the process is blocked the entire time from when it calls
recvfrom until it returns
● When recvfrom returns successfully, our application
processes the datagram.
NONBLOCKING I/O MODEL

● Nonblocking I/O allows a program to continue executing even if an I/O operation is not
yet complete.
● When a program performs a nonblocking I/O operation, it doesn't wait for the
operation to finish but continues with other tasks.
● It enables the program to perform other operations or check the status of multiple I/O
operations simultaneously.
● Nonblocking I/O requires additional code logic to handle the nonblocking nature and
repeatedly check for completion.
NONBLOCKING I/O MODEL
● When a socket is set to be nonblocking, we are telling the kernel "when an I/O operation that I request cannot be
completed without putting the process to sleep, do not put the process to sleep, but return an error instead"
NONBLOCKING I/O MODEL
● For the first three recvfrom, there is no data to return and the kernel
immediately returns an error of EWOULDBLOCK.
● For the fourth time we call recvfrom, a datagram is ready, it is copied into
our application buffer, and recvfrom returns successfully. We then process
the data.
● When an application sits in a loop calling recvfrom on a nonblocking
descriptor like this, it is called polling.
● The application is continually polling the kernel to see if some operation is
ready.
● This is often a waste of CPU time, but this model is occasionally
encountered, normally on systems dedicated to one function.
I/O MULTIPLEXING MODEL

● I/O multiplexing is a mechanism to monitor multiple I/O operations using a single

thread or process.
● The select and poll functions are commonly used for I/O multiplexing in Unix-
based systems.
● These functions allow a program to monitor multiple file descriptors (e.g.,
sockets) and detect which ones are ready for I/O operations.
● By using I/O multiplexing, a program can efficiently handle multiple I/O
operations without blocking or spinning in busy loops.
I/O MULTIPLEXING MODEL
With I/O multiplexing, we call select or poll and block in one of these two
system calls, instead of blocking in the actual I/O system call.
I/O MULTIPLEXING MODEL
● We block in a call to select, waiting for the datagram socket to
be readable. When select returns that the socket is readable,
we then call recvfrom to copy the datagram into our
application buffer.
● Comparing to the blocking I/O model
○ Disadvantage: using select requires two system calls (select and
recvfrom) instead of one
○ Advantage: we can wait for more than one descriptor to be ready
SIGNAL-DRIVEN I/O MODEL

● Signal-driven I/O is a technique where a program receives a signal when an I/O

operation is ready to be performed.
● The SIGIO signal is sent to the program to indicate that an I/O operation on a
particular file descriptor is possible.
● By registering for the SIGIO signal, the program can handle I/O operations
asynchronously without blocking.
● It allows the program to continue executing until it receives the signal, indicating
that an I/O operation can be performed.
SIGNAL-DRIVEN I/O MODEL
● The signal-driven I/O model uses signals, telling the kernel to notify us with the SIGIO signal when the descriptor
is ready.
SIGNAL-DRIVEN I/O MODE

● We first enable the socket for signal-driven I/O and install a signal handler using
the sigaction system call. The return from this system call is immediate and our
process continues; it is not blocked.
● When the datagram is ready to be read, the SIGIO signal is generated for our
process. We can either:
○ read the datagram from the signal handler by calling recvfrom and then notify the main
loop that the data is ready to be processed
○ notify the main loop and let it read the datagram .
ASYNCHRONOUS I/O MODEL

● Asynchronous I/O is a method where I/O operations are initiated and executed
independently of the program's execution flow.
● The POSIX aio_ functions (e.g., aio_read, aio_write) are used for asynchronous I/O operations.
● With asynchronous I/O, a program initiates an I/O operation and continues with other tasks
without waiting for the operation to complete.
● The program can then later check the status of the asynchronous operation or be notified
through a callback mechanism.
● The main difference between this model and the signal-driven I/O model is that with signal-
driven I/O, the kernel tells us when an I/O operation can be initiated, but with asynchronous
I/O, the kernel tells us when an I/O operation is complete.
ASYNCHRONOUS I/O MODEL
ASYNCHRONOUS I/O MODEL
● We call aio_read (the POSIX asynchronous I/O functions begin with aio_ or lio_) and
pass the kernel the following:
○ descriptor, buffer pointer, buffer size (the same three arguments for read),
○ file offset (similar to lseek),
○ and how to notify us when the entire operation is complete.

This system call returns immediately and our process is not blocked while waiting for the
I/O to complete.
● We assume in this example that we ask the kernel to generate some signal when the
operation is complete.
● This signal is not generated until the data has been copied into our application
buffer, which is different from the signal-driven I/O model.
SYNCHRONOUS I/O VERSUS ASYNCHRONOUS I/O

● POSIX defines these two terms as follows:

○ A synchronous I/O operation causes the requesting process to be blocked
until that I/O operation completes
○ An asynchronous I/O operation does not cause the requesting process to be
blocked.
● Using these definitions, the first four I/O models (blocking, nonblocking,
I/O multiplexing, and signal-driven I/O) are all synchronous because the
actual I/O operation (recvfrom) blocks the process. Only the
asynchronous I/O model matches the asynchronous I/O definition.
SOCKET OPTIONS

● There are various ways to get and set the options that
affect a socket:
○ The getsockopt and setsockopt functions.
○ The fcntl function, which is the POSIX way to set a socket
for nonblocking I/O, signal-driven I/O, and to set the owner
of a socket.
○ The ioctl function.
GETSOCKOPT AND SETSOCKOPT FUNCTIONS
● getsockopt() and setsockopt() manipulate options for the socket referred to by the file descriptor sockfd.
● Options may exist at multiple protocol levels;

referred to by the file descriptor sockfd.

GETSOCKOPT AND SETSOCKOPT FUNCTIONS

● On success, zero is returned for the standard options.

● On error, -1 is returned, and errno is set to indicate the
error.
GETSOCKOPT AND SETSOCKOPT FUNCTIONS

level optname get set Description Flag Datatype

IPPROTO_IP IP_HDRINCL x x IP header included with data x int

IP_OPTIONS x x IP header options (see text)

IP_RECVDSTADDR x x Return destination IP address x int

IP_RECVIF x x Return destination IP address x int

GETSOCKOPT AND SETSOCKOPT FUNCTIONS
level optname get set Description Flag Datatype

IPPROTO_IPV6 IPV6_CHECKSUM x x Offset of checksum int

field for raw sockets

IPV6_DONTFRAG x x Drop instead of x int

fragment large
packets

IPV6_NEXTHOP x x Specify next-hop sockaddr_in6{}

address

IPV6_PATHMTU x Retrieve current path ip6_mtuinfo{}

MTU

IPV6_RECVDSTOPTS x Receive destination x int

options
DAEMON PROCESSES

● Daemons are processes that are often started when the system is
bootstrapped and terminate only when the system is shut down.
● Because they don’t have a controlling terminal, they run in the
background.
● UNIX systems have numerous daemons that perform day-to-day
activities.
● Since a daemon does not have a controlling terminal, we need to see
how a daemon can report error conditions when something goes wrong.
DAEMON PROCESS: ERROR LOGGING

One problem a daemon has is how to handle error messages. It cannot (simply)
write to:

● Standard error: it shouldn't have a controlling terminal.

● Console device: on many workstations the console device runs a windowing
system.
● Separate files: it's a headache to keep up which daemon writes to which log
file and to check these files on a regular basis.

A central daemon error-logging facility is required. Most daemons use this facility.
DAEMON PROCESS: ERROR LOGGING

● There are three ways to generate log messages:

○ Kernel routines can call the log function. These messages can be read by any user
process that opens and reads the /dev/klog device.
○ Most user processes (daemons) call the syslog(3) function to generate log
messages. This causes the message to be sent to the UNIX domain datagram
socket /dev/log.
○ A user process on this host or some other host that is connected to this host by a
TCP/IP network, can send log messages to UDP port 514. Note that the syslog
function never generates these UDP datagrams: they require explicit network
programming by the process generating the log message.
DAEMON PROCESS: ERROR LOGGING
The syslogd daemon reads all three forms of log messages. On start-up, this daemon reads a configuration file, usually
/etc/syslog.conf, which determines where different classes of messages are to be sent.
IOCTL () FUNCTION
● IOCTL is referred to as Input and Output Control, which is used to talking to device
drivers
● The major use of this is in case of handling some specific operations of a device for
which the kernel does not have a system call by default.
#include <unistd.h>
int ioctl(int fd,int request,...../* void *arg/);
//Return: 0 if successful, -1 if failed
● The third parameter is always a pointer, but the type of the pointer depends on the
request parameter
IOCTL FUNCTION

● There are 6 types of ioctl requests related to the network:

○ Socket operation
○ File operations
○ Interface operation
○ ARP(Address Resolution Protocol) cache operation
○ Routing table operations
○ Flow system
SOCKET AND OPERATION
category request description type of data

Socket SIOCATMASK Is it on the out-of-band sign int

SIOCSPGRP Set the process ID and process group ID of the socket int

SIOCGPGPR Get the process ID and process group ID of the socket int

File operations FIONBIO Set/clear non-blocking flag int

FIOASYNC Set/clear asynchronous I/O flag int

FIONREAD Get the number of bytes of data in the receive buffer int

FIOSETOWN Set the process ID or process group ID of the file int

FIOGETOWN Get the process ID or process group ID of the file int

category request description type of data

interface SIOCGIFCONF Get a list of all interfaces struct ifconf

SIOCSIFADDR Set interface address struct ifreq

SIOCGIFADDR Get interface address struct ifreq

SIOCSIFFLAGS Set interface flag struct ifreq

ARP SIOCSARP Create/modify ARP entries struct arpreq

SIOCGARP Get ARP entries struct arpreq

SIOCDARP Delete ARP entry struct arpreq

SIOCSARP Create/modify ARP entries struct arpreq

routing SIOCADDRT Increase path struct rtentry

SIOCDELRT Delete path struct rtentry

SOCKET IMPLEMENTATION
https://www.tutorialspoint.com/unix_sockets/socket_quick_guide.htm

https://github.com/sushantpaudel/network-programming-examples
ASSIGNMENT .
● https://aws.amazon.com/education/awseducate/

● Get AWS Educate account using college’s email

● Create a Linux Instance in AWS educate account

THANK YOU!
- SUSHANT PAUDEL