没有窗口的 RPC 服务端

# 没有窗口的 RPC 服务端

Fun 的 Linux 移植里，`lib-winsock-lnx` 把网络栈换成了 BSD socket 加 `poll(2)`，`lib-ado-lnx` 把数据层换成了 SQLite。这一篇补上它们上面的那一层：两个 RPC 服务端。Windows 版的 `lib-jsonrpc`/`lib-orm-rpc` 是长在窗口上的 —— `Form()` 基类、`WSAAsyncSelect`、user32 消息泵；Linux 没有 hwnd，于是事件模型整个换掉，而协议一层一个字没动。

## 一、Windows 版：socket 事件是「窗口消息」

`lib-jsonrpc.fun` 只有 97 行，形状是这样的：

```fun
class JsonRpc = Form()
  var ip    = JsonRpcIp;
  var port  = JsonRpcPort;
  var http  = nil;

fun onMessage(hwnd, message, wParam, lParam)
    result = false;
    if message = WMX_Winsock and wParam <> nil then
      result = _JR_.http.OnMessage(hwnd, message, wParam, lParam);
    end if;
  end fun;

fun start()
    stop();
    http = Server.HTP(ip, port, onGet);
    http.Start(h, WMX_Winsock);
  end fun;
end class;
```

`WMX_Winsock = 0x777`。socket 上的可读／可写事件由 `WSAAsyncSelect` 投递成窗口消息，`onMessage` 再转交给 HTTP 服务器对象；`http.Start(h, WMX_Winsock)` 把监听套接字与窗口句柄、自定义消息绑在一起。换句话说，这个服务端必须跑在一个有消息泵的 GUI 线程里。

## 二、Linux 版：把消息泵换成 poll(2)

`lib-jsonrpc-lnx.fun` 133 行，第一行定义就是区别：`class JsonRpc()`，没有 `Form` 基类。启动只要一个 `start()`：

```fun
var rpc = JsonRpc();
rpc.port = 8278;
rpc.start();          // bind + listen + 在当前线程跑 poll 循环，直到 stop()

rpc.listen();         // 只 bind + listen，不阻塞
while ... loop rpc.runOnce(200); end loop
```

协议层原样照搬：路由 `/JsonRpc/2.0`、`onCall` 与 `'Rpc_<Method>'` 成员派发、请求里 `args`/`params` 两种参数名的兼容、JSON-RPC 2.0 的五个错误码 —— `-32700`（解析错）、`-32600`（非法请求）、`-32601`（方法不存在）、`-32602`（参数非法）、`-32603`（内部错）—— 与 Windows 版逐行相同。`onGet` 的主体也几乎一样，只去掉了两处 `?.` 调试打印（Windows 版的 `?. req;` 与 `else ?. 'DDOS';`）。

换掉的只有事件模型。服务端挂到 `lib-winsock-lnx.fun`（629 行）的 `Server.HTP` 上：调用线程跑 `poll(2)`，回调内联执行，没有 worker 线程。那个文件的开头把原因写得很直白 —— Windows 类是 `WSAAsyncSelect(socket, hwnd, msg, event)` 加 user32 消息泵，Linux 没有 hwnd，替代品就是 poll 循环。HTTP/WebSocket 的协议与连接簿记在 `lib-winsock-base.fun`（与 Windows 共用），两端差异只剩 `SendOnce`/`Read`/`CloseSock`/`Delay` 几个钩子和 poll 泵本身。

顺带一提，这套 poll 服务器的监听队列 backlog 从 5 提到了 128：单线程 accept 循环，配客户端 1s/3s 的 SYN 重试，5 太小会溢出。

## 三、OrmRpc = JsonRpc() 加 SQLite

`lib-orm-rpc-lnx.fun` 103 行，继承就一句 `class OrmRpc = JsonRpc()`，方法名与协议跟 Windows 版一字不差：

```fun
fun Rpc_OrmInit(args, ret, sock)
fun Rpc_OrmGet(args, ret, sock)
fun Rpc_OrmSave(args, ret, sock)
fun Rpc_OrmUpdate(args, ret, sock)
fun Rpc_OrmDelete(args, ret, sock)
```

客户端看到的还是同一套 JSON-RPC：

```
{"jsonrpc":"2.0","id":1,"method":"OrmInit","params":{"connectionString":"/tmp/app.sqlite"}}
{"jsonrpc":"2.0","id":2,"method":"OrmGet","params":{"User":{"name":"alice"}}}
```

两处与 Windows 版不同。一是两个 `use` 换了：`lib-ado-lnx.fun`（SQLite）加 `lib-ado-schema-lnx.fun`，Windows 版走的是 COM/ODBC 那条链。二是 schema 不用客户端送了 —— Windows 版要求把 schema 一并传进来，Linux 版在 `args.schema` 为空时直接读数据库：

```fun
if args.schema <> nil then
  db.schema = args.schema;
else
  db.schema = Schema(cnString, args).ToSchema();
end if;
```

连接串就是 SQLite 文件路径、`:memory:` 或 `Data Source=...`。数据库操作统一走 `OrmCall`：从 `orm` 模块里取同名函数，`ret.data = f(db, args)`，异常包成 `-32603`。

还有一个小决定：`db.dontPrintSQL = true`。一个没有界面的服务端不该把每条 SQL 喷到 stdout；要看就把它设回 false。

## 四、两个 Fun 特有的坑

**false 就是 nil。** Fun 里没有独立的布尔类型，`false` 与 `nil` 相等，所以「用一个可选参数决定是否阻塞」这条路口走不通 —— 分不清「没传参」和「传了 false」。阻塞的 `start()` 与非阻塞的 `listen()` 只能做成两个方法。

**start() 里不要重复 listen()。** 第一版 `start()` 无条件调用 `listen()`，但 `listen()` 会重建 http 对象，于是先 `listen()` 再挂的定时器被丢掉，`Run` 里的 scheduler 永远空转 —— 实测 poll 超时恒等于传入值，定时器再也不触发。改成 `if http = nil then listen()`：已开好的监听器复用，定时器就能在 `listen()` 与 `start()` 之间挂上。测试里正好有一段是「阻塞的 `start()` 由一个定时器调用 `stop()` 才返回」，专门盯这条路径。

## 五、验证

两个测试都在 `fun/test/`，单线程、端口用 0（让内核分配临时端口）、输出全是布尔：

- `lib-jsonrpc-lnx-test.fun` 7 段：`listen()` 与临时端口、`Test` 派发返回的 `result`/`data`、`-32601`、`-32602`、`-32600`、越权路由直接关连接、阻塞 `start()` 由定时器 `stop()` 返回。
- `lib-orm-rpc-lnx-test.fun` 5 段：`OrmInit` 自动建 schema、`OrmGet`（带过滤与不带过滤列全表）、`OrmSave`、`OrmDelete`、未知方法 `-32601`。

RPC 这一步把 `lib-jsonrpc`、`lib-orm-rpc` 两个模块在 Linux 上从 FAIL 变成 LOAD：loadcheck 48/59 → 50/59；整个 Linux 回归当前 85/85。

## 结语

这一篇里没有新协议。Windows 版与 Linux 版共享 JSON-RPC 2.0 的分帧、`onCall` 的派发约定、五个错误码，甚至 `onGet` 的调用链；两个新文件加起来 236 行，绝大部分是在把「事件从哪来」从窗口消息换成 `poll(2)`。平台适配真正要重写的，往往就是这一小块最不显眼的胶水。