Say how sends will share one loop, and what it must show (017, 2b)

Each link and each HTTP wire sends on a thread of its own: a host with
twenty outputs runs twenty-one threads more than one without. 2b moves
them into one sending loop: an epoll over the links' UDP sockets and
the wires' TCP sockets with one wake, waiting until the soonest link
timer or wire pause. Links (2b-1) do in the loop what their threads
did each round; wires (2b-2) become a non-blocking HTTP/1.1 client
state machine, with non-blocking steps added to the crypto table for
TLS. A name looked up again still waits where it is, and says so.

Before building: every link, wire, answer and seal check green; a host
of ten links and ten wires two threads above one without; and link and
wire throughput, alternated before and after, no more than 5% lower at
the median (four links together: 10%).

1 files changed, 18 insertions, 3 deletions

diff --git a/docs/design/017-apps-on-one-host.md b/docs/design/017-apps-on-one-host.md
index a192908..aaaef51 100644
--- a/docs/design/017-apps-on-one-host.md
+++ b/docs/design/017-apps-on-one-host.md
@@ -1,7 +1,7 @@
 # 017 — 한 호스트의 여러 앱: 차례, 예산, 실패 경계
 
 작성일: 2026-10-01. 상태: 1·2단계 구현, 검사로 고정하고 쟀다([111](../research/111-apps-on-one-host.md),
-[112](../research/112-sending-between-apps.md)). 2b와 3단계는 설계.
+[112](../research/112-sending-between-apps.md)). 2b는 착수 기준을 적었다. 3단계는 설계.
 [외부 리뷰 004](../outside-feedback/feedback-004.md)의 "구현 방향에 대한 평가" 셋째에서 시작한다. 작은 OS의 운영 모델(
 [007](007-execution-domains.md))을 Pure가 실제로 갖게 하는 단계다.
 
@@ -172,8 +172,23 @@ counter  apps/count.pmod  stores/counter
   않는다. 받는 앱이 메모리 예산으로 받지 못하면(013) 묶음은 돌아오고, 100 ms 뒤에 다시 간다.
 - 재시작: 보내는 앱의 outbox에 남은 것이 다시 가고, 받는 앱의 들은 번호가 이미 받은 것을 걸러낸다(링크와 같다).
 
-**2b(뒤로 미룬다).** 보냄마다의 스레드(전달선 하나, 링크 하나에 하나씩)를 하나의 보내는 루프로 모은다. 지금 출력을 가진 앱은
-보냄마다 스레드 하나를 더한다. 앱마다 스레드를 두지 않는다는 원칙에 어긋나는 마지막 자리다.
+**2b: 보내는 루프 하나.** 보냄마다의 스레드(전달선 하나, 링크 하나에 하나씩)를 호스트의 보내는 스레드 하나로 모은다. 출력을 가진
+앱은 보냄마다 스레드 하나를 더해 왔다. 앱마다 스레드를 두지 않는다는 원칙에 어긋나는 마지막 자리다.
+
+- 루프 하나(`pure-send`)가 epoll 하나에 링크의 UDP 소켓과 전달선의 TCP 소켓, 깨움 하나를 둔다. 기다리는 시간은 링크들의 다음 때와
+  전달선들의 쉼 가운데 가장 이른 것이다. 출구에 보냄이 쌓이면 루프를 깨운다(자고 있을 때 한 번).
+- 링크(2b-1): 지금 스레드가 한 바퀴에 하던 일을 루프의 한 바퀴에서 링크마다 한다. 답 받기, 시각, 보내기다. 받는 쪽을 다시 찾는
+  이름 찾기(DNS)는 그 자리에서 기다린다. 프로브 셋이 답을 못 받았을 때뿐이라 드물지만, 그동안 다른 보냄도 멈춘다. 이것을 밝힌다.
+- 전달선(2b-2): 비블로킹 HTTP/1.1 클라이언트의 상태기다(연결, TLS, 요청 쓰기, 답 읽기, 쉼). TLS는 crypto의 함수 표에 비블로킹
+  단계를 더한다. 이름 찾기는 연결할 때 기다린다(링크와 같다).
+
+**2b의 착수 기준.**
+
+- 바꿀 결정: 보냄을 스레드 하나의 루프로 돌릴지다. 아래를 채우지 못하면 보냄마다의 스레드를 둔다.
+- 최소 확인: 링크·전달·답·봉인·`server_apps_links`의 검사가 모두 초록. 출력이 링크 열과 전달선 열인 호스트의 스레드가 출력이 없는
+  호스트보다 둘(보내는 루프, 링크를 받는 스레드)만 많다(지금은 스물하나).
+- 통과 조건(RAM의 Pi 5, 전과 후 번갈아): 112의 링크 측정(두 앱, 루프백 링크 하나)과 같은 방식의 전달선 측정(HTTP로 받는 앱)에서
+  처리량의 중앙값이 5% 넘게 낮지 않다. 링크 넷이 함께 보낼 때 처리량의 합이 10% 넘게 낮지 않다.
 
 ## 2단계의 착수 기준