客户端收到的回复对不对
场景：起服务后，用客户端发说明点名的一条请求。 任务：看回复是否和说明写的预期一致（True/False），到 ~/对照表.txt 里查它对应的标记。 （判分只看你在受控容器里本机起的服务、本机连出来的证据，全在 127.0.0.1，不碰公
交付:一个能用的 KV 服务
场景：要交付一个本机能连、按协议应答的 KV 服务，端口、要支持的命令见说明。 任务：写/补 ~/svc/server.py 与 启动.sh，让客户端发说明里的几条请求都拿到正确回复。改好运行 ~/check。 （判分只看你在受控容器里本机
诊断连不上先看什么
客户端连不上本机服务，最该先确认的是【0】。 （本机受控：一批各有毛病的服务 + 客户端，全在 127.0.0.1。）
从现象认连接/并发问题
本机服务出问题，下面哪些是「连接/并发」层面的原因？ A. 端口没监听、连接被拒 B. 服务起错了端口 C. 单线程被一个慢客户端卡住、别人都等 D. 收了不回、客户端一直阻塞在 recv
服务到底起没起
场景：客户端报连不上，~/svc/ 下有服务和日志。 任务：判断服务此刻是「在监听 / 没起来」哪种，到 ~/对照表.txt 里查它对应的标记。 （判分只看你在受控容器里本机起的服务、本机连出来的证据，全在 127.0.0.1，不碰公网。）
客户端连的端口对不对
场景：客户端里写的端口，可能和服务监听的端口不一致。 任务：判断客户端连的端口和服务端监听的是否一致（True/False），到 ~/对照表.txt 里查它对应的标记。 （判分只看你在受控容器里本机起的服务、本机连出来的证据，全在 127.
是哪个客户端卡住了
场景：单线程服务被某个客户端拖住，日志记了各连接状态。 任务：从日志看是哪个连接卡住了（编号），到 ~/对照表.txt 里查它对应的标记。 （判分只看你在受控容器里本机起的服务、本机连出来的证据，全在 127.0.0.1，不碰公网。） （本
改对客户端的端口
场景：客户端连的端口写错了，连不上服务。 任务：把 ~/svc/client.py 连的端口改成和服务监听一致，让它连得上。改好运行 ~/check。 （判分只看你在受控容器里本机起的服务、本机连出来的证据，全在 127.0.0.1，不碰公
让服务收了就回
场景：服务收到请求却不回（少了 sendall），客户端一直阻塞在 recv。 任务：改 ~/svc/server.py，让它 handle 后把回复发回去，客户端不再卡住。改好运行 ~/check。 （判分只看你在受控容器里本机起的服务、
别让一个卡住拖垮全部
场景：服务对一个连接做了阻塞操作、把整个循环卡住。 任务：改 ~/svc/server.py，改成轮询/每连接独立处理（说明给了改法），让别的客户端不再被拖住。改好运行 ~/check。 （判分只看你在受控容器里本机起的服务、本机连出来的证