Inter-process communication — pipe, shared memory, message queue আর socket

১ · প্রসেস আলাদা কেন, আর তবু কথা বলতে হয় কেন

পর্ব ৮-এ দেখেছেন, প্রতিটি প্রসেস নিজের একটি জগতে থাকে। তার কোড, ডেটা, heap আর stack — সবকিছু তার নিজের address space-এ। একটি প্রসেস যদি 0x5000 ঠিকানায় লেখে, আরেকটি প্রসেসের 0x5000 ঠিকানায় কিছুই বদলায় না। কারণ দুজনের ঠিকানা আলাদা page table দিয়ে আলাদা physical মেমরিতে যায় (পর্ব ৩২)। এই দেয়ালটি OS ইচ্ছে করে বানায়, আর এটিই কম্পিউটারকে স্থিতিশীল রাখে।

দেয়ালের লাভ স্পষ্ট: একটি প্রসেস ক্র্যাশ করলে বাকিরা টিকে থাকে, আর একটি দুষ্ট প্রোগ্রাম আপনার ব্যাংকিং অ্যাপের মেমরি থেকে পাসওয়ার্ড পড়তে পারে না।

Independent আর cooperating প্রসেস

পাঠ্যবই প্রসেসকে দুই ভাগে ভাগ করে। যে প্রসেস অন্য কোনো প্রসেসের কাজে প্রভাব ফেলে না এবং অন্যের দ্বারা প্রভাবিতও হয় না, সে independent process. যেমন আপনার ক্যালকুলেটর আর গান-শোনার অ্যাপ — একসাথে চললেও কেউ কারও তথ্য নেয় না। আর যে প্রসেস অন্যের সাথে তথ্য ভাগ করে, অন্যের কাজে প্রভাব ফেলে বা প্রভাবিত হয়, সে cooperating process. Cooperating প্রসেসের জন্যই IPC লাগে।

প্রসেসকে একসাথে কাজ করানোর কারণগুলো পরীক্ষায় প্রায়ই চাওয়া হয়:

খেয়াল করুন, একই প্রসেসের ভেতরের thread-গুলোর এই সমস্যা নেই — তারা একই address space ভাগ করে (পর্ব ১৪)। তবে thread-এর ভাগাভাগি “সব অথবা কিছুই না” — একটি thread মেমরি নষ্ট করলে পুরো প্রসেস পড়ে যায়। প্রসেস আর IPC দিয়ে আপনি ঠিক করেন কোন তথ্যটুকু ভাগ হবে।

২ · দুই মডেল — shared memory বনাম message passing

সব IPC ব্যবস্থাকেই শেষ পর্যন্ত দুই মডেলের একটিতে ফেলা যায়। পার্থক্যটি মূলত একটি প্রশ্নে: ডেটা পৌঁছাতে প্রতিবার kernel-কে লাগে কি না।

অনেক পাঠ্যবই বলে, shared memory দ্রুত কারণ “kernel লাগে না”। কথাটি অর্ধেক সত্য। ডেটা পড়া-লেখায় kernel লাগে না ঠিকই, কিন্তু “কখন পড়ব?” — এই সমন্বয়ের জন্য প্রায়ই semaphore বা futex লাগে, যা ব্যস্ত অবস্থায় আবার kernel-এ যায়। আর বহু-core মেশিনে একই মেমরি দুই core-এ পালাক্রমে লেখা হলে cache line এক core থেকে আরেক core-এ ছোটাছুটি করে (cache coherence, পর্ব ৪)। তাই ছোট বার্তায় ব্যবধান বইয়ের ছবির মতো বিশাল নয়; বড় ডেটায় shared memory স্পষ্টভাবে জেতে।

৩ · Message passing-এর নকশা — কাকে, কখন, কতটুকু জমা

“বার্তা পাঠানো” কথাটি শুনতে সহজ। কিন্তু একটি message passing ব্যবস্থা বানাতে গেলে OS ডিজাইনারকে তিনটি প্রশ্নের উত্তর ঠিক করতে হয়। পরীক্ষা আর ইন্টারভিউতে এগুলো খুব চেনা।

প্রশ্ন ১ — নাম ধরে, নাকি ডাকবাক্সে? (direct বনাম indirect)

• Direct communication: প্রেরক প্রাপকের নাম ধরে পাঠায় — send(P, msg), receive(Q, msg). প্রতি জোড়া প্রসেসের মধ্যে ঠিক একটি সংযোগ। প্রাপক যেকোনো জনের কাছ থেকে নিতে চাইলে receive(any, msg) — একে বলে asymmetric addressing. অসুবিধা: প্রাপকের পরিচয় বদলালে সব প্রেরকের কোড বদলাতে হয়।
• Indirect communication: বার্তা যায় একটি mailbox বা port-এ — send(A, msg), receive(A, msg), যেখানে A একটি ডাকবাক্স। একই mailbox অনেক প্রসেস ভাগ করতে পারে, আর একজোড়া প্রসেস একাধিক mailbox দিয়ে যুক্ত থাকতে পারে। POSIX message queue, Mach port আর Windows ALPC port — সবই এই ধরনের।

Mailbox ভাগ করলে একটি প্রশ্ন ওঠে: P₁ পাঠাল, আর P₂ ও P₃ দুজনেই receive ডাকল — বার্তা পাবে কে? সমাধান তিনটি: এক mailbox-এ সর্বোচ্চ দুই প্রসেস; একসাথে মাত্র একজনকে receive করতে দেওয়া; অথবা সিস্টেম নিজে একজনকে বেছে নেবে। POSIX message queue-তে প্রতিটি বার্তা ঠিক একজন প্রাপক পায়।

প্রশ্ন ২ — অপেক্ষা করবে, নাকি ফিরে যাবে? (blocking বনাম non-blocking)

যখন send আর receive দুটোই blocking, তখন প্রেরক আর প্রাপক একটি মুহূর্তে “মিলিত” হয় — একে বলে rendezvous. Linux-এ fd-কে non-blocking করতে O_NONBLOCK flag লাগে; সার্ভার সাধারণত এর সাথে epoll ব্যবহার করে, যাতে একটি thread অনেক সংযোগ সামলাতে পারে।

প্রশ্ন ৩ — পথে কতগুলো বার্তা জমতে পারে? (buffering)

• Zero capacity: পথে কোনো বার্তা জমে না। প্রেরককে প্রাপক না নেওয়া পর্যন্ত অপেক্ষা করতেই হয় — স্বাভাবিকভাবেই rendezvous. Go ভাষার unbuffered channel ঠিক এমন।
• Bounded capacity: সর্বোচ্চ nটি বার্তা জমতে পারে। জায়গা থাকলে প্রেরক না থেমে চলে যায়; ভর্তি হলে অপেক্ষা করে। Pipe, POSIX message queue — বাস্তবের প্রায় সব ব্যবস্থাই এই ধরনের।
• Unbounded capacity: অসীম জায়গা, প্রেরক কখনো থামে না। এটি তাত্ত্বিক মডেল — বাস্তবে মেমরি একসময় শেষ হয়।

নিচের ডায়াগ্রামে ৩ ঘরের একটি bounded mailbox দেখুন। একজন প্রেরক (S) A থেকে F পর্যন্ত বার্তা পাঠাচ্ছে, একজন প্রাপক (R) নিচ্ছে। কখন কে ঘুমায়, কে জাগে, আর non-blocking চেষ্টায় কী ফেরে — খেয়াল করুন।

1R: receive(box)          ; empty2S: send(box, A)3R: gets A, works on it4S: send B; send C; send D5S: send(box, E)          ; full6R: receive -> B ; S wakes7S: try_send(box, F)      ; full8R: receive x3 -> C, D, E9R: try_receive(box)      ; empty

৪ · Pipe — সবচেয়ে পুরোনো, সবচেয়ে চেনা নালি

পর্ব ৩-এ shell-এ ls -l | grep txt লিখেছিলেন। ওই | চিহ্নের পেছনে আছে একটি anonymous pipe — kernel-এর ভেতরের একটি ছোট buffer, যার একদিকে লেখা হয় আর অন্যদিকে পড়া হয়। C-তে এটি পাওয়া যায় একটি system call দিয়ে:

int fd[2];
pipe(fd);      /* fd[0] = পড়ার মুখ (read end), fd[1] = লেখার মুখ (write end) */

Pipe-এর নিয়মগুলো ছোট, কিন্তু প্রতিটি গুরুত্বপূর্ণ:

• একমুখী: ডেটা শুধু fd[1] থেকে fd[0]-এর দিকে যায়। দুই দিকে কথা বলতে চাইলে দুটি pipe লাগে।
• বাইটের স্রোত: pipe বার্তার সীমানা মনে রাখে না। আপনি “cha” আর “puri” আলাদা দুটি write-এ পাঠালেও পাঠক একটি read-এ “chapuri” পেতে পারে। সীমানা লাগলে নিজে newline বা দৈর্ঘ্য দিয়ে চিহ্ন দিতে হয়।
• শুধু আত্মীয়দের জন্য: pipe-এর নাম নেই; অন্য প্রসেস এটি পায় শুধু fork-এর সময় file descriptor উত্তরাধিকার সূত্রে পেয়ে।
• সীমিত ধারণক্ষমতা: Linux-এ ডিফল্ট ৬৫,৫৩৬ বাইট (১৬টি page). খালি হলে read অপেক্ষা করে, ভর্তি হলে write অপেক্ষা করে।
• ছোট write অবিভাজ্য: PIPE_BUF বাইট (Linux-এ ৪০৯৬) বা কম লেখা অন্য লেখকের লেখার সাথে মেশে না; বড় write-এ মিশতে পারে।
• EOF আর SIGPIPE: সব লেখার মুখ বন্ধ হলে, buffer খালি হওয়ার পর read ফেরত দেয় 0 — অর্থাৎ ফাইলের শেষ। উল্টো দিকে, সব পড়ার মুখ বন্ধ থাকলে write করলে লেখক SIGPIPE signal পায় (ডিফল্টে প্রসেস শেষ), আর signal উপেক্ষা করা থাকলে write ব্যর্থ হয় EPIPE দিয়ে।

নিচের ডায়াগ্রামে বোঝার সুবিধার জন্য মাত্র ৮ বাইটের একটি খেলনা pipe নেওয়া হয়েছে (আসল Linux-এ ৬৫,৫৩৬)। ␤ চিহ্ন মানে newline, আর · মানে খালি ঘর।

1R: read(fd[0], buf, 16)2W: write(fd[1], "cha\n", 4)3R: read returns 44W: write(fd[1], "singara\n", 8)5W: write(fd[1], "puri\n", 5)6R: read(fd[0], buf, 6) -> 67W: (woken) write returns 58W: close(fd[1])9R: read returns 710R: read returns 0   ; EOF

হাতে-কলমে — parent লেখে, child পড়ে

এবার আসল pipe. Parent তিনটি অর্ডার লিখবে, child পড়বে যতক্ষণ না EOF আসে। দুটি জিনিস খেয়াল করুন: fork-এর আগে fflush(stdout) (না করলে stdout-এর buffer-এ থাকা লেখা দুই প্রসেসেই কপি হয়ে দুবার ছাপা হতে পারে — পর্ব ১০), আর দুই প্রসেসেই অব্যবহৃত মুখ বন্ধ করা।

#include <stdio.h>
#include <string.h>
#include <sys/wait.h>
#include <unistd.h>

int main(void) {
    int fd[2];                          /* fd[0] = read end, fd[1] = write end */
    if (pipe(fd) == -1) { perror("pipe"); return 1; }
    printf("pipe(): read end = fd %d, write end = fd %d\n", fd[0], fd[1]);
    fflush(stdout);                     /* flush BEFORE fork */

    pid_t pid = fork();
    if (pid == 0) {                     /* child = reader */
        close(fd[1]);                   /* close the unused write end! */
        char buf[16];
        ssize_t n, total = 0;
        while ((n = read(fd[0], buf, sizeof buf)) > 0) {
            fwrite(buf, 1, (size_t)n, stdout);
            total += n;
        }
        printf("child : read() returned %zd -> EOF after %zd bytes\n", n, total);
        fflush(stdout);
        _exit(0);
    }
    close(fd[0]);                       /* parent = writer */
    const char *orders[] = {"order 1: cha\n", "order 2: singara\n", "order 3: puri\n"};
    for (int i = 0; i < 3; i++)
        if (write(fd[1], orders[i], strlen(orders[i])) == -1) perror("write");
    close(fd[1]);                       /* last write end closed -> reader sees EOF */
    waitpid(pid, NULL, 0);
    printf("parent: child has finished, pipe is gone\n");
    return 0;
}

pipe(): read end = fd 3, write end = fd 4
order 1: cha
order 2: singara
order 3: puri
child : read() returned 0 -> EOF after 44 bytes
parent: child has finished, pipe is gone

সবচেয়ে চেনা বাগ — “read কখনো শেষ হয় না”

উপরের কোড থেকে child-এর close(fd[1]); লাইনটি মুছে দিলে কী হয়? প্রোগ্রাম তিনটি অর্ডার ছাপবে, তারপর চিরকাল আটকে থাকবে। কোনো error নেই, crash নেই — শুধু নীরবতা। কারণটি fork-এর একটি সরল নিয়মে: fork-এর পর প্রতিটি খোলা file descriptor দুই প্রসেসেই থাকে, আর kernel গোনে মোট কতগুলো লেখার মুখ খোলা।

1parent: pipe(fd)2parent: fork()3parent: write x3; close(fd[1])4child : read ... 44 bytes5child : read()   ; waits forever6FIX child: close(fd[1]) first

৫ · Named pipe (FIFO) — নামওয়ালা নালি

Anonymous pipe-এর বড় সীমাবদ্ধতা: নাম নেই, তাই শুধু fork-সূত্রে আত্মীয় প্রসেসরাই ব্যবহার করতে পারে। দুটি সম্পূর্ণ আলাদা প্রোগ্রাম — ধরুন একটি log সংগ্রাহক আর একটি সার্ভার, যাদের আলাদা সময়ে আলাদা মানুষ চালু করেছেন — কীভাবে pipe ভাগ করবে? উত্তর: FIFO (first in, first out), যাকে named pipe-ও বলে।

FIFO হলো ফাইল সিস্টেমে একটি বিশেষ ধরনের নাম। তৈরি করতে shell-এ mkfifo name বা C-তে mkfifo(path, mode). যে প্রসেস নামটি জানে আর অনুমতি আছে, সে সাধারণ ফাইলের মতো open করতে পারে। কিন্তু ডেটা ডিস্কে লেখা হয় না — ভেতরে এটি অবিকল pipe, kernel-এর মেমরির buffer. FIFO-র একটি বিশেষ আচরণ: পড়ার জন্য open করলে লেখক না আসা পর্যন্ত, আর লেখার জন্য open করলে পাঠক না আসা পর্যন্ত open নিজেই অপেক্ষা করে।

নিচের স্ক্রিপ্টে একটি FIFO বানিয়ে পেছনে (background) একজন লেখক চালানো হয়েছে, তারপর আলাদাভাবে একজন পাঠক:

mkfifo kitchen.fifo                     # a named pipe, created in the cwd
ls -l kitchen.fifo | cut -c1-10         # first letter p = pipe
[ -p kitchen.fifo ] && echo "test -p: kitchen.fifo is a FIFO"

# writer runs in the background; open() blocks until a reader opens the FIFO
( for o in cha singara puri; do echo "order: $o"; done > kitchen.fifo ) &
writer=$!
sleep 0.3
echo "writer state while no reader: $(ps -o stat= -p "$writer")"

# reader: unrelated to the writer, finds it only by the file name
while read -r line; do echo "reader got -> $line"; done < kitchen.fifo
wait "$writer"
echo "writer exit status: $?"
echo "bytes stored in the FIFO on disk: $(stat -c %s kitchen.fifo)"
rm kitchen.fifo

prw-r--r--
test -p: kitchen.fifo is a FIFO
writer state while no reader: SN
reader got -> order: cha
reader got -> order: singara
reader got -> order: puri
writer exit status: 0
bytes stored in the FIFO on disk: 0

FIFO কাজে লাগে একই মেশিনের সহজ কাজে, যেমন একটি ছোট daemon-কে কমান্ড পাঠানো। অনেক লেখক থাকলে PIPE_BUF-এর চেয়ে বড় লেখা মিশে যেতে পারে, আর উত্তর ফেরত পাঠাতে আলাদা FIFO লাগে।

৬ · Shared memory আর mmap — একই পাতা, দুই ঘরে

Message passing-এ প্রতিটি বাইট অন্তত দুবার কপি হয়। প্রায় ৮ MB-এর একটি Full HD ভিডিও ফ্রেম (১৯২০ × ১০৮০ পিক্সেল, প্রতিটি ৪ বাইট) প্রতি সেকেন্ডে ৩০ বার পাঠাতে হলে সেটি অনেক খরচ। Shared memory এর সমাধান: kernel একই physical মেমরির পাতা (page frame) দুই প্রসেসের page table-এ বসিয়ে দেয়। দুজনের কাছে এটি নিজের মেমরির মতোই — সাধারণ পয়েন্টার দিয়ে পড়া-লেখা।

Linux/POSIX-এ তিন উপায়

প্রথমটি সবচেয়ে সহজ, আর আমাদের পরীক্ষার জন্য যথেষ্ট। mmap দিয়ে দুটি পাতা নেওয়া হবে — একটি MAP_SHARED, একটি MAP_PRIVATE — আর একটি সাধারণ ভ্যারিয়েবল। Child তিনটিতেই লিখবে, parent অপেক্ষার পর পড়বে:

#include <stdio.h>
#include <sys/mman.h>
#include <sys/wait.h>
#include <unistd.h>

int main(void) {
    /* one page shared by parent and child, one page copied (private) */
    int *shared = mmap(NULL, sizeof(int), PROT_READ | PROT_WRITE,
                       MAP_SHARED | MAP_ANONYMOUS, -1, 0);
    int *priv   = mmap(NULL, sizeof(int), PROT_READ | PROT_WRITE,
                       MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
    if (shared == MAP_FAILED || priv == MAP_FAILED) { perror("mmap"); return 1; }
    int plain = 0;                      /* ordinary variable */
    *shared = 0;
    *priv = 0;
    fflush(stdout);

    pid_t pid = fork();
    if (pid == 0) {                     /* child writes to all three */
        for (int i = 0; i < 1000; i++) (*shared)++;
        *priv = 1000;
        plain = 1000;
        printf("child : shared=%d private=%d plain=%d\n", *shared, *priv, plain);
        fflush(stdout);
        _exit(0);
    }
    waitpid(pid, NULL, 0);              /* wait = the simplest synchronisation */
    printf("parent: shared=%d private=%d plain=%d\n", *shared, *priv, plain);
    munmap(shared, sizeof(int));
    munmap(priv, sizeof(int));
    return 0;
}

child : shared=1000 private=1000 plain=1000
parent: shared=1000 private=0 plain=0

নিচের ডায়াগ্রামে ঠিক এই প্রোগ্রামের page table-এর ভেতরটা দেখুন। F2, F3, F7… হলো physical frame-এর কাল্পনিক নম্বর:

1mmap SHARED, mmap PRIVATE, plain=02fork()3child: (*shared)++ x10004child: *priv = 10005child: plain = 1000; _exit6parent: waitpid; read all three7process B: shm_open + mmap

নাম দিয়ে shared memory — shm_open

অসম্পর্কিত দুই প্রোগ্রামের জন্য POSIX shared memory ব্যবহার করা হয়। নিচে দুটি আলাদা প্রোগ্রামের মূল অংশ (চালানোর জন্য নয়, নমুনা) — একটি “নোটিশ বোর্ড”-এ লেখে, আরেকটি পড়ে। Linux-এ নামটি /dev/shm/abcl_board হিসেবে দেখা যায়।

/* ---- writer ---- */
int fd = shm_open("/abcl_board", O_CREAT | O_RDWR, 0600);  /* owner only */
ftruncate(fd, 4096);                                        /* set its size */
char *board = mmap(NULL, 4096, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0);
close(fd);                              /* the mapping stays valid */
strcpy(board, "notice: meeting in room 302 at 3 pm");

/* ---- reader (another program, started later) ---- */
int fd = shm_open("/abcl_board", O_RDONLY, 0);
char *board = mmap(NULL, 4096, PROT_READ, MAP_SHARED, fd, 0);
close(fd);
printf("%s\n", board);
munmap(board, 4096);
shm_unlink("/abcl_board");              /* remove the name when done */

Memory-mapped file — ফাইলকে মেমরির মতো ব্যবহার

একটি সাধারণ ফাইলকে mmap(MAP_SHARED) করলে ফাইলের বিষয়বস্তু মেমরিতে একটি অ্যারের মতো দেখা যায়। পড়লে kernel দরকারমতো ডিস্ক থেকে page আনে (পর্ব ৩৫), লিখলে পরে ফাইলে ফেরত যায়। একই ফাইল দুই প্রসেস map করলে দুজন একই page cache-এর পাতা দেখে — অর্থাৎ এটিও shared memory, সাথে স্থায়ী সংরক্ষণ। LMDB-র মতো ডেটাবেস আর shared library লোড করা এভাবেই চলে। আসলে POSIX shm_open-ও Linux-এ /dev/shm-এর একটি মেমরি-ভিত্তিক ফাইল সিস্টেমে (tmpfs) একটি ফাইলকে map করা মাত্র।

৭ · Message queue, socket আর signal

POSIX message queue — বার্তার সীমানা আর priority

Pipe বাইটের স্রোত দেয়; কিন্তু অনেক সময় দরকার আলাদা আলাদা বার্তা — একটি অর্ডার মানে একটি পুরো বার্তা, অর্ধেক নয়। POSIX message queue ঠিক এটি দেয়: নাম দিয়ে খোলা একটি mailbox (indirect communication), যেখানে প্রতিটি mq_send একটি সম্পূর্ণ বার্তা, আর প্রতিটি বার্তার একটি priority. mq_receive সবসময় সবচেয়ে বেশি priority-র সবচেয়ে পুরোনো বার্তাটি দেয়। Queue-র আকার সীমিত (mq_maxmsg) — bounded capacity, আর ভর্তি হলে mq_send অপেক্ষা করে (non-blocking হলে EAGAIN).

#include <fcntl.h>
#include <mqueue.h>
#include <stdio.h>

int main(void) {
    struct mq_attr attr = { .mq_maxmsg = 4, .mq_msgsize = 32 };
    mqd_t q = mq_open("/abcl_orders", O_CREAT | O_RDWR, 0600, &attr);
    if (q == (mqd_t)-1) { perror("mq_open"); return 1; }

    mq_send(q, "tea for table 3", 16, 1);       /* priority 1 */
    mq_send(q, "URGENT: gas leak", 17, 9);      /* priority 9 */
    mq_send(q, "rice for table 5", 17, 1);

    char buf[32];
    unsigned prio;
    for (int i = 0; i < 3; i++) {
        ssize_t n = mq_receive(q, buf, sizeof buf, &prio);
        printf("got %zd bytes, prio %u: %s\n", n, prio, buf);
    }
    mq_close(q);
    mq_unlink("/abcl_orders");                  /* remove the name */
    return 0;
}

got 17 bytes, prio 9: URGENT: gas leak
got 16 bytes, prio 1: tea for table 3
got 17 bytes, prio 1: rice for table 5

System V IPC — পুরোনো কিন্তু এখনো আছে

১৯৮০-র দশকের AT&T System V Unix থেকে আসা তিনটি ব্যবস্থা — message queue (msgget, msgsnd, msgrcv), semaphore set (semget, semop) আর shared memory (shmget, shmat) — একসাথে System V IPC নামে পরিচিত। এগুলো ফাইলের নামের বদলে একটি সংখ্যা-চাবি (key, প্রায়ই ftok দিয়ে বানানো) ব্যবহার করে, আর তৈরিকারী প্রসেস শেষ হয়ে গেলেও থেকে যায় — যতক্ষণ না কেউ মুছে দেয় বা কম্পিউটার reboot হয়। ipcs কমান্ড এদের তালিকা দেখায়, ipcrm মোছে। নতুন কোডে সাধারণত POSIX সংস্করণ (mq_open, shm_open, sem_open) পছন্দ করা হয়, তবে পুরোনো সফটওয়্যারে System V এখনো দেখা যায়।

Socket — একই মেশিনে, আর নেটওয়ার্কে

Socket হলো যোগাযোগের একটি প্রান্ত (endpoint). দুটি socket যুক্ত হলে দুই দিকেই ডেটা চলে। ১৯৮৩ সালের 4.2BSD Unix-এ আসা এই API আজ Linux, macOS আর Windows (Winsock) — সবখানে প্রায় একই রকম। দুই ধরনের socket এই পর্বে গুরুত্বপূর্ণ:

• Unix domain socket (AF_UNIX): শুধু একই মেশিনের ভেতরে। ঠিকানা হলো ফাইল সিস্টেমের একটি পথ, যেমন /run/docker.sock বা PostgreSQL-এর /var/run/postgresql/.s.PGSQL.5432; তাই ফাইলের অনুমতি দিয়েই নিয়ন্ত্রণ করা যায় কে যুক্ত হতে পারবে। নেটওয়ার্কের protocol stack পার হয় না বলে সাধারণত localhost TCP-র চেয়ে দ্রুত; অপর প্রান্তের PID/UID জানা আর খোলা fd পাঠানোও যায় (প্র ০৪ দেখুন)।
• TCP socket (AF_INET/AF_INET6): ঠিকানা হলো IP আর port, তাই অন্য মেশিনেও যাওয়া যায় — ইন্টারনেটের প্রায় সব সেবা এর ওপর চলে। সার্ভার socket → bind → listen → accept, ক্লায়েন্ট socket → connect, তারপর দুজনেই read/write (বা send/recv). বিস্তারিত C কোড আছে C প্রোগ্রামিং কোর্সের TCP socket পর্বে।

Parent আর child-এর জন্য সবচেয়ে সহজ পথ socketpair: এক কলেই দুটি যুক্ত Unix domain socket, pipe-এর মতো, কিন্তু দুই দিকে চলে। নিচে child একটি ছোট “echo” সার্ভার — যা পায় তা বড় হাতের অক্ষরে ফেরত দেয়:

#include <ctype.h>
#include <stdio.h>
#include <string.h>
#include <sys/socket.h>
#include <sys/wait.h>
#include <unistd.h>

int main(void) {
    int sv[2];                          /* two connected Unix-domain sockets */
    if (socketpair(AF_UNIX, SOCK_STREAM, 0, sv) == -1) { perror("socketpair"); return 1; }
    fflush(stdout);
    pid_t pid = fork();
    if (pid == 0) {                     /* child = echo server on sv[1] */
        close(sv[0]);
        char buf[64]; ssize_t n;
        while ((n = read(sv[1], buf, sizeof buf)) > 0) {
            for (ssize_t i = 0; i < n; i++) buf[i] = (char)toupper((unsigned char)buf[i]);
            if (write(sv[1], buf, (size_t)n) == -1) break;   /* reply, same socket */
        }
        _exit(0);                       /* read() == 0: client closed */
    }
    close(sv[1]);                       /* parent = client on sv[0] */
    const char *msgs[] = {"hello", "dhaka metro"};
    for (int i = 0; i < 2; i++) {
        char reply[64];
        if (write(sv[0], msgs[i], strlen(msgs[i])) == -1) { perror("write"); return 1; }
        ssize_t n = read(sv[0], reply, sizeof reply - 1);
        reply[n > 0 ? n : 0] = '\0';
        printf("client sent \"%s\" -> server replied \"%s\"\n", msgs[i], reply);
    }
    close(sv[0]);                       /* server's read() now returns 0 */
    waitpid(pid, NULL, 0);
    printf("one socket, both directions: done\n");
    return 0;
}

client sent "hello" -> server replied "HELLO"
client sent "dhaka metro" -> server replied "DHAKA METRO"
one socket, both directions: done

Signal — সবচেয়ে ছোট বার্তা

Signal-ও একরকম IPC, তবে সবচেয়ে সংকীর্ণ: বার্তা মানে শুধু একটি সংখ্যা — SIGTERM, SIGUSR1, SIGCHLD ইত্যাদি। কোনো ডেটা যায় না, আর একই signal অপেক্ষমাণ থাকতে আবার এলে সাধারণ signal-এ দুটি একটিতে মিশে যেতে পারে। তবু “থেমে যান”, “config আবার পড়ুন”, “child শেষ হয়েছে” — এ ধরনের খবর জানাতে এটি যথেষ্ট — যেমন kill -HUP <pid> দিয়ে অনেক সার্ভারকে config আবার পড়তে বলা হয়। Signal কীভাবে পাঠানো, ধরা আর সামলানো হয়, তা পরের পর্বে (পর্ব ১৩)।

৮ · Windows, macOS আর উঁচু স্তর — তারপর সব এক টেবিলে

Windows-এ একই কাজ

ALPC নিয়ে একটু সাবধানে বলা দরকার। এটি Windows NT kernel-এর একটি দ্রুত message passing ব্যবস্থা, যা Windows Vista-র সময় পুরোনো LPC-র জায়গা নেয়। একই মেশিনের ভেতরের RPC আর অনেক system service এর ওপর চলে। তবে Microsoft এটি অ্যাপের সরাসরি ব্যবহারের জন্য প্রকাশ্যে ডকুমেন্ট করেনি; অ্যাপ সাধারণত RPC বা COM-এর মাধ্যমে পরোক্ষে এটি ব্যবহার করে।

macOS আর Android

macOS-এর XNU kernel Mach microkernel-এর ঐতিহ্য বহন করে, তাই এর মূল IPC হলো Mach port-এ Mach message পাঠানো — একটি indirect, port-ভিত্তিক message passing. এর ওপর Apple-এর XPC চলে; পাশাপাশি BSD-অংশের pipe আর socket-ও আছে। Android Linux kernel-এর ওপর চলে, কিন্তু অ্যাপ আর system service-এর মধ্যে প্রায় সব কথা হয় Binder দিয়ে — একটি kernel driver, যা RPC-ধাঁচের কল, পাঠানো প্রসেসের পরিচয় আর অনুমতি-যাচাই একসাথে দেয়। Binder এখন mainline Linux kernel-এর অংশ।

উঁচু স্তর — RPC, gRPC আর D-Bus

সরাসরি pipe বা socket-এ বাইট পাঠানো নিচু স্তরের কাজ: বার্তার ফর্ম্যাট, সংস্করণ, ত্রুটি — সব নিজেকে ঠিক করতে হয়। তাই এর ওপর তৈরি হয়েছে উঁচু স্তর:

• RPC (remote procedure call): অন্য প্রসেস বা অন্য মেশিনের একটি ফাংশন এমনভাবে ডাকা, যেন নিজের ফাংশন। একটি “stub” argument-গুলোকে বাইটে সাজায় (marshalling), message passing দিয়ে পাঠায়, উত্তর এলে আবার খুলে দেয়। Birrell আর Nelson-এর ১৯৮৪ সালের গবেষণাপত্র এর ক্লাসিক বর্ণনা; Sun-এর ONC RPC-র ওপর NFS চলে (পর্ব ৫৩)।
• gRPC: Google-এর ২০১৫ সালে উন্মুক্ত করা RPC framework — HTTP/2-এর ওপর Protocol Buffers ফর্ম্যাটে বার্তা। Microservice-এর মধ্যে খুব জনপ্রিয়; একই মেশিনে Unix domain socket-এর ওপরেও চলতে পারে।
• D-Bus: Linux ডেস্কটপ আর systemd-এর message bus. একটি কেন্দ্রীয় bus daemon (Unix domain socket-এর ওপর) প্রোগ্রামগুলোর মধ্যে বার্তা আর ঘটনা পৌঁছে দেয় — যেমন “USB লাগানো হয়েছে”।

সব পদ্ধতি এক টেবিলে

৯ · AI-এর যুগে IPC

“দুই প্রসেসের মধ্যে shared memory দিয়ে ডেটা পাঠানোর C কোড দাও” — AI দ্রুত দেবে, আর আপনার ল্যাপটপে প্রথম কয়েকবার সেটি চলবেও। IPC-র বাগ সাধারণত প্রথম রানে ধরা পড়ে না: race condition আসে লোড বাড়লে, SIGPIPE আসে ক্লায়েন্ট হঠাৎ চলে গেলে। AI-এর সাধারণ ভুলগুলো:

AI-এর লেখা IPC কোড চালানোর আগে — চেকলিস্ট

• প্রতিটি fork-এর পর parent আর child-এ অব্যবহৃত pipe/socket-মুখ বন্ধ হচ্ছে; শেষে সব fd বন্ধ
• Shared memory-তে প্রতিটি যৌথ লেখা lock, semaphore বা atomic দিয়ে সুরক্ষিত; কোনো সাধারণ pointer shared অঞ্চলে রাখা হয়নি
• বার্তার সীমানা নিশ্চিত (দৈর্ঘ্য-চিহ্ন, নির্দিষ্ট আকার বা message queue); আংশিক read/write-এর লুপ আছে
• অনেকবার, বড় ডেটায় আর একাধিক core-এ চালিয়ে ফল মিলিয়েছি; পাঠক বা লেখক হঠাৎ বন্ধ করে দেখেছি প্রোগ্রাম আটকায় বা মরে কি না
• নামওয়ালা object (/dev/shm, mqueue, socket ফাইল, FIFO) শেষে মুছে ফেলা হয়; অনুমতি ন্যূনতম, কোথাও 0666/777 বা অকারণ sudo নেই
• ব্যবহৃত API আমার OS-এ আছে কি না man page (section 2, 3, 7) বা Microsoft-এর ডকুমেন্টেশনে মিলিয়েছি