2つのユースケースのために1つのソケットAPIを設計することにした。 ...ソケットAPIとかもう無限にあるだろとは思うけど今回の目的に合いそうなものが見つからなかった。

2つのユースケースは:

1. WebAssemblyアプリ向けのフレームワーク(yuniframe)でのソケットAPI 。いやまぁBSDソケットでも良いかもしれないけど、BSDソケットのセマンティクスを完全に実装するのは面倒でオーバーキルな可能性が高い。
2. マイコン向けの簡易VPNプロトコル 。マイコン側でTCP/IPを終端するのはなるべく避けたい。というのは、WIZnet W5500のようなハードウェアオフロードチップがあったり、wio Terminalのようにサブプロセッサ側にTCP/IPを実装しているといったケースがあり、これらを無視してマイコン側でもTCP/IPを実装するのは流石にリソースがもったいない。

機能

機能は基本的に Socks5 プロキシを基準に考える。つまり、

• 接続先には IPv4 、 IPv6 、 ホスト名の文字列指定 が可能
• トランスポート層のプロトコルは TCP と UDP をサポート
• Listen(TCP)とBind(UDP)もサポート

例えばICMPを使ってpingを打ったり、DHCPを使ってIPアドレスを取得したり、mDNSでLAN上の機器を名前解決することはできない。

コンテキストとマルチスレッド

一般的なソケットAPIと異なり、トランスポートを抽象化した "コンテキスト" を持ち、各種操作はコンテキストに対して行う。マルチスレッド時の排他はアプリケーション責となる。

トレードオフ

まぁ組込み向けなんでパフォーマンスや機能性は犠牲にしても良いかな。。例えばTCP接続タイムアウトの調整といった sockopt 系の操作は一切できない。

通信速度の異なるクライアントを複数サポートすることを考えると、ソケット毎にリングバッファを持ったりした方が良いかもしれない。でもまぁ真面目にパフォーマンスを考えるならプラットフォームのsocketを直接使えということで。。