Measure sending between two apps of a host: local outlet or link (112)

Two apps of one host, src sending one message for each of 1,000 items
in a burst event, 2,000 bursts a run, five rounds with the ways in
turns: the local outlet stores 1,141,642 sends a second at 1.17 us of
the host's CPU each, a loopback pure:// link to the host's own port
578,879 at 2.93 us (1.97 times the sends, 0.40 times the CPU). 017's
second stage asked for at least the link's rate at half its CPU or
less: it goes in. Every run checks dst's sum: each send came once.

1 files changed, 56 insertions, 0 deletions

diff --git a/docs/research/112-sending-between-apps.md b/docs/research/112-sending-between-apps.md
new file mode 100644
index 0000000..223418b
--- /dev/null
+++ b/docs/research/112-sending-between-apps.md
@@ -0,0 +1,56 @@
+# 112 — 한 호스트의 앱 사이의 건넴: 안쪽 출구와 링크
+
+2026-10-01. [017](../design/017-apps-on-one-host.md)의 2단계를 잰다. 기준은 구현하기 전에 017에 적어 커밋했다(`f394f1e`).
+
+- 바꿀 결정: 같은 호스트의 앱 사이를 링크(소켓, 봉인, 패킷)가 아니라 안쪽 출구로 건넬지.
+- 통과 조건: 같은 두 앱 사이에서, 받는 앱에 저장된 보냄의 초당 수가 루프백 `pure://` 링크보다 낮지 않고, 저장된 보냄 하나에
+  드는 호스트의 CPU가 링크의 절반 이하다.
+
+## 쉬운 말로
+
+- **통과했다.** 안쪽 출구는 링크의 두 배(초당 114만 건 대 58만 건)를 나르고, 보냄 하나에 호스트의 CPU를 40%만 쓴다(1.17 µs 대
+  2.93 µs).
+- 안쪽 출구에는 봉인, 패킷, 소켓, 받는 스레드가 없다. 보내는 앱의 차례가 저장한 보냄을 묶음으로 받는 앱의 대기열에 넣고, 받는
+  앱이 링크의 기록처럼 들은 번호 다음부터 적용한다. 순서와 한 번만은 링크와 같은 "들은 번호"가 지킨다. 그래서 받는 쪽의 코드는
+  링크와 같고, 보내는 쪽은 출구 하나(약 200줄)다.
+- 여기서 잰 CPU에는 보내는 사건(목록을 걸으며 1,000건을 보내고 저장)과 받는 앱의 적용·저장도 들어 있다. 두 길에 같다. 출구만의
+  차이는 이보다 크다.
+
+## 결과
+
+원시 결과와 명령은 [027-apps-sending](../../research/experiments/027-apps-sending/)에 있다(`runs.sh`, `sends.py`, 두 앱
+`src.aup`와 `dst.aup`).
+
+**방법.** 한 호스트(`--apps`, 연결 스레드 하나, 실행 스레드 둘, RAM, 코어 0–2)에 앱 둘. `src`는 항목 1,000개를 들고, `burst`
+사건 하나가 그것을 걸으며 하나에 보냄 하나(`send out { k }`)를 낸다. `dst`는 받은 것을 세고 더한다. 한 판은 `burst` 2,000번(보냄
+200만 건)을 차례로 보내고, `dst`가 모두 저장할 때까지의 시간과 호스트의 CPU(utime + stime)를 잰다. `dst`의 합이 모든 보냄이 한
+번씩 왔는지 본다. 링크는 호스트가 자기 `--link-port`로, 자기 키로 봉인해 보낸다(`send=out=pure://127.0.0.1:포트/dst/take`).
+다섯 라운드, 두 길을 번갈아. 부하 평균은 1.3–1.6이었다.
+
+| 라운드 | 안쪽 출구(건/초, µs/건) | 링크(건/초, µs/건, 패킷) |
+|---|---:|---:|
+| 1 | 1,124,661, 1.17 | 575,155, 2.92, 63,888 |
+| 2 | 1,149,587, 1.17 | 591,140, 2.87, 63,094 |
+| 3 | 1,138,945, 1.18 | 578,879, 2.94, 66,506 |
+| 4 | 1,141,642, 1.17 | 550,106, 3.12, 72,477 |
+| 5 | 1,161,814, 1.16 | 601,578, 2.93, 69,839 |
+
+중앙값은 안쪽 출구 1,141,642건/초에 1.17 µs, 링크 578,879건/초에 2.93 µs다(1.97배, 0.40배). 안쪽 출구는 판마다 묶음 2,000개를
+넘겼다. 사건 하나의 보냄 1,000건이 한 묶음이었다.
+
+**검사**(`tests/check.py`의 `server_apps_links`). 한 호스트의 앱이 400건마다 넷에 보낸다. 다른 호스트의 앱(링크, 봉인, 그
+호스트의 링크 포트가 `far/take`로 받는다), 같은 호스트의 앱 셋(같은 모양, 이름으로 받는 모양, 메모리 예산이 차는 앱)이다.
+150번째 요청 앞에서 보내는 호스트를 `kill -9`하고 다시 띄운다. 넷 모두 400건을 한 번씩 순서대로 받는다. 가득 찬 앱은 147건을
+쥐고, 나머지는 보내는 앱의 outbox가 붙든다. 그 앱이 쥔 것을 놓을 때마다 이어서 받아 400건을 다 받는다. 세 번 돌려 세 번
+같았다.
+
+## 판정
+
+- **017의 2단계는 들어간다.** 같은 호스트의 앱 사이는 안쪽 출구로 건넨다. 다른 호스트로는 지금처럼 링크로 보낸다(`pure://…/앱/입력`,
+  호스트의 링크 포트 하나가 모든 앱의 입력을 받는다).
+
+## 다음
+
+- **2b: 보냄마다의 스레드.** 링크와 전달선은 아직 하나에 스레드 하나다. 안쪽 출구에는 스레드가 없다. 앱마다 스레드를 두지 않는다는
+  원칙에 어긋나는 마지막 자리다.
+- 3단계(앱의 수명): 달리는 호스트에 앱을 더하고, 멈추고, 바꾼다.