Minitalk

Usage

Prerequisites

Clone the repository to your local machine using the following command in the terminal.

git clone https://github.com/milandekruijf/minitalk.git && cd minitalk

Compiling

To build both the server and client, run the following command in the project root directory.

make

Compiles using the cc compiler with the flags -Wall, -Wextra, and -Werror.

Running

After compiling, the executables server and client are created in the /out directory.

1. Start the server in one terminal (it prints its process ID and waits for signals):

./out/server

2. In another terminal, send a message to that PID:

./out/client <server_pid> "your message here"

The server prints the received characters and a newline when the message ends. The client exits after sending.

Debugging

This repository does not define a make debug target. To inspect the programs with Valgrind, run it on each executable as needed—for example, start the server under Valgrind in one terminal, then run the client normally in another.

valgrind --leak-check=full --show-leak-kinds=all --track-origins=yes ./out/server

Testing

There is no make test target and no bundled automated test suite in this project. You can verify behavior manually with the server and client as described above.

Linting

There is no make lint target. If you use Norminette for 42 coding standards, run it yourself from the project root on the sources you want to check.

Features

Minitalk implements a minimal signal-based protocol between a server and a client.

General

• Server lifecycle: The server takes no arguments, displays its PID, installs signal handlers, and runs until you stop it (for example with Ctrl-C).
• Client invocation: The client expects exactly two arguments: the server PID (digits only) and the message string.
• Transport over signals: Each byte is sent bit by bit using SIGUSR1 and SIGUSR2; the server reconstructs bytes and prints them with ft_printf.
• Flow control: After each bit, the server acknowledges the client with a signal so bits are not lost under normal UNIX signal delivery.
• Message boundary: The client sends a null byte after the string; the server prints a newline when that terminator is received.

Internals (high level)

• Encoding: Bits are sent least-significant-bit first; SIGUSR1 and SIGUSR2 represent 0 and 1 respectively (src/client/write.c).
• Server handler: The server uses sigaction with SA_SIGINFO to read the sender PID and accumulate bits (src/server/listen.c, src/server/read.c).
• Client wait: The client waits for the server’s acknowledgment between bits via pause() and a SIGUSR1 handler (src/client/write.c, src/client/recv.c).
• Library: The project links against a local libft in lib/ft.

Limitations

• Throughput: Signal-based IPC is slow and not suited to large or high-frequency data.
• Robustness: Behavior depends on timely delivery and handling of signals; very long messages or hostile scenarios are outside the scope of this exercise.
• Scope: This is a learning exercise, not a general-purpose or secure messaging channel.

Acknowledgements

• Valgrind: Useful for checking memory use when debugging the server or client.
• Norminette: Optional linter aligned with 42 coding norms.
• 42: The school network where this project fits into the curriculum.
• Codam: The 42 campus in the Netherlands.