IPC Topics¶

Pipes
Named Pipes / FIFOs
Signals
Shared memory
Memory mapped files
Locking in shared memory
Files
Domain sockets
Doors
TCP/IP

IPC Performance Hierarchy¶

Fastest - no kernel interaction needed, except to setup:
- Shared memory
- Locking in shared memory
Very fast - virtual memory manager involved
- Memory mapped files
Fast - system calls required - i.e. context switches
- Pipes, FIFOs / Named Pipes
- Signals
- Domain sockets
Medium / Slow - FS or network involved
- Files
- TCP/UDP sockets

Pipes¶

Pipes are the oldest UNIX IPC mechanism aside from files.
Pipes are half-duplex - data only flows in one direction
Pipes can only be used between processes that have a common parent. Pipes are created by a parent process and then inherited across a fork() call.
Passing data from one process to another through a pipe involves at least two context switches. A third one is necessary for control to return to the writing process.
Pipes in general are very fast. Sending data at rates of 100s to 1000s of MB/s is possible.

Pipes¶

Pipes have two file descriptors
- One file descriptor is read-only
- One file descriptor is write-only
The Linux call to create a pipe is:
- int pipe(int pipefd[2]);
- pipefd[0] is the read-only half
- pipefd[1] is the write-only half
The Windows call to create a pipe is:
- BOOL CreatePipe(HANDLE readHandle, HANDLE writeHandle, LPSECURITY_ATTRIBUTES attr, DWORD nSize);
- readHandle and writeHandle are the read/write file handles
- attr allows processes that run under more than one user account to manage security of individual pipes
- nSize is the suggested buffer size for the pipe

Pipes - Linux¶

#include <stdio.h>
#include <unistd.h>
#include <fcntl.h>
#include <stdlib.h>

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

        int pipes[2];
        pipe(pipes);

        int inputPartOfPipe = pipes[0];
        int outputPartOfPipe = pipes[1];

        int pid = fork();

        if(pid > 0) {   //parent process
                dup2(inputPartOfPipe, 0); // redirect STDIN
                close(outputPartOfPipe);  // close unused half of pipe
                int value;
                scanf("%d\n", &value);
                printf("child sent value = %d\n", value);
        } else if(pid == 0) {   //child process
                dup2(outputPartOfPipe, 1); // redirect STDOUT
                close(inputPartOfPipe);     // close unused half of pipe
                printf("%d\n", 5000);
        } else {
                printf("fork failed!\n");
        }

        //don't worry about closing remaining pipes,
        //process exit does this for us

        return 0;
}

Pipes - Context Switches¶

Named Pipes / FIFOs¶

Named pipes are the same as regular pipes except:

Named pipes live in the filesystem namespace
Named pipes can have a different lifespan than individual processes
Since named pipes are files, you can apply more advanced permissions to them

Example usage of a regular pipe in Linux¶

Example:

$ cat file | gzip -c9 > file.gz

Example usage of a named pipe in Linux:

$ mkfifo pipe_file
$ gzip -c9 < pipe_file > file.gz
$ cat file > pipe_file
$ rm -f pipe_file

Named Pipes - Common Usages¶

Named pipes are commonly used for single machine client / server applications
In Windows, named pipes can ride on top of TCP/IP and be used for intra-machine IPC.
To improve performance of applications that are written to only work with files and not with normal pipes.
- Does not work if the program uses random I/O
- A program that is written to read a large file from disk can instead read from a named pipe. The named pipe’s data can in turn be produced by another program.
- A program that can only work with files from the local disk can be made to work with a file on the web through a named pipe and a command that can write a URL to standard output
- This pattern can be used to add encryption, file compression, and other extensions to programs that do not already have them.

Named Pipes - Atomic Reads / Writes¶

What happens if two processes write to a named pipe at the same time?

If the size of each write(…) call is <= PIPE_BUF, the writes will be atomic and in order.
If the size of each write(…) call is > PIPE_BUF, then the individual writes will be broken up and interleaved with other simultaneous callers.
So, a good rule of thumb, is to make sure that what you write to a named pipe is less than PIPE_BUF in size. Otherwise, you need to guarantee that you are the only one writing to the pipe file

Signals¶

Signals are software interrupts / events
Provide a way for handling asynchronous events
Modern UNIX systems have > 30 different signals defined
Signals have a concept of disposition or action
- Ignore the signal: works for all signals except SIGKILL, SIGSTOP, and SIGEMT
- Catch the signal: program registers with the kernel a function to handle a signal.
- Default: allows the signal to perform its default action. Every signal has a default action

List of Important Signals¶

List of Important Signals¶
Signal	Description
SIGABRT	abnormal termination, generated by abort() function. Default terminates and core dumps the process.
SIGALRM	generated when a timer expires. Set by alarm() function.
SIGBUS	Indicates a hardware fault. Often memory protection faults. Default terminates the application.
SIGCHLD	Sent to a parent process when a child process terminates.
SIGCONT	Sent to a stopped process when it is continued.
SIGEMT	General hardware fault
SIGFPE	Arithmetic exception: divide by 0, floating point overflow, etc…
SIGHUP	Terminal is disconnected
SIGILL	The process has executed an illegal instruction (like trying to disable interrupts)
SIGINT	Generated by terminal when we press Ctrl-C
SIGAIO	Generated when an asynchronous I/O event occurs.
SIGKILL	Can’t be caught or ignored. Default action is to kill a process.
SIGPIPE	Generated when you write to a pipe where the reader has been terminated.
SIGSEGV	Segmentation violation
SIGSTOP	Sent before a process is put into the stop state.

Handling Signals - Example¶

static void handler(int);

int main(int argv, char* argv[]) {
  signal(SIGUSR1, handler);
  signal(SIGINT, handler);
  while(1) { pause(); }
}

static void handler(int signalNum) {
  if(signalNum == SIGUSR1) {
    printf("received SIGUSR1\n");
  } else if(signalNum == SIGINT) {
    printf("received SIGHUP\n");
  }
}

Sending Signals - Example¶

Signals can be sent to a running process using kill:

$ firefox &
[1] 5050
$ kill -USR1 5050        - sends signal SIGUSR to firefox
$ kill 5050              - sends signal SIGTERM to firefox

Signals - Interrupted System Calls¶

Signals will “wake up” blocking calls to “slow” system calls
In old UNIX, this was any blocking system call.
In modern UNIX, the following are “slow” system calls meaning that they can block for ever in theory:
- Reads from pipes, terminal devices, and network devices
- Writes to pipes, terminal devices, and network devices if the data cannot be accepted immediately.
- Opens of files that block until some condition occurs (such as a serial device or modem connecting).
- All calls to the pause() function, pause() waits until signals are caught.
This means, if you are catching signals, you will have to check errno for EINTR (interrupted by signal) error if these functions return in an error state. If they do, you must retry your operation
In newer UNIX systems, if signals are triggered with a SA_RESTART flag passed to sigaction(…), system calls would be automatically restarted after signal handling completes.

Signals - Reentrant Functions¶

When handling a signal, the main execution of the process is suspended. The interrupted state is not something that can be examined or otherwise determined.
It is possible that the interrupted state could be inside of a malloc() or free() call. If we call malloc() or free() in the signal handler, we could corrupt the allocated or free list.
So, in signal handlers we can only call reentrant functions.
Reentrant functions have the following properties:
- Do not call malloc() or free()
- Do not refer to mutable static data structures
- Rule of thumb is to call functions that are either system calls or low level wrappers of system calls are safe. Other functions should not be used unless you are certain of their safety.

Signals - Reentrant Functions¶

abort       access       alarm      chdir       chmod        chown
close       creat        dup        dup2        execle       execve
exit        fcntl        fork       fstat       getgid       getuid
kill        link         longjmp    lseek       mkdir        mkfifo
open        pathconf     pause      pipe        read         rename
rmdir       setgid       setsid     setuid      sigaction    sigaddset
sigdelset   sigemptyset  signal     sigpending  sigsuspend   sleep
stat        sysconf      time       times       umask        uname
unlink      utime        wait       waitpid     write

Signals - Sending In Code¶

Sending a signal to another process:
- int kill(pid_t pid, int signo);
- pid > 0, signal is sent to process with id = pid
- pid = 0, signal sent to all process whose group ID is the same as the sender of the signal. Will not send to init or swapper daemons.
- pid < 0, signal is sent to all processes whose process group ID equals the absolute value of pid for which the sender has permission to send the signal.
- pid = -1, undefined.
Sending a signal to your own process:
- int raise(int signo);
Sending SIGALRM (terminates process by default):
- int alarm(unsigned int seconds);
Waiting for signals:
- int pause(void);

Example - implementing sleep() with alarm¶

    void sig_alrm(int signo) 
    {
       /* ... */
    }

    unsigned int sleepFor(int numSeconds) {
       signal(SIGALRM, sig_alrm);    //set signal handler
       alarm(numSeconds);            //set alarm for n-seconds
       pause();                      //wait for signal
       return alarm(0);              //turn off alarm
       handler;
    }

Example - “better” sleep implementation¶

jmpbuf env_alrm;

void sig_alrm(int signo) {
    longjmp(env_alrm, 1);
}

unsinged int sleepFor(int numSeconds) {
    signal(SIGALRM, sig_alrm);
    if(setjmp(env_alrm) == 0) {
        alarm(nsecs);
        pause();
    }
    return alarm(0);
}

Demonstrating the sleepFor problem¶

void sig_int(int signo) {
    volatile int j = 0;
    printf("sig_int enter\n");
    for(int i = 0; i < 10000000; i++) {
        j += i * i;
    }
    printf("sig_int done\n");
}

int main(int argc, char* argv[]) {
    signal(SIGINT, sig_int);
    unsigned int unslept = sleepFor(1);
    printf("sleepFor returned: %u\n", unslept);
    return 0;
}

History of sleep and why signals are scary.¶

These two sleep implementations are similar to historical implementations of the sleep() call in UNIX
Both of these demonstrate that implementations of signal handlers need to be handled with great care.
You must remember the following between signal and pause: Between the signal registration and the pause call, you may receive the signal. Pause could block forever because of this
You must remember the following in signal handlers:
- You may be interrupting execution of the main program or another signal handler.
- Avoid modifying global variables
Avoid non-reentrant functions
- Be careful of stack modifying functions like setjmp or longjmp
- If you need this behavior, look towards sigsetjmp or siglongjmp
- Be careful of what signals your handler generates

Other uses for alarm(…)¶

Aside from using alarm() to implement a sleep() call
alarm() can be used to put an upper time limit on slow or blocking operations.
If we want to ensure that we don’t wait on a call to read from a named pipe forever, we can setup an alarm call.

Memory Mapped Files¶

Memory mapped files are one of two ways to share memory regions between applications.
First, there are some virtual memory concepts that we need to introduce:
- Virtual address - the address that the program sees for an object in memory
- Physical address - the real address (if it exists) of an object in physical memory
- Physical and virtual addresses are almost never the same.
- Backing store - the non physical memory location that backs a physical memory object.
All physical memory objects have backing stores
- text segments - executable and library files
- data, stack segments - swap files
- memory mapped regions - memory mapped files
We will dig deeper into virtual memory in a later lecture, but these concepts will be sufficient to proceed

Memory Mapped Files¶

The technique used in memory mapped files is simple but very powerful.
Fundamentally, when you memory map a file with the mmap() function, you are declaring a region of virtual memory to be backed by a file.
This means, when you write to this mapped region, the values will appear (to other programs) immediately in the backing file. If the backing file is updated, the values in that file will (to the running program) appear immediately in memory.
When two programs map a file into virtual memory, the virtual addresses will most likely differ between the programs.
Two programs that have the same region of a memory mapped file mapped to memory will be able to communicate with each other by reading and writing values to that memory region

Memory Mapped Files¶

Memory Mapped Files - Virtual Addresses¶

There are two instances in virtual memory where position independent code (the use of relative memory addressing) must be used.
Shared libraries - because the data / bss segments are shared among processes and mapped to different virtual addresses.
Memory mapped files - because the memory mapped file is mapped to different virtual addresses in different processes.
To implement position independent code, techniques similar to -fpic used in GCC must be used by code that you write to work with memory mapped regions.
Rules for writing position independent code in memory mapped regions:
- Do not pass pointers or structures that make use of pointers. Pointers use virtual addresses.
- Objects in memory mapped regions should not refer to objects outside of memory mapped regions.

Absolute Memory Addressing¶

typedef struct {
    char[50] Brand;
    char[2] TractionRating;
    char[2] SpeedRating;
} Wheel;

typedef struct {
    Wheel*[4] Wheels;
    char* Make;
    char* Model;
} Car;

Car* car = (Car*)malloc(sizeof(Car));
car.Make = (char*)malloc(sizeof(char)*50);
car.Model = (char*)malloc(sizeof(char)*50);
car.Wheels[0] = (Wheel*)malloc(sizeof(Wheel));
car.Wheels[1] = (Wheel*)malloc(sizeof(Wheel));
car.Wheels[2] = (Wheel*)malloc(sizeof(Wheel));
car.Wheels[3] = (Wheel*)malloc(sizeof(Wheel));

car.Wheels[1]->Brand

Here, the location of each of the wheel objects is stored with an absolute reference from the Car. If this is shared in a memory mapped file, a call to car.Wheels[0] will not resolve to a correct address.

Relative Memory Addressing¶

typedef struct {
    char[50] Brand;
    char[2] TractionRating;
    char[2] SpeedRating;
} Wheel;

typedef struct {
    Wheel[4] Wheels;
    char[50] Make;
    char[50] Model;
} Car;

Car* car = (Car*)malloc(sizeof(Car));

Here, we are using relative addressing. The entire Car struct is allocated in a contiguous memory region. To access each wheel, you need only use an offset from the beginning of the Car struct.

Linux / Minix - Use of mmap()¶

General Algorithm:

Process A creates file on disk
Process A seeks a length of N
Process A writes a 0 to the file
Process A calls mmap on the file to map it to memory
Process A copies its data structures into the mapped region
Process B calls mmap on the file to map it to memory
Process A and B proceed using the mapped region to cooperate

mmap - simple example¶

int main(int argc, char* argv[]) {
    const char *data = "Hello World";
    const int dummyValue = 0;
    int dataSize = sizeof(char) * strlen(data) + sizeof(char);

    int fd = open("shared.dat", O_CREAT|O_TRUNC|O_RDWR, 0666);
    lseek(fd, dataSize, SEEK_SET);
    write(fd, (char*)&dummyValue, sizeof(char));
    
    void* map = mmap(NULL,dataSize,PROT_READ|PROT_WRITE,MAP_SHARED,fd,0);

    memcpy(map, data, dataSize);

    getchar();

    munmap(map, dataSize);
    close(fd);

    return 0;
}

mmap - simple example¶

int main(argc, char* argv[]) {
    struct stat fileStat;
    stat("shared.dat", &fileStat);
    int fileSize = fileStat.st_size;

    int fd = open("shared.dat", O_RDWR);

    void* map = mmap(NULL, fileSize, PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0);

    char* data = (char*)calloc(1, fileSize);

    memcpy(data, map, fileSize);

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

    free(data);
    munmap(map);
    close(fd);

    return 0;
}

Memory Mapped Files - Atomicity¶

When we explored pipes, we learned that writing to a pipe (below a certain limit) is an atomic operation. We get this guarantee because the OS kernel guarantees this by guaranteeing that system calls are atomic.
The only system calls involved in memory mapped files are mmap and munmap. These are only for initializing and cleaning up mapped memory regions.
Reading and writing mapped memory regions does not involve system calls and carries no guarantee of atomicity. It is similar to multiple threads writing to the same heap.
To achieve atomicity in memory mapped regions, you must use:
- Mutexes
- Semaphores
- Monitors / Condition Variables
The implementation that you use must also use relative addressing internally or otherwise be able to be configured for it.
The fact that memory mapped regions do not guarantee atomicity and do not use context switches is also why memory mapped regions perform so well.
In general, the fewer the guarantees a mechanism provides, the faster it is.

Memory Mapped Files - Bounded Buffer¶

#include <semaphore.h>

const int MessageQueueSize = (5);
const int MaxMessageSize = (20);

class Message {
public:
  ~Message();
  void EnqueueMessage(const char *msg);
  char* DequeueMessage();
  static Message *CopyToMemoryMappedFile(int fd);
  static Message *GetFromMemoryMappedFile(int fd);
static void ReleaseFile(Message *msg, int fd);
private:
  Message();
  sem_t _lock;
  sem_t _empty;
  sem_t _full;
  int _current;
  char _messages[MessageQueueSize][MaxMessageSize];
};

Memory Mapped Files - Bounded Buffer¶

Message::Message() {
  sem_init(&_lock,  1, 1);                                //passing 1 as the 2nd parameter allows the
  sem_init(&_empty, 1, 0);                              //semaphore work in a memory mapped region
  sem_init(&_full,  1, MessageQueueSize);
  _current = 0;
}
Message::~Message() { }
Message *Message::CopyToMemoryMappedFile(int fd) {
  int datasize = sizeof(Message);
  printf("message size = %d\n", datasize);
  if(lseek(fd, sizeof(Message), SEEK_SET) == (-1)) {
     fprintf(stderr, "error in lseek\n");
  }
  int dummyVal = 0;
  if(write(fd, (char*)&dummyVal, sizeof(char)) == (-1)) {
     fprintf(stderr, "error in write\n");
  }
  void *map = mmap(NULL, sizeof(Message), (PROT_READ|PROT_WRITE), MAP_SHARED, fd, 0);
  if(map == (void*)(-1)) {
     fprintf(stderr, "mmap() returned -1\n");
  }
  Message *msg = new Message();
  memcpy(map, (void*)msg, sizeof(Message));
  delete msg;
  return (Message*)map;
}

Memory Mapped Files - Bounded Buffer¶

Message *Message::GetFromMemoryMappedFile(int fd) {
  void *map = mmap(
     NULL, sizeof(Message), 
     (PROT_READ|PROT_WRITE), MAP_SHARED, fd, 0);
  if(map == (void*)(-1)) {
     fprintf(stderr, "mmap() returned -1\n");
  }
  Message* msg = (Message*)map;
  return msg;
}

void Message::ReleaseFile(Message *msg, int fd) {
  if(munmap((void*)msg, sizeof(Message)) == (-1)) {
     fprintf(stderr, "munmap() failed\n");
  }
}

Memory Mapped Files - Bounded Buffer¶

void Message::EnqueueMessage(const char *msg) {
  sem_wait(&_full);
  sem_wait(&_lock);
  _current += 1;
  bzero(&_messages[_current], MaxMessageSize*sizeof(char));
  memcpy(&_messages[_current], msg, strlen(msg)*sizeof(char));
  sem_post(&_lock);
  sem_post(&_empty);
}

char* Message::DequeueMessage() {
  char *msg = new char[MaxMessageSize];
  sem_wait(&_empty);
  sem_wait(&_lock);
  memcpy(msg, &_messages[_current], MaxMessageSize*sizeof(char));
  _current -= 1;
  sem_post(&_lock);
  sem_post(&_full);
  return msg;
}

Memory Mapped Files - Bounded Buffer¶

Producer Code

int main(int argc, char* argv[]) {
  const char *sharedFileName = "shared.dat";
  const mode_t mode = 0666;
  const int openFlags = (O_CREAT | O_TRUNC | O_RDWR);
  int fd = open(sharedFileName, openFlags, mode);

  if(fd == (-1)) {
     printf("open returned (-1)\n");
     return (-1);
  }

  Message* msg = Message::CopyToMemoryMappedFile(fd);

  for(int i = 0; i < 100; i++) {
     char message[10];
     sprintf(message, "%d\n", i);
     msg->EnqueueMessage(&message[0]);
     printf("enqueued %d\n", i);
  }
  printf("message queue written\n");
  getchar();
  Message::ReleaseFile(msg, fd);
  close(fd);
}

Memory Mapped Files - Bounded Buffer¶

Consumer Code

int main(int argc, char* argv[]) {
  const char *sharedFileName = "shared.dat";
  const mode_t mode = 0666;
  const int openFlags = (O_RDWR);
  int fd = open(sharedFileName, openFlags, mode);

  if(fd == (-1)) {
     printf("open returned (-1)\n");
     return (-1);
  }

  Message* msg = Message::GetFromMemoryMappedFile(fd);

  int count = 0;

  while(1) {
     char *message = msg->DequeueMessage();
     printf("%d: %s", ++count, message);
     fflush(stdout);
  }

  Message::ReleaseFile(msg, fd);

  close(fd);
}

Memory Mapped Files - Fast I/O¶

Memory mapped I/O is faster because it avoids a copy from user mode to kernel mode

Normal User - Kernel write(…) call algorithm:

user app - write(fd, user_buf, len);
user app - context switch into OS (software interrupt)
kernel mode - allocate space in file, check security, etc…
kernel mode - copy user_buf to FS buffer cache
kernel mode - context switch into user app (interrupt return)
at some later time, kernel commits buffer cache to disk

Normal User - Kernel mmap(…) write algorithm:

user app - copy values to mapped region
kernel mode - MMU triggers page fault (hardware interrupt)
kernel mode - writes page to backing store
kernel mode - context switch to user app (interrupt return)

Memory Mapped Files - Fast I/O¶

The read algorithm for regular read vs. mmap read is very similar to the write algorithm and also avoids a kernel to user mode copy
On systems with large address spaces (64-bit), memory mapped I/O can be very advantageous. - For example, a database server can memory map an entire database that is several TB in size into memory.
Since most VM systems user a very efficient LRU algorithm and have a lot of I/O scheduling data, memory mapping large files is amongst the fastest approaches.
Other advanced approaches include scatter/gather or vectored I/O.
Memory mapped I/O carries the greatest advantage when the structure of the file maps well into the domain model. This means that no serialization / deserialization is needed.

Files - IPC¶

Files are the oldest and most generally used form of IPC
Almost every resource in a modern operating system is accessible through a file based contract (open, read, write, seek, close)
File based IPC is available in almost every operating system.
File based IPC, in modern times is best considered in a few patterns:
- State persistence - beyond the lifetime of a program
- Exposing current state - during program execution
- Queues / Spooling folders - mail daemons, printers, execution queues
- Resource state expression - lock files, availability, etc…

Files - Exposing Current State¶

/proc filesystems are important ways for OS designers to expose system information without inventing new system calls.

This is a key advantage for kernel module developers and for device driver developers
Also provides a great way to debug kernel changes

List of /proc-style Filesystems¶
Filesystem	Description
Filesystem	Description
/proc/vmstat	virtual memory stats and configuration
/proc/cpuinfo	individual CPU information
/proc/<PID>	individual process information
/proc/loadavg	moving average of ready process load

Spool Folders¶

Spool folders are most commonly used for:
- E-mail daemons (Postfix, Exchange, etc…)
- Printer managers (CUPS, lpr, etc…)
- Job managers (CRON, etc…)
Spool folders are folders reserved for a single process that’s single task is to monitor the folder and process each new file created in the folder. Each file in the folder represents a task to complete.
Spool folders, like other persisted queueing systems are resilient to failure. If the processing daemon crashes, it can be restarted without losing the task list.
Often, spool folders are processed by some defined order. One typical order is to process files alphabetically.
If the jobs are not meant to be repeated, files are typically moved to another folder upon completion or deleted.

Spool Folders - Cron¶

Cron typically maintains a few spool folders under /etc:

/etc/cron.daily
/etc/cron.hourly
/etc/cron.monthly
/etc/cron.weekly

Cron will, at the correct time, enter each of these folders and execute every executable file in each of these folders.

Spool Folders - CUPS¶

CUPS is a printer daemon for UNIX operating systems
The spool folder for CUPS is typically /var/spool/cups
In the spool folder there are two types of files:
- Data files - The object that is being printed
  
  Named d00001-001, d00001-002, d00002-001,….
- Control files - A file that represents a set of data files
  
  Named c00001, c00002, ….
The use of this file naming convention exposes a domain model of sorts that the CUPS system respects in its queue.
CUPS has a series of programs that manage the creation of files in the spooling folder and the processing of files once in the spooling folder.

Lock Files¶

A useful aspect of all system calls is that they are atomic operations. This means that some system calls can be used to perform test-and-set like operations and be the basis of locking systems.
A common example is the use of files to make sure only one instance of a software program is running at one time.
- For example, you would not want to HTTP daemons running on the same port.
- To prevent this, you could create a lock file like /var/lock/http_80.
- When the HTTP daemon starts up, it can check very early on for a /var/lock/http_## for the port it is configured on before proceeding. When the daemon shuts down it can delete the file
The creation of and deletion of files is an atomic operation. So, if two processes both try at the same time to create the same file, only one will succeed.

Doors¶

Doors pretty much only exist on Solaris and nowhere else
Even so, they are an interesting concept.
Doors basically allow a process to expose one or more functions through one or more files on the filesystem. It is basically a file system based RPC mechanism

Server Code¶

void server(void* cookie, char* argp, size_t arg_size, door_desc_t* dp, uint_t n_desc) {

    /*server code goes here*/

}

int doorfd = door_create(server, 0, 0);
int fd = creat("/tmp/door", 0666);
fdetach("/tmp/door");
fattach(doorfd,"/tmp/door");
pause();

Client Code¶

typdef struct myArg {
    int id
} myArg_t;

door_arg_t d_arg;
int doorfd = open("/tmp/door", O_RDONLY);
myArg_t* arg = (myArg_t*)malloc(sizeof(myArg_t));
arg->id = 12;
d_arg.data_ptr = (char*)arg;
d_arg.data_size = sizeof(*arg);
d_arg.desc_ptr = NULL;
d_arg.desc_num = 0;
door_call(doorfd, &d_arg);

Domain Sockets¶

Domain sockets serve the same purpose as named pipes, except that domain sockets are:
- Full - duplex
- Can have many clients to one server
- Support datagram and streaming modes
Domain sockets use functions that are very similar to what is used with internet sockets:
- accept, bind, listen, connect, socket
The setup for domain sockets can be a bit complex, so the best way to explain is through a simple example.

Domain Sockets - Example¶

int server_listen(const char *fileName) {
  unlink(fileName);
  int socket_fd = socket(PF_UNIX, SOCK_STREAM, 0);
  struct sockaddr_un address;
  memset(&address, 0, sizeof(struct sockaddr_un));
  address.sun_family = AF_UNIX;
  sprintf(address.sun_path, fileName);

  bind(socket_fd, (struct sockaddr*)&address, sizeof(struct sockaddr_un));
  listen(socket_fd, 5);
  int connection_fd;
  socklen_t address_length;
  while((connection_fd = accept(socket_fd, (struct sockaddr*)&address, &address_length)) > (-1)) {
     int child = fork();
     if(child == 0) {
        return connection_handler(connection_fd);
     } else {
        close(connection_fd);
     } 
  }

  close(socket_fd);
  unlink(fileName);
  return 0;
}

Domain Sockets - Example¶

int connection_handler(int socket_fd) {
  char buff[256];
  int nBytes = read(socket_fd, buff, 256);
  buff[nBytes] = 0;
  printf("message from client: %s\n", buff);
  nBytes = snprintf(buff, 256, "hello from server");
  write(socket_fd, buff, nBytes);

  close(socket_fd);
  return 0;
}

Domain Sockets - Example¶

int client_connect(const char* fileName) {
  int socket_fd = socket(PF_UNIX, SOCK_STREAM, 0);

  struct sockaddr_un address;
  memset(&address, 0, sizeof(struct sockaddr_un));
  address.sun_family = AF_UNIX;
  sprintf(address.sun_path, fileName);

  connect(socket_fd, (struct sockaddr*)&address, sizeof(struct sockaddr_un));
  char buffer[256];
  int nBytes = snprintf(buffer, 256, "hello from a client");
  write(socket_fd, buffer, nBytes);

  nBytes = read(socket_fd, buffer, 256);
  buffer[nBytes] = 0;

  printf("message from server: %s\n", buffer);

  close(socket_fd);

  return 0;
}