От process A к process B: весь путь сообщения

Overview

Диаграмма задаёт главный вопрос курса: как процесс на компьютере A передаёт слово «Привет» процессу на компьютере B. В строке шесть Unicode-символов, а в UTF-8 payload занимает 12 bytes. Между приложениями нет прямого провода: каждое пересекает границу socket API, buffers ядра, transport/network stack, драйвер и NIC. На принимающей стороне отдельно показан причинный шаг: адрес приводит данные к компьютеру B, а destination port 27015 помогает ядру выбрать нужный socket endpoint.

Socket здесь показан не как «кусок сети» и не как простой buffer. Это управляемый ядром communication endpoint, к которому относится protocol state и send/receive buffers. Успех send() подтверждает локальное принятие bytes стеком в рамках контракта вызова, но сам по себе не доказывает, что recv() на другом компьютере уже вернул данные.

Components

• process A / process B — user-mode программы, которые придают bytes смысл строки.
• socket handle / endpoint — локальный дескриптор или handle для kernel-managed endpoint.
• send и receive buffers — очереди bytes в ядре между вызовами программы и работой сетевого стека.
• TCP/IP stack — transport и network processing, включая addressing, sequencing и demultiplexing.
• destination port 27015 — transport metadata, по которой ядро выбирает локальную коммуникацию; это не PID процесса.
• NIC / PHY — граница MAC/driver и кодирование данных в physical symbols выбранной среды.
• switch — forwarding Ethernet frames внутри link-layer domain.
• router — forwarding IP packets между сетями с новым link-layer wrapper на каждом hop.

Scenarios

1. «Привет» end to end — один и тот же 12-byte application payload проходит границы от send() до выбора endpoint по destination port и recv().
2. Компьютер найден, программа — нет — destination IP доводит packet до B, но неверный destination port не выбирает нужный endpoint.
3. Protocol mismatch — bytes успешно попадают process B, но без одинаковых правил application layer их смысл не восстанавливается.

Failure modes

• Ошибка addressing или routing может остановить путь ещё до компьютера B.
• Правильный destination IP с неправильным destination port не доставляет bytes нужной программе.
• Правильная доставка bytes не гарантирует правильный смысл: обе программы должны реализовывать один application protocol.
• Успех send() остаётся локальным наблюдением и сам по себе не доказывает, что recv() на другом компьютере уже вернул данные.

References

• RFC 1122: Requirements for Internet Hosts — Communication Layers
• RFC 9293: Transmission Control Protocol
• Microsoft: send function (winsock2.h)
• Microsoft: recv function (winsock2.h)