Introduction

Files and sockets are fundamental input/output resources. Files provide access to persistent or device-backed data, while sockets provide communication between processes on the same machine or across a network.

On POSIX systems, applications commonly access both resources through file descriptors. This unified interface allows functions such as read(), write() and close() to work with several kinds of operating-system-managed resources.

Applications use files and sockets to:

• Read configuration and application data
• Write logs and reports
• Persist records
• Transfer files
• Communicate between processes
• Accept client connections
• Send requests and responses
• Stream messages and events

In your System Design curriculum, Files and Sockets is Topic 2.6 under Computer Systems, Linux and Concurrency. It follows synchronization, race conditions and deadlocks, and prepares learners for Linux process and network diagnostic tools.

Prerequisites

What Is a File?

A regular file is a named filesystem object containing a sequence of bytes. The filesystem also maintains metadata describing the object.

File metadata can include:

• File type
• File size
• Owner and group identifiers
• Permission bits
• Modification and access timestamps
• Filesystem-specific identifiers
• Links to the underlying object

Simplified Filesystem Relationship

Pathname
   |
   v
Directory Entry
   |
   v
Filesystem Object Metadata
   |
   v
File Data Blocks

A pathname identifies a route through directories. After a file is opened, the process normally performs I/O using the returned descriptor rather than repeating pathname resolution for every operation.

File Descriptors

A file descriptor is a non-negative integer used by a process to refer to an open kernel-managed I/O resource.

File descriptors can refer to:

• Regular files
• Directories
• Pipes
• Devices
• Network sockets
• Local-domain sockets
• Other platform-specific resources

Standard Descriptors

Descriptor Relationship

Application Process

Descriptor 0 ----> Standard Input
Descriptor 1 ----> Standard Output
Descriptor 2 ----> Standard Error
Descriptor 3 ----> Open File
Descriptor 4 ----> Network Socket
Descriptor 5 ----> Pipe

File Descriptor vs FILE Stream

C supports standard I/O streams through the FILE type, while POSIX systems provide lower-level descriptor operations.

Do not close the same underlying resource independently through both interfaces unless ownership and conversion behaviour are carefully defined.

Opening a File

The POSIX open() function opens a filesystem object and returns a file descriptor.

#include <fcntl.h>

int descriptor =
    open(
        "input.txt",
        O_RDONLY
    );

Common flags include:

Reading from a Descriptor

The POSIX read() function requests bytes from an open descriptor.

#include <unistd.h>

unsigned char buffer[4096];

ssize_t amount =
    read(
        descriptor,
        buffer,
        sizeof buffer
    );

Interpreting the Result

A successful read can return fewer bytes than requested. Correct programs process the returned byte count rather than assuming the buffer was filled.

Writing to a Descriptor

const char message[] =
    "Hello, file descriptor!\n";

ssize_t amount =
    write(
        descriptor,
        message,
        sizeof message - 1
    );

A successful write can report fewer bytes than requested. Applications requiring completion must continue from the first unwritten byte.

Complete Write Helper

#include <errno.h>
#include <stddef.h>
#include <unistd.h>

static int write_all(
    int descriptor,
    const void *data,
    size_t size)
{
    const unsigned char *bytes =
        data;

    size_t written = 0;

    while (written < size) {
        ssize_t result =
            write(
                descriptor,
                bytes + written,
                size - written
            );

        if (result > 0) {
            written +=
                (size_t)result;

            continue;
        }

        if (result == -1 &&
            errno == EINTR) {

            continue;
        }

        return 0;
    }

    return 1;
}

For nonblocking descriptors, a temporary unavailable condition requires an event-waiting or retry policy rather than an uncontrolled immediate loop.

Complete File-copy Example

#define _POSIX_C_SOURCE 200809L

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

static int write_all(
    int descriptor,
    const void *data,
    size_t size)
{
    const unsigned char *bytes =
        data;

    size_t written = 0;

    while (written < size) {
        ssize_t result =
            write(
                descriptor,
                bytes + written,
                size - written
            );

        if (result > 0) {
            written +=
                (size_t)result;

            continue;
        }

        if (result == -1 &&
            errno == EINTR) {

            continue;
        }

        return 0;
    }

    return 1;
}

static int copy_file(
    const char source_name[],
    const char destination_name[])
{
    int source =
        open(
            source_name,
            O_RDONLY
        );

    if (source == -1) {
        perror(
            "Unable to open source"
        );

        return 0;
    }

    int destination =
        open(
            destination_name,
            O_WRONLY |
            O_CREAT |
            O_TRUNC,
            0644
        );

    if (destination == -1) {
        perror(
            "Unable to open destination"
        );

        close(source);

        return 0;
    }

    unsigned char buffer[8192];
    int succeeded = 1;

    for (;;) {
        ssize_t amount =
            read(
                source,
                buffer,
                sizeof buffer
            );

        if (amount > 0) {
            if (!write_all(
                    destination,
                    buffer,
                    (size_t)amount)) {

                perror(
                    "Unable to write"
                );

                succeeded = 0;

                break;
            }

            continue;
        }

        if (amount == 0) {
            break;
        }

        if (errno == EINTR) {
            continue;
        }

        perror(
            "Unable to read"
        );

        succeeded = 0;

        break;
    }

    if (close(source) == -1) {
        succeeded = 0;
    }

    if (close(destination) == -1) {
        succeeded = 0;
    }

    return succeeded;
}

int main(
    int argc,
    char *argv[])
{
    if (argc != 3) {
        fprintf(
            stderr,
            "Usage: %s SOURCE DESTINATION\n",
            argv[0]
        );

        return EXIT_FAILURE;
    }

    return
        copy_file(
            argv[1],
            argv[2]
        )
            ? EXIT_SUCCESS
            : EXIT_FAILURE;
}

Compile and Run

cc -std=c17 -Wall -Wextra -Wpedantic file_copy.c -o file_copy
./file_copy source.txt destination.txt

This educational example handles partial writes and interrupted operations. A production copy utility can additionally preserve metadata, avoid unsafe destination replacement, validate source and destination identity, and define durability requirements.

File Position

Regular-file descriptors commonly have a current file offset. Reads and writes can advance that offset.

File bytes:

0 1 2 3 4 5 6 7 8 9
          ^
          Current offset

POSIX lseek() can reposition the offset for supported resources.

off_t position =
    lseek(
        descriptor,
        0,
        SEEK_SET
    );

Pipes and stream sockets do not support ordinary random-access seeking.

Buffered and Unbuffered I/O

The terms buffered and unbuffered require context. Low-level descriptor I/O can still pass through kernel caches and device buffers. Standard C streams add user-space library buffering.

Application
    |
    | fwrite()
    v
C Library Buffer
    |
    | write()
    v
Kernel / Filesystem Cache
    |
    v
Storage Device

Buffering can:

• Combine several small operations
• Reduce system-call frequency
• Improve sequential transfer efficiency
• Delay visibility of buffered output
• Require explicit flushing at selected boundaries

Flush vs Durable Storage

Moving data from an application buffer to the kernel is not necessarily the same as persisting the data to stable storage.

Application Buffer
       |
       | fflush() or write()
       v
Operating-system Buffer
       |
       | Filesystem and device persistence
       v
Durable Storage

The required guarantee should be based on the application's data-loss and recovery requirements. Stronger durability can add latency and reduce write throughput.

What Is a Socket?

A socket is a communication endpoint. A successful POSIX socket() call returns a file descriptor referring to that endpoint.

#include <sys/socket.h>

int socket_descriptor =
    socket(
        AF_INET,
        SOCK_STREAM,
        0
    );

The main arguments select:

• The communication domain or address family
• The socket type and communication semantics
• The protocol, explicitly or through a default selection

Common Socket Types

Address Families

Address-family availability and behaviour depend on the target operating system.

TCP Server Lifecycle

TCP Client Lifecycle

Name resolution can return several candidate addresses. A robust client evaluates applicable candidates and applies a documented connection deadline and error policy.

Minimal POSIX TCP Server

The following educational server accepts one IPv4 connection, reads one block of bytes and echoes the received bytes back to the client.

#define _POSIX_C_SOURCE 200809L

#include <arpa/inet.h>
#include <errno.h>
#include <netinet/in.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <sys/socket.h>
#include <unistd.h>

enum
{
    SERVER_PORT = 8080,
    BUFFER_CAPACITY = 4096
};

static int send_all(
    int socket_descriptor,
    const void *data,
    size_t size)
{
    const unsigned char *bytes =
        data;

    size_t sent = 0;

    while (sent < size) {
        ssize_t result =
            send(
                socket_descriptor,
                bytes + sent,
                size - sent,
                0
            );

        if (result > 0) {
            sent +=
                (size_t)result;

            continue;
        }

        if (result == -1 &&
            errno == EINTR) {

            continue;
        }

        return 0;
    }

    return 1;
}

int main(void)
{
    int listener =
        socket(
            AF_INET,
            SOCK_STREAM,
            0
        );

    if (listener == -1) {
        perror(
            "socket"
        );

        return EXIT_FAILURE;
    }

    int reuse = 1;

    if (setsockopt(
            listener,
            SOL_SOCKET,
            SO_REUSEADDR,
            &reuse,
            sizeof reuse) == -1) {

        perror(
            "setsockopt"
        );

        close(listener);

        return EXIT_FAILURE;
    }

    struct sockaddr_in address;

    memset(
        &address,
        0,
        sizeof address
    );

    address.sin_family =
        AF_INET;

    address.sin_addr.s_addr =
        htonl(INADDR_ANY);

    address.sin_port =
        htons(SERVER_PORT);

    if (bind(
            listener,
            (const struct sockaddr *)
                &address,
            sizeof address) == -1) {

        perror(
            "bind"
        );

        close(listener);

        return EXIT_FAILURE;
    }

    if (listen(
            listener,
            16) == -1) {

        perror(
            "listen"
        );

        close(listener);

        return EXIT_FAILURE;
    }

    puts(
        "Waiting for one connection..."
    );

    int client =
        accept(
            listener,
            NULL,
            NULL
        );

    if (client == -1) {
        perror(
            "accept"
        );

        close(listener);

        return EXIT_FAILURE;
    }

    unsigned char buffer[
        BUFFER_CAPACITY
    ];

    ssize_t amount;

    do {
        amount =
            recv(
                client,
                buffer,
                sizeof buffer,
                0
            );
    } while (
        amount == -1 &&
        errno == EINTR
    );

    int succeeded = 1;

    if (amount > 0) {
        succeeded =
            send_all(
                client,
                buffer,
                (size_t)amount
            );
    } else if (amount == -1) {
        perror(
            "recv"
        );

        succeeded = 0;
    }

    if (close(client) == -1) {
        succeeded = 0;
    }

    if (close(listener) == -1) {
        succeeded = 0;
    }

    return
        succeeded
            ? EXIT_SUCCESS
            : EXIT_FAILURE;
}

Compile

cc -std=c17 -Wall -Wextra -Wpedantic tcp_server.c -o tcp_server

This example handles only one connection and one received block. A production server additionally requires protocol framing, size limits, authentication where needed, deadlines, concurrent-connection control, graceful shutdown, overload handling and observability.

Minimal POSIX TCP Client

#define _POSIX_C_SOURCE 200809L

#include <arpa/inet.h>
#include <errno.h>
#include <netinet/in.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <sys/socket.h>
#include <unistd.h>

enum
{
    SERVER_PORT = 8080
};

static int send_all(
    int socket_descriptor,
    const void *data,
    size_t size)
{
    const unsigned char *bytes =
        data;

    size_t sent = 0;

    while (sent < size) {
        ssize_t result =
            send(
                socket_descriptor,
                bytes + sent,
                size - sent,
                0
            );

        if (result > 0) {
            sent +=
                (size_t)result;

            continue;
        }

        if (result == -1 &&
            errno == EINTR) {

            continue;
        }

        return 0;
    }

    return 1;
}

int main(void)
{
    int connection =
        socket(
            AF_INET,
            SOCK_STREAM,
            0
        );

    if (connection == -1) {
        perror(
            "socket"
        );

        return EXIT_FAILURE;
    }

    struct sockaddr_in server;

    memset(
        &server,
        0,
        sizeof server
    );

    server.sin_family =
        AF_INET;

    server.sin_port =
        htons(SERVER_PORT);

    if (inet_pton(
            AF_INET,
            "127.0.0.1",
            &server.sin_addr) != 1) {

        fprintf(
            stderr,
            "Invalid server address.\n"
        );

        close(connection);

        return EXIT_FAILURE;
    }

    if (connect(
            connection,
            (const struct sockaddr *)
                &server,
            sizeof server) == -1) {

        perror(
            "connect"
        );

        close(connection);

        return EXIT_FAILURE;
    }

    const char request[] =
        "Hello from the client.";

    if (!send_all(
            connection,
            request,
            sizeof request - 1)) {

        perror(
            "send"
        );

        close(connection);

        return EXIT_FAILURE;
    }

    unsigned char response[4096];

    ssize_t amount;

    do {
        amount =
            recv(
                connection,
                response,
                sizeof response,
                0
            );
    } while (
        amount == -1 &&
        errno == EINTR
    );

    if (amount > 0) {
        if (!write_all(
                STDOUT_FILENO,
                response,
                (size_t)amount) ||
            !write_all(
                STDOUT_FILENO,
                "\n",
                1)) {

            close(connection);

            return EXIT_FAILURE;
        }
    } else if (amount == -1) {
        perror(
            "recv"
        );

        close(connection);

        return EXIT_FAILURE;
    }

    if (close(connection) == -1) {
        return EXIT_FAILURE;
    }

    return EXIT_SUCCESS;
}

TCP Is a Byte Stream

A TCP stream delivers an ordered sequence of bytes. It does not preserve the boundaries of individual application send() calls.

Sender:

send("HELLO")
send("WORLD")


Receiver can observe:

recv() -> "HELLOWORLD"

or:

recv() -> "HEL"
recv() -> "LOWOR"
recv() -> "LD"

or another valid segmentation.

The application protocol must define how the receiver identifies complete messages.

Message Framing

Common framing strategies include:

Length-prefixed Message

+----------------------+-------------------------+
| 4-byte payload size  | Payload bytes           |
+----------------------+-------------------------+

A receiver should:

1. Read the complete fixed-size header.
2. Decode the length using the documented byte order.
3. Reject lengths above the protocol limit.
4. Allocate or select a bounded buffer.
5. Read exactly the stated payload length.
6. Validate the message contents.

Read-exactly Helper

#include <errno.h>
#include <stddef.h>
#include <sys/socket.h>

static int receive_exactly(
    int socket_descriptor,
    void *destination,
    size_t size)
{
    unsigned char *bytes =
        destination;

    size_t received = 0;

    while (received < size) {
        ssize_t result =
            recv(
                socket_descriptor,
                bytes + received,
                size - received,
                0
            );

        if (result > 0) {
            received +=
                (size_t)result;

            continue;
        }

        if (result == 0) {
            return 0;
        }

        if (errno == EINTR) {
            continue;
        }

        return 0;
    }

    return 1;
}

This blocking helper waits until all requested bytes arrive, the peer closes the stream or an error occurs. Production use should also apply an appropriate deadline.

Blocking I/O

A blocking operation can suspend the calling thread until data, connection progress, resource capacity or an error becomes available.

Thread calls recv()
        |
        +--> Data available: return bytes
        |
        +--> Peer closed: return end-of-stream result
        |
        +--> Error: report failure
        |
        +--> No data: thread waits

Blocking I/O can provide simple control flow, but every blocked connection consumes associated state and possibly a thread.

Nonblocking I/O

In nonblocking mode, an operation that cannot make immediate progress returns a temporary unavailable result instead of waiting indefinitely.

Attempt read
     |
     +--> Data available: process bytes
     |
     +--> End of stream: close connection
     |
     +--> Temporary unavailable:
             wait for readiness through an event mechanism
     |
     +--> Permanent error:
             close or recover according to policy

Nonblocking I/O requires careful state management for partially received and partially sent messages.

I/O Readiness

POSIX systems provide mechanisms that allow an application to wait for readiness across several descriptors.

Examples include:

• select()
• poll()
• Platform-specific scalable event facilities

Readiness means an operation may make progress without blocking in the expected way. It does not guarantee that an entire application message can be read or written in one operation.

Partial Socket Writes

A successful send() can accept only part of the application buffer. The application must retain the unsent bytes.

Application message: 10,000 bytes

send() accepts: 4,000 bytes

Remaining:
6,000 bytes beginning at offset 4,000

In an event-driven server, the remaining bytes are commonly stored in connection-specific output state and retried when the socket becomes writable.

End of Stream

For a stream socket, a receive result of zero indicates that the peer has performed an orderly closure of its sending side.

Peer sends bytes
      |
      v
Peer closes sending direction
      |
      v
Receiver drains remaining bytes
      |
      v
recv() returns 0

End of stream is not the same as an empty application message. The protocol must define whether closure is expected at that point.

Half-close

A stream socket can support closing one communication direction while retaining the other.

Client:

Send request
Shutdown client sending direction
Continue receiving response


Server:

Read until client end of stream
Generate response
Send response
Close connection

POSIX shutdown() controls selected communication directions. The application protocol must define whether half-close is supported.

Datagram Sockets

Datagram sockets send and receive individual datagrams rather than one continuous byte stream.

Sender:

Datagram A
Datagram B
Datagram C


Receiver:

Receives individual datagrams,
subject to transport and network behaviour.

Datagram applications must consider:

• Loss
• Duplication
• Reordering
• Maximum datagram size
• Truncation when the receive buffer is too small
• Sender identity
• Application-level retry and deduplication where required

Regular Files vs Stream Sockets

Concurrent Descriptor Access

Threads within one process can access the same descriptor, but safe behaviour requires an explicit ownership model.

Shared File Offset

Thread A reads from shared descriptor
Thread B reads from shared descriptor

Both operations affect the shared open-file position
according to the descriptor relationship and platform semantics.

Possible designs include:

• One owner thread performs all I/O.
• A mutex protects position-dependent operations.
• Position-explicit operations are used when supported.
• Each worker opens an independent descriptor when appropriate.

Interleaved Socket Writes

Thread A sends message header A.
Thread B sends message header B.
Thread A sends payload A.
Thread B sends payload B.

Peer observes a byte stream that does not match
the intended complete-message ordering.

A connection should normally have one output owner or a synchronized output queue that preserves protocol framing.

Descriptor Ownership

For every descriptor, define:

• Who creates or receives it
• Who is allowed to read it
• Who is allowed to write it
• Who closes it
• Whether ownership can be transferred
• Whether several threads can access it
• How shutdown is communicated
• How errors are reported

Duplicated Descriptors

POSIX duplication functions can create several descriptor numbers referring to the same underlying open resource relationship.

Descriptor 3 ----+
                 +--> Open Resource
Descriptor 8 ----+

Closing one descriptor releases that descriptor reference. The underlying resource remains open while another descriptor reference still exists.

Duplicated descriptors can share resource state such as a file position, depending on how they were created.

Descriptors Across fork()

A child process created through POSIX fork() inherits descriptor references according to platform semantics.

Before fork:

Parent Descriptor 3 ---> Open File


After fork:

Parent Descriptor 3 ---+
                       +--> Related Open File Description
Child Descriptor 3 ----+

Parent and child must define which process retains each descriptor. Unneeded copies should be closed so end-of-stream and resource-release behaviour are not delayed unexpectedly.

File Locking

File locks can coordinate cooperating processes, but locking semantics vary by platform and interface.

A file-lock design should define:

• The protected file or byte range
• Shared vs exclusive access
• Whether locks are advisory or mandatory
• The process or descriptor ownership model
• Lock ordering across several files
• Behaviour after process termination
• Timeout and recovery policies

A lock works only when every participating writer follows the same protocol.

Safe File Replacement

Directly truncating the active file before writing can destroy the only recoverable copy when the write fails.

Safer Replacement Pattern

Write new content to a temporary file
        |
        v
Check every write
        |
        v
Apply the required durability operation
        |
        v
Close successfully
        |
        v
Validate temporary content where required
        |
        v
Replace the destination according to platform rules
        |
        v
Preserve or clean up backup according to policy

Replacement atomicity, durability and metadata behaviour depend on the filesystem, operating system and whether source and destination are on the same filesystem.

Timeouts and Deadlines

Network operations should not wait indefinitely when the application has a finite request deadline.

A timeout policy should define:

• Connection-establishment timeout
• Read timeout
• Write timeout
• Complete-operation deadline
• Retry ownership
• Maximum retry attempts
• Behaviour after uncertain completion
• Cancellation and cleanup

A timeout does not prove that the remote operation failed. A request or write may have reached the peer even if the response was not observed.

Interrupted Operations

Some blocking POSIX calls can return an interruption error when a signal is handled.

ssize_t amount;

do {
    amount =
        read(
            descriptor,
            buffer,
            sizeof buffer
        );
} while (
    amount == -1 &&
    errno == EINTR
);

Retrying is appropriate only when the operation contract and application cancellation policy permit it.

Broken Connections

Socket operations can fail because the peer closed the connection, the network path failed, a deadline expired or the local system rejected the operation.

The application should:

• Check every operation result
• Distinguish temporary from permanent conditions
• Stop using connections in an invalid state
• Release associated buffers and application state
• Record useful diagnostics without exposing sensitive payloads
• Retry only when the business operation is safe

Security Considerations

File and socket code should validate:

• Path and filename policy
• File type
• Ownership and permissions
• Symbolic-link behaviour
• Input length
• Message framing
• Protocol version
• Numeric fields and byte order
• Authentication and authorization
• Resource-consumption limits

Never Trust a Network Length

uint32_t payload_size =
    receive_length();

unsigned char *payload =
    malloc(payload_size);

enum
{
    MAXIMUM_PAYLOAD_SIZE =
        1024 * 1024
};

uint32_t payload_size =
    receive_length();

if (payload_size == 0 ||
    payload_size >
        MAXIMUM_PAYLOAD_SIZE) {

    return PROTOCOL_ERROR;
}

unsigned char *payload =
    malloc(payload_size);

if (payload == NULL) {
    return ALLOCATION_ERROR;
}

Backpressure

Backpressure prevents a fast producer from creating unlimited buffered work for a slower consumer.

Fast Client
    |
    v
Bounded Input Buffer
    |
    +--> Capacity available:
    |       accept more data
    |
    +--> Buffer full:
            stop reading, delay,
            reject or close according to policy

Backpressure controls include:

• Bounded buffers
• Bounded queues
• Read suspension
• Request limits
• Connection limits
• Rate limiting
• Flow-control mechanisms
• Load shedding

Important Metrics

Linux Diagnostic Commands

List Open Descriptors

ls -l /proc/PROCESS_ID/fd

List Process Files and Sockets

lsof -p PROCESS_ID

Display Socket Summary

ss -s

Display Listening TCP Sockets

ss -ltnp

Display TCP Connections

ss -tnp

Trace File and Network System Calls

strace -f -e trace=file,network ./application

Observe Storage Activity

iostat -xz 1

Command availability, permissions and output vary by Linux distribution and environment. Diagnostic tools can add overhead and should follow the approved operational process.

Common Files and Sockets Mistakes

Recommended Test Cases

Files and Sockets Best Practices

Practice Exercise

Build a length-prefixed TCP echo service using POSIX sockets.

Requirements

1. The server listens on a configurable port.
2. Each message begins with a four-byte unsigned payload length.
3. The length is encoded in network byte order.
4. The maximum payload size is one megabyte.
5. The server reads the complete header before decoding it.
6. The server rejects a zero or oversized payload.
7. The server reads the exact payload length.
8. The server returns the same framed message.
9. Partial sends are handled correctly.
10. Peer closure during a message is treated as incomplete input.
11. Every accepted descriptor is closed exactly once.
12. The implementation records useful errors without logging payload content.

Protocol Format

Request:

+----------------------+---------------------------+
| 4-byte payload size  | Payload                   |
+----------------------+---------------------------+


Response:

+----------------------+---------------------------+
| 4-byte payload size  | Same payload              |
+----------------------+---------------------------+

Required Validation

Frequently Asked Questions