.NET8でgRPCのパイプ通信を評価してみる＆ついでに既存プロジェクトを.NET8へ移行

.NET8でgRPCのパイプ通信 を評価してみる ＆ついでに既存プロジェクトを.NET8へ移行 2023/11/30 須藤（suusanex）

自己紹介  ID：suusanex（ connpass・Twitter・GitHub共通）  名前：須藤圭太  サイエンスパーク株式会社という独立系ソフトウェアベンダーに所属  4年ほど受託開発で、上流から下流まで全部を回す  ここ10年ほどは、自社製品開発も担当  Windowsアプリ開発のネタが多い

概要  Windowsアプリでは、プロセス間で通信をしたい場合がある  .NET 8でgRPCのパイプ通信が公式サポートされた  ということで、このような話をしてみます  話の前提：プロセス間通信したいケースと、gRPC  標準のTCP通信をパイプ通信に移行  そのメリットと実測データ  パイプ通信への移行の具体的な実装方法  既存のプロジェクトを.NET 8に移行

話の前提：プロセス間通信したい  Windowsアプリでは、プロセス1つで完結できず、他のプロセスと通信したい ケースがある  例えば、バックグラウンドで動くWindowsサービスと、GUIを持つユーザー セッションアプリで通信したい場合など

話の前提： gRPCをプロセス間通信に使う  gRPC：通信内容を専用構文で定義することで、クロスプラットフォームの通信がで きる（通常はTCP）  同一プラットフォーム内でプロセス間通信に使うだけでもメリットはある   最初から通信内容と通信方式が分離されていて、コード生成なども手厚い  つまり他のプロセス間通信手法より手軽 TCP通信でもlocalhostが対象なら十分に速い

TCPからパイプ通信へ  .NET 8で、gRPCでのパイプ通信を公式サポート  通信内容の定義はそのままに、通信方式をパイプ通信にできる

なぜパイプ通信？  TCP通信と比べてのメリットは？  他ソフトとのポート番号の衝突を気にしなくて良い  パイプは文字列なので衝突する可能性は低い  ファイルと同様にACLでの権限管理ができる  「TCPでも十分に速い」とは言ったが、より高速な用途ではパイプが優れる

いくつかのケースでの実測1  「接続・送信・受信・切断」の繰り返し  100ms間隔で「接続・送信・受信・切断」を繰り返し、1回ごとの所要時間を計測  TCP：約2000ms/1回  パイプ：約1ms /1回  通信確立の所要時間の違いか、圧倒的な差が付く  数秒オーダーよりも頻繁に通信を繰り返す場合、パイプ通信が有効

いくつかのケースでの実測2   ストリーム通信を確立し、その上で通信を繰り返し  1，ループ1回の所要時間と、  2，送信元の通信データ作成から、送信先の通信データ取得までの所要時間を測定  10ms間隔でループ 結果は次ページ

いくつかのケースでの実測2   1，ループ1回の所要時間  TCP：約15.65ms  パイプ：約15.55ms 2， 送信元の通信データ作成から、送信先の通信データ取得までの所要時間  TCP：約0.25ms  パイプ：約0.15ms  通信繰り返しの所要時間はほぼ同じ  通信内容そのものの到達時間にはわずかに差がある（通信全体の所要時間から すると誤差に近い）  よほど通信遅延のタイミングにシビアな用途でなければ、差は無いと言って良 い

速度のメリットが得られるケース まとめ  ストリームを常時確立せずに単発の通信をしたく、かつ数秒間隔では性能不足 のケースにはぴったり  ストリーム通信の場合はTCPと大差無い

実装方法は割と簡単 クライアント側


TCPの場合

var channel = GrpcChannel.ForAddress("http://localhost:50100/Connect1");
パイプの場合、パイプ接続処理をオプションへ渡すだけ
var channel = GrpcChannel.ForAddress("http://localhost/Connect1", new
{
HttpHandler = new
{
ConnectCallback = async (context, token) =>
{
var clientStream = new NamedPipeClientStream(/*パイプ名など、諸々のオプション*/);
await clientStream.ConnectAsync().ConfigureAwait(false);
return clientStream;
}
}
});
 色々省略してるので、詳細はMS Docsをどうぞ


• https://learn.microsoft.com/ja-jp/aspnet/core/grpc/interprocess-namedpipes?view=aspnetcore-8.0

実装方法は割と簡単 サーバー側


Generic Host前提で

IHost host = Host.CreateDefaultBuilder(args)
.ConfigureWebHostDefaults(webBuilder =>
{
webBuilder.ConfigureKestrel(options =>
{
//TCPの場合
options.Listen(IPAddress.Loopback, 50100, listenOptions =>
{
listenOptions.Protocols = HttpProtocols.Http2;
});
//パイプの場合
options.ListenNamedPipe(“（パイプ名）", listenOptions =>
{
listenOptions.Protocols = HttpProtocols.Http2;
});
});

サーバー側注意点  Windowsサービス(LocalSystem権限)からパイプを作ると、デフォルトではユー ザー権限の書き込み不可  ユーザーセッションからユーザー権限で操作したい場合は、Win32APIを使って パイプにACLを設定する必要あり   CreateFileで開いてGet/SetSecurityInfoなど コードは複雑なので省略、興味のある人はこちらをどうぞ  https://github.com/suusanex/sample_winservice_pipe_duplex_wcf_and_grpc/blob /master/gRPCWinServiceSample

• https://github.com/suusanex/sample_winservice_pipe_duplex_wcf_and_grpc/blob/master/gRPCWinServiceSample

.NET8より前の既存プロジェクトからの 移行は？    WPF・クラスライブラリなど(C#)  プロジェクトの「ターゲットフレームワーク」で「.NET 8.0」を選択するだけ。  もちろんファイルの<TargetFramework>を直接書き換えてもOK C++/CLI  プロジェクトの「.NETターゲットフレームワーク」で「.NET 8.0」を・・・選択肢にない。  コンボボックスに、手入力で「net8.0」と書く。 Win UI 3(C#)  未サポート・・・  https://learn.microsoft.com/ja-jp/windows/apps/windows-app-sdk/stable-channel （一部引用）この問題のため、さらに .NET 8 がまだ正式にリリースされていないため、 Windows App SDK 1.4 では .NET 8 が正式にサポートされていません。 ただし、このバー ジョンの App SDK で .NET 8 のプレリリース バージョンを引き続きターゲットとしたい場 合は、次の手順をお勧めします。

• https://learn.microsoft.com/ja-jp/windows/apps/windows-app-sdk/stable-channel

まとめ  PC内のプロセス間通信に、gRPCのパイプ通信を使うのは十分あり  .NET8より前のプロジェクトでTCPを使っている場合の移行も割と容易  特に接続・切断を数秒より速く繰り返すケースではメリット大  当てはまる場合は.NET 8移行の動機にもなりそう  WinUI 3、息してる？