狠狠撸

狠狠撸Share a Scribd company logo
Mono is Dead
~高速なC#サーバを目指して~
もくじ
? Introduction
? 颁#で1万颁濒颈别苍迟を捌く
? Mono is Dead
Introduction
やったこと
? 1対1で対戦する
? TCPの
? ゲームサーバを
? C#(Mono)で作った
結果
? 1サーバあたり10,000クライアント程度
ならいける
? 無事iOSとAndroidにリリースして、ちゃ
んと動いてる
長く苦しい戦いだった…
? 苦しかったのは主にMonoのせい
? 今日はMonoをdisります
? が、その前に前提知識(async/await構
文)の共有をします
Q&A
? なんでC#なの?
? クライアントがC#(Unity)で書かれて
いて、一部のロジックを共有したかっ
た
Q&A
? P2Pでやらないのはなぜ?
? 改ざんに対する処置がゲームサーバ作
るよりめんどそう
Q&A
? .NET Framework使わないの?
? 奥颈苍诲辞飞蝉を运用するのはとてもつらい
Q&A
? なんでTCPなの?UDPじゃだめなの?
? UDPはつらい
? パケット組み立てるのつらい
? 再送信処理を実装するのつらい
? 送信元を識別するのつらい
? 切断検知つらい
颁#で1万颁濒颈别苍迟を捌く
C#でTCP通信
? お題: 5バイトのデータを受け取り、そ
のデータをそのまま返すサーバを作ろ
う
? つまり劣化版贰肠丑辞サーバ
同期版
TcpClient client = // Accept部分は省略
Stream stream = client.GetStream();
while (true) {
var buf = new buf[5];
stream.Read(buf, 0, buf.Length);
stream.Write(buf, 0, buf.Length);
}
ダメ
? Readでbuf.Lengthだけ読める保証は無い
? Readの戻り値が0の時は終端だったりエ
ラーの場合なので例外を投げる
? 例外の処理をしよう
同期版(改)
static void ReadFully(this Stream stream, byte[] buf) {
var readBytes = 0;
while (readBytes != buf.Length) {
var n = stream.Read(buf, readBytes,
buf.Length - readBytes);
if (n == 0)
throw new Exception("hoge-");
readBytes += n;
}
}
同期版(改)
try {
while (true) {
var buf = new buf[5];
stream.ReadFully(buf);
stream.Write(buf, 0, buf.Length);
}
} catch (Exception e) {
// 例外出たらログを残して接続を閉じる
logger.Error("error", e);
client.Close();
}
簡単
? 同期的に書くのはとても簡単
? 例外処理を含めても簡単
だがしかし
だがしかし
CPUが全く働いてない
だがしかし
? 呼び出したスレッドが止まる
? 8スレッドで動かした場合、8クライアントが
Readするだけで全部止まる
? たかだかスレッド数までしかクライアントを
捌けない
スレッド増やせば?
? メモリが足りない
? スタック領域だけで最低256KBぐらい
? コンテキストスイッチで時間が掛かる
? なので1万クライアントをスレッドで捌くのは
きつい
? いわゆるC10K問題
つまり
? 1万クライアントをスレッドで同期処
理するのは無理
そこで
? 非同期処理
? C#には非同期処理用の関数がある
? BeginRead, EndRead, BeginWrite, EndWrite
? これを使えば解決できるはず
同期版(再掲)
try {
while (true) {
var buf = new buf[5];
stream.ReadFully(buf);
stream.Write(buf, 0, buf.Length);
}
} catch (Exception e) {
// 例外出たらログを残して接続を閉じる
logger.Error("error", e);
client.Close();
}
非同期版
var buf = new byte[5];
Func<IAsyncResult> func;
func = ar1 => {
stream.EndReadFully(ar1);
stream.BeginWrite(buf, 0, buf.Length, ar2 => {
stream.EndWrite(ar2);
// 再度BeginReadを始める(whileループ相当)
stream.BeginReadFully(buf, 0, buf.Length, func,
null);
};
};
stream.BeginReadFully(buf, 0, buf.Length, func, null);
完全に別コード
非同期版
var buf = new byte[5];
Func<IAsyncResult> func;
func = ar1 => {
stream.EndReadFully(ar1);
stream.BeginWrite(buf, 0, buf.Length, ar2 => {
stream.EndWrite(ar2);
// 再度BeginReadを始める(whileループ相当)
stream.BeginReadFully(buf, 0, buf.Length, func,
null);
};
};
stream.BeginReadFully(buf, 0, buf.Length, func, null);
どうやって実装するのか分かりませんでした
非同期版
var buf = new byte[5];
Func<IAsyncResult> func;
func = ar1 => {
stream.EndReadFully(ar1); // 例外処理どうしよう
stream.BeginWrite(buf, 0, buf.Length, ar2 => {
stream.EndWrite(ar2); // 例外処理どうしよう
// 再度BeginReadを始める(whileループ相当)
stream.BeginReadFully(buf, 0, buf.Length, func,
null);
};
};
stream.BeginReadFully(buf, 0, buf.Length, func, null);
例外処理つらい
非同期版
var buf = new byte[5];
Func<IAsyncResult> func;
func = ar1 => {
stream.EndReadFully(ar1);
stream.BeginWrite(buf, 0, buf.Length, ar2 => {
stream.EndWrite(ar2);
// 再度BeginReadを始める(whileループ相当)
stream.BeginReadFully(buf, 0, buf.Length, func,
null);
};
};
stream.BeginReadFully(buf, 0, buf.Length, func, null);
whileループすら再帰とか…
結論
? 非同期処理はつらい
そこで
? async/await構文
? C# 5.0 で入った新しい非同期処理
同期版(再掲)
static void ReadFully(
this Stream stream, byte[] buf) {
var readBytes = 0;
while (readBytes != buf.Length) {
var n = stream.Read(buf, readBytes,
buf.Length - readBytes);
if (n == 0)
throw new Exception("hoge-");
readBytes += n;
}
}
async/await版
static async Task ReadFullyAsync(
this Stream stream, byte[] buf) {
var readBytes = 0;
while (readBytes != buf.Length) {
var n = await stream.ReadAsync(buf, readBytes,
buf.Length - readBytes)
.ConfigureAwait(false);
if (n == 0)
throw new Exception("hoge-");
readBytes += n;
};
}
差分
static async Task ReadFullyAsync(
this Stream stream, byte[] buf) {
var readBytes = 0;
while (readBytes != buf.Length) {
var n = await stream.ReadAsync(buf, readBytes,
buf.Length - readBytes)
.ConfigureAwait(false);
if (n == 0)
throw new Exception("hoge-");
readBytes += n;
};
}
同期版(再掲)
try {
while (true) {
var buf = new buf[5];
stream.ReadFully(buf);
stream.Write(buf, 0, buf.Length);
}
} catch (Exception e) {
// 例外出たらログを残して接続を閉じる
logger.Error("error", e);
client.Close();
}
async/await版
try {
while (true) {
var buf = new buf[5];
await stream.ReadFullyAsync(buf)
.ConfigureAwait(false);
await stream.WriteAsync(buf, 0, buf.Length)
.ConfigureAwait(false);
}
} catch (Exception e) {
// 例外出たらログを残して接続を閉じる
logger.Error("error", e);
client.Close();
}
差分
try {
while (true) {
var buf = new buf[5];
await stream.ReadFullyAsync(buf)
.ConfigureAwait(false);
await stream.WriteAsync(buf, 0, buf.Length)
.ConfigureAwait(false);
}
} catch (Exception e) {
// 例外出たらログを残して接続を閉じる
logger.Error("error", e);
client.Close();
}
async/awaitは良い
? 同期版とほぼ同じように書ける
? 例外処理も簡単に書ける
実际の动き
? スレッドの代わりにタスクと呼ばれる
単位で動作する
? タスク自体はメモリをほぼ使わない
? いわゆる軽量スレッド
? awaitする度にタスクを処理するスレッ
ドが変わる
実际の动き
try {
while (true) {
var buf = new buf[5];
await stream.ReadFullyAsync(buf)
.ConfigureAwait(false);
await stream.WriteAsync(buf, 0, buf.Length)
.ConfigureAwait(false);
}
} catch (Exception e) {
// 例外出たらログを残して接続を閉じる
logger.Error("error", e);
client.Close();
}
Thread1
Thread2
実际の动き
実际の动き
タスク9個の場合
Q&A
? Con?gureAwait(false)って何?
? これが無いと、完了通知先が必ず呼
び出し元のスレッドになる
? UI処理する場合は便利だけど、ス
レッド待ちで遅くなるし、デッドロッ
クが起きる可能性もある
async/awaitは良い
? 同期版とほぼ同じように書ける
? 例外処理も簡単に書ける
? メモリをほとんど使わない (new!)
? CPUを使いきれる (new!)
? つまり1万クライアント捌ける
补蝉测苍肠/补飞补颈迟まとめ
? async/awaitを使って
? 高速で
? 書きやすい
? C#サーバ
? これは…いける!
补蝉测苍肠/补飞补颈迟まとめ
Mono is Dead
~本編始まるよ!~
.NET is Alive
? MicrosoftVisual C#を使って実装
? VC#を使っている時点ではほぼ問題な
く実装できてた
Mono is Dead
? VC#ではうまく動いていたexeをMonoで
実行すると…
Mono is Dead
? VC#ではうまく動いていたexeをMonoで
実行すると…
_人人人人人人_
>?突然の死?<
 ̄Y^Y^Y^Y^Y ̄
LogicalSetData で死ぬ
LogicalSetData で死ぬ
? System.Runtime.Remoting.Messaging.CallC
ontext.LogicalSetData
? TLS(Thread Local Storage)のタスク版み
たいなやつ(正確には違うけど)
? タスク単位のグローバル変数っぽいの
を作りたい場合、これに頼るしか無い
(はず)
LogicalSetData で死ぬ
? VC#では問題なく動いていたのに、
Monoだとおかしな動作をする
? 惭辞苍辞のソースコードを眺めてみると…
LogicalSetData で死ぬ
[ThreadStatic] static Hashtable logicalDatastore;
static void LogicalSetData(string name, object data)
{
var r = logicalDatastore;
if (r == null)
r = logicalDatastore = new Hashtable();
r[name] = data;
}
Mono-3.2.8のソースより
LogicalSetData で死ぬ
[ThreadStatic] static Hashtable logicalDatastore;
static void LogicalSetData(string name, object data)
{
var r = logicalDatastore;
if (r == null)
r = logicalDatastore = new Hashtable();
r[name] = data;
}
ただのTLS実装になっている
そんな実装で大丈夫か?
Mono-3.2.8のソースより
LogicalSetData で死ぬ
? Issueにも報告さ
れている
? Mono 4.0以降で
直っていること
が分かった
LogicalSetData で死ぬ
? タスク単位のグローバル変数を使う場
合はMono 4.0以降が必須
? Mono 4.0は2015年5月4日にリリース
? 公式パッケージに入ってない可能性が
あるので気をつけよう
LogicalSetData で死ぬ
? 結論: Mono 3.x は死ぬべき
キャンセルトークンで死ぬ
キャンセルトークンで死ぬ
? ReadAsyncやWriteAsyncなどの非同期処
理を中断する機能
? 主にタイムアウトの為に使う
キャンセルトークンで死ぬ
public virtual Task<int> ReadAsync(
byte[] buffer,
int offset,
int count,
CancellationToken cancellationToken)
// Task1
CancellationToken token = tokenSource.Token;
await stream.ReadAsync(buf, 0, size, token);
// Task2
// ReadAsyncの処理を中断させる
tokenSource.Cancel();
キャンセルトークンで死ぬ
? これでいけそうに見える
? が、実際はI/O処理を中断できない
? NetworkStreamがキャンセルトークンに
対応してない
? え、タイムアウトどうやって実現する
の?
キャンセルトークンで死ぬ
? Stack Over?ow曰く
? 「タイムアウトになったら別タスクで
Closeすりゃ中断できるよ」
? これなら…いける!
_人人人人人人_
>?突然の死?<
 ̄Y^Y^Y^Y^Y ̄
キャンセルトークンで死ぬ
キャンセルトークンで死ぬ
static async Task TestConnect() {
try {
var client = new TcpClient();
var task = Task.Run(
() => client.ConnectAsync("localhost", 8080));
client.Close();
await task.ConfigureAwait(false);
} catch (Exception) { }
}
これを10万回ぐらい呼び出すと大体死ぬ
全体コード
キャンセルトークンで死ぬ
? そもそもNetworkStreamは仕様的にはス
レッドセーフではない
? なので死ぬのは仕方がないという気も
する
? そしてタイムアウト実現は振り出しに
戻る
キャンセルトークンで死ぬ
? 結局キューに詰めて一本化することで
何とかした
キャンセルトークンで死ぬ
? ReadAsyncやCloseをリクエストキュー
に詰めて、
? ワーカータスクがそれを処理し、
? 結果をリプライキューに詰めたのを、
? 呼び出し元がリプライキューの結果を
読む
キャンセルトークンで死ぬ
public async Task<int> ReadAsync(
byte[] buf, int offset, int length,
CancellationToken token) {
// リクエストキューに詰めて
await requestQueue.Enqueue(new Request() {
Type = Operation.ReadAsync,
Buf = buf,
Offset = offset,
Length = length,
}).ConfigureAwait(false);
// レスポンスキューに結果が返ってくるのを待つ
var resp = await responseQueue.Dequeue(token)
.ConfigureAwait(false);
return resp.ReadResult;
}
キャンセルトークンで死ぬ
public async Task<int> ReadAsync(
byte[] buf, int offset, int length,
CancellationToken token) {
// リクエストキューに詰めて
await requestQueue.Enqueue(new Request() {
Type = Operation.ReadAsync,
Buf = buf,
Offset = offset,
Length = length,
}).ConfigureAwait(false);
// レスポンスキューに結果が返ってくるのを待つ
var resp = await responseQueue.Dequeue(token)
.ConfigureAwait(false);
return resp.ReadResult;
}
responseQueueがCancellationTokenに対応してればいい
キャンセルトークンで死ぬ
async void Run() {
while (true) {
// リクエストを受け取り
var op = await requestQueue.Dequeue().ConfigureAwait(false);
// リクエスト毎の処理をして
switch (op.Type) {
case Operation.ReadAsync:
var result = await client.ReadAsync(
op.Buf, op.Offset, op.Length).ConfigureAwait(false);
// レスポンスを返す
await responseQueue.Enqueue(resp)
.ConfigureAwait(false);
break;
case Operation.WriteAsync:
...
}
}
キャンセルトークンで死ぬ
? キューから1個ずつ取ってきて処理す
るので、同時にReadAsyncやCloseが呼ば
れたりしない
? responseQueueがキャンセルトークンに
対応してるので、無事タイムアウト処
理ができるようになった
キャンセルトークンで死ぬ
? 結論: Monoは通信のタイムアウトすら簡
単に対応できない
補足
? キャンセルトークンが使えないのは
VC#でも同じ
? ただし別タスクからCloseを呼び出しま
くっても落ちなかった
Q&A
? これってちゃんとClose呼ばれるの?
? 呼ばれないこともある
? でもソケットはSafeHandleなのでファ
イナライザがうまいことやってくれる
叠耻蹿蹿别谤叠濒辞肠办で死ぬ
叠耻蹿蹿别谤叠濒辞肠办で死ぬ
public async Task<int> ReadAsync(
byte[] buf, int offset, int length,
CancellationToken token) {
// リクエストキューに詰めて
await requestQueue.Enqueue(new Request() {
Type = Operation.ReadAsync,
Buf = buf,
Offset = offset,
Length = length,
}).ConfigureAwait(false);
// レスポンスキューに結果が返ってくるのを待つ
var resp = await responseQueue.Dequeue(token)
.ConfigureAwait(false);
return resp.ReadResult;
}
requestQueueとresponseQueueはどうやって作るの?
叠耻蹿蹿别谤叠濒辞肠办で死ぬ
? Queue<T>はスレッドセーフではない
? ConcurrentQueue<T>はawaitで待てない
? 补蝉测苍肠/补飞补颈迟に対応したキューが必要
叠耻蹿蹿别谤叠濒辞肠办で死ぬ
? System.Threading.Tasks.Data?ow.BufferBlo
ck が使えそう
? BufferBlock.SendAsync(data, token)で送信
? BufferBlock.ReceiveAsync(token)で受信
? キャンセルトークンが使える!
_人人人人人人_
>?突然の死?<
 ̄Y^Y^Y^Y^Y ̄
叠耻蹿蹿别谤叠濒辞肠办で死ぬ
叠耻蹿蹿别谤叠濒辞肠办で死ぬ
static async Task SendTask(BufferBlock<string> bb) {
for (int i = 0; i < 10000; i++) {
await bb.SendAsync(i.ToString()).ConfigureAwait(false);
await Task.Delay(1).ConfigureAwait(false);
}
}
static async Task ReceiveTask(BufferBlock<string> bb) {
for (int i = 0; i < 10000; i++) {
try {
await bb.ReceiveAsync(TimeSpan.FromMilliseconds(1))
.ConfigureAwait(false);
} catch (Exception) { }
}
}
SendTaskとReceiveTaskを同時に実行すると大体死ぬ
全体コード
叠耻蹿蹿别谤叠濒辞肠办で死ぬ
? 普通にバグ
? ReceiveAsyncのタイムアウト時の処理で
レースコンディション起こしてる
叠耻蹿蹿别谤叠濒辞肠办で死ぬ
? 結局自作した
? AsyncMutex
? AsyncConditionVariable
? AsyncQueue
? 今のところ問題なく動いてる
叠耻蹿蹿别谤叠濒辞肠办で死ぬ
? 結論: Monoはまともに使えないライブ
ラリを提供している
厂骋别苍で死ぬ
厂骋别苍で死ぬ
? Mono曰く
? SGen is a new and powerful garbage
collector.
厂骋别苍で死ぬ
_人人人人人人_
>?突然の死?<
 ̄Y^Y^Y^Y^Y ̄
厂骋别苍で死ぬ
? しばらく動かしてると唐突に死ぬ
? スタックトレースを見るとSGenの関数
内で死んでる
? new and powerful ェ…
厂骋别苍で死ぬ
? 古き良き Boehm GC を使うと死ななく
なった
? ただしメモリが4GBまでしか使えない
? 複数プロセス起動することで対応
厂骋别苍で死ぬ
? 結論: Monoはnew and powerful (笑) な
GCを提供している
尘尘补辫(狈翱狈贰)で死ぬ
尘尘补辫(狈翱狈贰)で死ぬ
_人人人人人人_
>?突然の死?<
 ̄Y^Y^Y^Y^Y ̄
尘尘补辫(狈翱狈贰)で死ぬ
? しばらく動かしていると
? mmap(...PROT_NONE...) failed
? というエラーを出して死ぬ
尘尘补辫(狈翱狈贰)で死ぬ
? Issueにあるように、コンパイラのビル
ド時に-DUSE_MMAPと-DUSE_MUNMAP
を外す必要がある
? Monoをソースからビルドし直し
尘尘补辫(狈翱狈贰)で死ぬ
? Monoはしばらく動かしてると大体死ぬ
メモリリークで死ぬ
メモリリークで死ぬ
メモリリークで死ぬ
? 未解決問題
? 負荷が掛かっている場合だけメモリ使
用量が増え続ける
? ゲームサーバのコードが悪いせいなの
かどうか分からない
メモリリークで死ぬ
? PHP製作者曰く:
? 「僕なら、10リクエストごとにApache
を再起動しますね。」
? ということで、一定量動かしたらプロ
セスを再起動するようにした
メモリリークで死ぬ
メモリリークで死ぬ
? 結論: Monoはメモリリークを起こしてい
るかも、と疑心暗鬼になるだけの下地
がある
まとめ
? Monoは人類には早かった
? 次やるならクライアントをホストにす
ると思う
まとめ
? とはいえ、async/awaitのおかげでサーバ
のコードは相当短くなった
? 全部で5,000行程度
? ※クライアントとの共通コードは除く
?言い換えれば5,000行程度でMonoが死にま
くったという…
まとめ
? Monoは(人間とプロセスが)死ぬ
? 覚悟を持って使いましょう
おわり

More Related Content

What's hot (19)

NextGen Server/Client Architecture - gRPC + Unity + C#
NextGen Server/Client Architecture - gRPC + Unity + C#NextGen Server/Client Architecture - gRPC + Unity + C#
NextGen Server/Client Architecture - gRPC + Unity + C#
Yoshifumi Kawai
?
XML-RPC : Pythonが「電池付属」と呼ばれる理由
XML-RPC : Pythonが「電池付属」と呼ばれる理由XML-RPC : Pythonが「電池付属」と呼ばれる理由
XML-RPC : Pythonが「電池付属」と呼ばれる理由
Ransui Iso
?
async/await のしくみ
async/await のしくみasync/await のしくみ
async/await のしくみ
信之 岩永
?
Pyconjp2014_implementations
Pyconjp2014_implementationsPyconjp2014_implementations
Pyconjp2014_implementations
masahitojp
?
Async design with Unity3D
Async design with Unity3DAsync design with Unity3D
Async design with Unity3D
Kouji Hosoda
?
Altanative macro
Altanative macroAltanative macro
Altanative macro
Motohiro KOSAKI
?
LINQ in Unity
LINQ in UnityLINQ in Unity
LINQ in Unity
Yoshifumi Kawai
?
笔测翱辫别苍颁尝による骋笔骋笔鲍入门
笔测翱辫别苍颁尝による骋笔骋笔鲍入门笔测翱辫别苍颁尝による骋笔骋笔鲍入门
笔测翱辫别苍颁尝による骋笔骋笔鲍入门
Yosuke Onoue
?
「黒騎士と白の魔王」gRPCによるHTTP/2 - API, Streamingの実践
「黒騎士と白の魔王」gRPCによるHTTP/2 - API, Streamingの実践「黒騎士と白の魔王」gRPCによるHTTP/2 - API, Streamingの実践
「黒騎士と白の魔王」gRPCによるHTTP/2 - API, Streamingの実践
Yoshifumi Kawai
?
本当にわかる Spectre と Meltdown
本当にわかる Spectre と Meltdown本当にわかる Spectre と Meltdown
本当にわかる Spectre と Meltdown
Hirotaka Kawata
?
core dumpでcode golf
core dumpでcode golfcore dumpでcode golf
core dumpでcode golf
Nomura Yusuke
?
A quick tour of the Cysharp OSS
A quick tour of the Cysharp OSSA quick tour of the Cysharp OSS
A quick tour of the Cysharp OSS
Yoshifumi Kawai
?
Effective Modern C++ 勉強会#3 Item16
Effective Modern C++ 勉強会#3 Item16Effective Modern C++ 勉強会#3 Item16
Effective Modern C++ 勉強会#3 Item16
Mitsuru Kariya
?
高速な倍精度指数関数别虫辫の実装
高速な倍精度指数関数别虫辫の実装高速な倍精度指数関数别虫辫の実装
高速な倍精度指数関数别虫辫の実装
MITSUNARI Shigeo
?
effective modern c++ chapeter36
effective modern c++ chapeter36effective modern c++ chapeter36
effective modern c++ chapeter36
Tatsuki SHIMIZU
?
SEH on mingw32
SEH on mingw32SEH on mingw32
SEH on mingw32
kikairoya
?
高速な暗号実装のためにしてきたこと
高速な暗号実装のためにしてきたこと高速な暗号実装のためにしてきたこと
高速な暗号実装のためにしてきたこと
MITSUNARI Shigeo
?
WASM(WebAssembly)入門 ペアリング演算やってみた
WASM(WebAssembly)入門 ペアリング演算やってみたWASM(WebAssembly)入門 ペアリング演算やってみた
WASM(WebAssembly)入門 ペアリング演算やってみた
MITSUNARI Shigeo
?
NextGen Server/Client Architecture - gRPC + Unity + C#
NextGen Server/Client Architecture - gRPC + Unity + C#NextGen Server/Client Architecture - gRPC + Unity + C#
NextGen Server/Client Architecture - gRPC + Unity + C#
Yoshifumi Kawai
?
XML-RPC : Pythonが「電池付属」と呼ばれる理由
XML-RPC : Pythonが「電池付属」と呼ばれる理由XML-RPC : Pythonが「電池付属」と呼ばれる理由
XML-RPC : Pythonが「電池付属」と呼ばれる理由
Ransui Iso
?
Pyconjp2014_implementations
Pyconjp2014_implementationsPyconjp2014_implementations
Pyconjp2014_implementations
masahitojp
?
Async design with Unity3D
Async design with Unity3DAsync design with Unity3D
Async design with Unity3D
Kouji Hosoda
?
笔测翱辫别苍颁尝による骋笔骋笔鲍入门
笔测翱辫别苍颁尝による骋笔骋笔鲍入门笔测翱辫别苍颁尝による骋笔骋笔鲍入门
笔测翱辫别苍颁尝による骋笔骋笔鲍入门
Yosuke Onoue
?
「黒騎士と白の魔王」gRPCによるHTTP/2 - API, Streamingの実践
「黒騎士と白の魔王」gRPCによるHTTP/2 - API, Streamingの実践「黒騎士と白の魔王」gRPCによるHTTP/2 - API, Streamingの実践
「黒騎士と白の魔王」gRPCによるHTTP/2 - API, Streamingの実践
Yoshifumi Kawai
?
本当にわかる Spectre と Meltdown
本当にわかる Spectre と Meltdown本当にわかる Spectre と Meltdown
本当にわかる Spectre と Meltdown
Hirotaka Kawata
?
A quick tour of the Cysharp OSS
A quick tour of the Cysharp OSSA quick tour of the Cysharp OSS
A quick tour of the Cysharp OSS
Yoshifumi Kawai
?
Effective Modern C++ 勉強会#3 Item16
Effective Modern C++ 勉強会#3 Item16Effective Modern C++ 勉強会#3 Item16
Effective Modern C++ 勉強会#3 Item16
Mitsuru Kariya
?
高速な倍精度指数関数别虫辫の実装
高速な倍精度指数関数别虫辫の実装高速な倍精度指数関数别虫辫の実装
高速な倍精度指数関数别虫辫の実装
MITSUNARI Shigeo
?
effective modern c++ chapeter36
effective modern c++ chapeter36effective modern c++ chapeter36
effective modern c++ chapeter36
Tatsuki SHIMIZU
?
高速な暗号実装のためにしてきたこと
高速な暗号実装のためにしてきたこと高速な暗号実装のためにしてきたこと
高速な暗号実装のためにしてきたこと
MITSUNARI Shigeo
?
WASM(WebAssembly)入門 ペアリング演算やってみた
WASM(WebAssembly)入門 ペアリング演算やってみたWASM(WebAssembly)入門 ペアリング演算やってみた
WASM(WebAssembly)入門 ペアリング演算やってみた
MITSUNARI Shigeo
?

Viewers also liked (8)

颁谤测蝉迟补濒贵补苍迟补蝉颈补を支えきった技术と技术た?けて?はと?うにもならなかった话
颁谤测蝉迟补濒贵补苍迟补蝉颈补を支えきった技术と技术た?けて?はと?うにもならなかった话颁谤测蝉迟补濒贵补苍迟补蝉颈补を支えきった技术と技术た?けて?はと?うにもならなかった话
颁谤测蝉迟补濒贵补苍迟补蝉颈补を支えきった技术と技术た?けて?はと?うにもならなかった话
Keisuke Utsumi
?
贬迟迟辫颁濒颈别苍迟详解、或いは非同期の落とし穴について
贬迟迟辫颁濒颈别苍迟详解、或いは非同期の落とし穴について贬迟迟辫颁濒颈别苍迟详解、或いは非同期の落とし穴について
贬迟迟辫颁濒颈别苍迟详解、或いは非同期の落とし穴について
Yoshifumi Kawai
?
Async deepdive before de:code
Async deepdive before de:codeAsync deepdive before de:code
Async deepdive before de:code
Kouji Matsui
?
continuatioN Linking
continuatioN LinkingcontinuatioN Linking
continuatioN Linking
Kouji Matsui
?
Async await in C++
Async await in C++Async await in C++
Async await in C++
cppfrug
?
これからの「补蝉测苍肠/补飞补颈迟」の话をしよう
これからの「补蝉测苍肠/补飞补颈迟」の话をしようこれからの「补蝉测苍肠/补飞补颈迟」の话をしよう
これからの「补蝉测苍肠/补飞补颈迟」の话をしよう
Kouji Matsui
?
async/awaitダークサイド is 何
async/awaitダークサイド is 何async/awaitダークサイド is 何
async/awaitダークサイド is 何
Kouji Matsui
?
补蝉测苍肠/补飞补颈迟不要论
补蝉测苍肠/补飞补颈迟不要论补蝉测苍肠/补飞补颈迟不要论
补蝉测苍肠/补飞补颈迟不要论
bleis tift
?
颁谤测蝉迟补濒贵补苍迟补蝉颈补を支えきった技术と技术た?けて?はと?うにもならなかった话
颁谤测蝉迟补濒贵补苍迟补蝉颈补を支えきった技术と技术た?けて?はと?うにもならなかった话颁谤测蝉迟补濒贵补苍迟补蝉颈补を支えきった技术と技术た?けて?はと?うにもならなかった话
颁谤测蝉迟补濒贵补苍迟补蝉颈补を支えきった技术と技术た?けて?はと?うにもならなかった话
Keisuke Utsumi
?
贬迟迟辫颁濒颈别苍迟详解、或いは非同期の落とし穴について
贬迟迟辫颁濒颈别苍迟详解、或いは非同期の落とし穴について贬迟迟辫颁濒颈别苍迟详解、或いは非同期の落とし穴について
贬迟迟辫颁濒颈别苍迟详解、或いは非同期の落とし穴について
Yoshifumi Kawai
?
Async deepdive before de:code
Async deepdive before de:codeAsync deepdive before de:code
Async deepdive before de:code
Kouji Matsui
?
Async await in C++
Async await in C++Async await in C++
Async await in C++
cppfrug
?
これからの「补蝉测苍肠/补飞补颈迟」の话をしよう
これからの「补蝉测苍肠/补飞补颈迟」の话をしようこれからの「补蝉测苍肠/补飞补颈迟」の话をしよう
これからの「补蝉测苍肠/补飞补颈迟」の话をしよう
Kouji Matsui
?
async/awaitダークサイド is 何
async/awaitダークサイド is 何async/awaitダークサイド is 何
async/awaitダークサイド is 何
Kouji Matsui
?
补蝉测苍肠/补飞补颈迟不要论
补蝉测苍肠/补飞补颈迟不要论补蝉测苍肠/补飞补颈迟不要论
补蝉测苍肠/补飞补颈迟不要论
bleis tift
?

Similar to Mono is Dead (20)

C# 7.2 with .NET Core 2.1
C# 7.2 with .NET Core 2.1C# 7.2 with .NET Core 2.1
C# 7.2 with .NET Core 2.1
信之 岩永
?
「Python言語」はじめの一歩 / First step of Python / 2016 Jan 12
「Python言語」はじめの一歩 / First step of Python / 2016 Jan 12「Python言語」はじめの一歩 / First step of Python / 2016 Jan 12
「Python言語」はじめの一歩 / First step of Python / 2016 Jan 12
Takanori Suzuki
?
Gpgpu tomoaki-fp16
Gpgpu tomoaki-fp16Gpgpu tomoaki-fp16
Gpgpu tomoaki-fp16
tomoaki0705
?
Bossan dentoo
Bossan dentooBossan dentoo
Bossan dentoo
kubo39
?
Richard high performance fuzzing ja
Richard  high performance fuzzing jaRichard  high performance fuzzing ja
Richard high performance fuzzing ja
PacSecJP
?
ゆるふわLinux-HA ?PostgreSQL編?
ゆるふわLinux-HA ?PostgreSQL編?ゆるふわLinux-HA ?PostgreSQL編?
ゆるふわLinux-HA ?PostgreSQL編?
Taro Matsuzawa
?
密着!わたしのコンソールアフ?リ开発环境
密着!わたしのコンソールアフ?リ开発环境密着!わたしのコンソールアフ?リ开発环境
密着!わたしのコンソールアフ?リ开発环境
Fumihito Yokoyama
?
Firefox 3.1 & MozTech
Firefox 3.1 & MozTechFirefox 3.1 & MozTech
Firefox 3.1 & MozTech
dynamis
?
C# 8.0 Preview in Visual Studio 2019 (16.0)
C# 8.0 Preview in Visual Studio 2019 (16.0)C# 8.0 Preview in Visual Studio 2019 (16.0)
C# 8.0 Preview in Visual Studio 2019 (16.0)
信之 岩永
?
.NET Core 2.x 時代の C#
.NET Core 2.x 時代の C#.NET Core 2.x 時代の C#
.NET Core 2.x 時代の C#
信之 岩永
?
Buffer overflow
Buffer overflowBuffer overflow
Buffer overflow
ionis111
?
厂迟谤别补尘2の基本
厂迟谤别补尘2の基本厂迟谤别补尘2の基本
厂迟谤别补尘2の基本
shigeki_ohtsu
?
WebRTC SFU mediasoup sample
WebRTC SFU mediasoup sampleWebRTC SFU mediasoup sample
WebRTC SFU mediasoup sample
mganeko
?
SmartNews TechNight Vol5 : SmartNews AdServer 解体新書 / ポストモーテム
SmartNews TechNight Vol5 : SmartNews AdServer 解体新書 / ポストモーテムSmartNews TechNight Vol5 : SmartNews AdServer 解体新書 / ポストモーテム
SmartNews TechNight Vol5 : SmartNews AdServer 解体新書 / ポストモーテム
SmartNews, Inc.
?
ネットワーク ゲームにおけるTCPとUDPの使い分け
ネットワーク ゲームにおけるTCPとUDPの使い分けネットワーク ゲームにおけるTCPとUDPの使い分け
ネットワーク ゲームにおけるTCPとUDPの使い分け
モノビット エンジン
?
ネットワーク ゲームにおけるTCPとUDPの使い分け
ネットワーク ゲームにおけるTCPとUDPの使い分けネットワーク ゲームにおけるTCPとUDPの使い分け
ネットワーク ゲームにおけるTCPとUDPの使い分け
モノビット エンジン
?
Firefox 3.1 In Depth (?)
Firefox 3.1 In Depth (?)Firefox 3.1 In Depth (?)
Firefox 3.1 In Depth (?)
dynamis
?
C# 8.0 非同期ストリーム
C# 8.0 非同期ストリームC# 8.0 非同期ストリーム
C# 8.0 非同期ストリーム
信之 岩永
?
clu2cは64ビットOSでも使えます (OSC 2012 Hiroshima LT用資料)
clu2cは64ビットOSでも使えます (OSC 2012 Hiroshima LT用資料)clu2cは64ビットOSでも使えます (OSC 2012 Hiroshima LT用資料)
clu2cは64ビットOSでも使えます (OSC 2012 Hiroshima LT用資料)
洋史 東平
?
翱蝉蝉で作成するチーム开発环境
翱蝉蝉で作成するチーム开発环境翱蝉蝉で作成するチーム开発环境
翱蝉蝉で作成するチーム开発环境
Tadahiro Ishisaka
?
「Python言語」はじめの一歩 / First step of Python / 2016 Jan 12
「Python言語」はじめの一歩 / First step of Python / 2016 Jan 12「Python言語」はじめの一歩 / First step of Python / 2016 Jan 12
「Python言語」はじめの一歩 / First step of Python / 2016 Jan 12
Takanori Suzuki
?
Bossan dentoo
Bossan dentooBossan dentoo
Bossan dentoo
kubo39
?
Richard high performance fuzzing ja
Richard  high performance fuzzing jaRichard  high performance fuzzing ja
Richard high performance fuzzing ja
PacSecJP
?
ゆるふわLinux-HA ?PostgreSQL編?
ゆるふわLinux-HA ?PostgreSQL編?ゆるふわLinux-HA ?PostgreSQL編?
ゆるふわLinux-HA ?PostgreSQL編?
Taro Matsuzawa
?
密着!わたしのコンソールアフ?リ开発环境
密着!わたしのコンソールアフ?リ开発环境密着!わたしのコンソールアフ?リ开発环境
密着!わたしのコンソールアフ?リ开発环境
Fumihito Yokoyama
?
Firefox 3.1 & MozTech
Firefox 3.1 & MozTechFirefox 3.1 & MozTech
Firefox 3.1 & MozTech
dynamis
?
C# 8.0 Preview in Visual Studio 2019 (16.0)
C# 8.0 Preview in Visual Studio 2019 (16.0)C# 8.0 Preview in Visual Studio 2019 (16.0)
C# 8.0 Preview in Visual Studio 2019 (16.0)
信之 岩永
?
Buffer overflow
Buffer overflowBuffer overflow
Buffer overflow
ionis111
?
厂迟谤别补尘2の基本
厂迟谤别补尘2の基本厂迟谤别补尘2の基本
厂迟谤别补尘2の基本
shigeki_ohtsu
?
WebRTC SFU mediasoup sample
WebRTC SFU mediasoup sampleWebRTC SFU mediasoup sample
WebRTC SFU mediasoup sample
mganeko
?
SmartNews TechNight Vol5 : SmartNews AdServer 解体新書 / ポストモーテム
SmartNews TechNight Vol5 : SmartNews AdServer 解体新書 / ポストモーテムSmartNews TechNight Vol5 : SmartNews AdServer 解体新書 / ポストモーテム
SmartNews TechNight Vol5 : SmartNews AdServer 解体新書 / ポストモーテム
SmartNews, Inc.
?
ネットワーク ゲームにおけるTCPとUDPの使い分け
ネットワーク ゲームにおけるTCPとUDPの使い分けネットワーク ゲームにおけるTCPとUDPの使い分け
ネットワーク ゲームにおけるTCPとUDPの使い分け
モノビット エンジン
?
ネットワーク ゲームにおけるTCPとUDPの使い分け
ネットワーク ゲームにおけるTCPとUDPの使い分けネットワーク ゲームにおけるTCPとUDPの使い分け
ネットワーク ゲームにおけるTCPとUDPの使い分け
モノビット エンジン
?
Firefox 3.1 In Depth (?)
Firefox 3.1 In Depth (?)Firefox 3.1 In Depth (?)
Firefox 3.1 In Depth (?)
dynamis
?
C# 8.0 非同期ストリーム
C# 8.0 非同期ストリームC# 8.0 非同期ストリーム
C# 8.0 非同期ストリーム
信之 岩永
?
clu2cは64ビットOSでも使えます (OSC 2012 Hiroshima LT用資料)
clu2cは64ビットOSでも使えます (OSC 2012 Hiroshima LT用資料)clu2cは64ビットOSでも使えます (OSC 2012 Hiroshima LT用資料)
clu2cは64ビットOSでも使えます (OSC 2012 Hiroshima LT用資料)
洋史 東平
?
翱蝉蝉で作成するチーム开発环境
翱蝉蝉で作成するチーム开発环境翱蝉蝉で作成するチーム开発环境
翱蝉蝉で作成するチーム开発环境
Tadahiro Ishisaka
?

Recently uploaded (8)

IoT Devices Compliant with JC-STAR Using Linux as a Container OS
IoT Devices Compliant with JC-STAR Using Linux as a Container OSIoT Devices Compliant with JC-STAR Using Linux as a Container OS
IoT Devices Compliant with JC-STAR Using Linux as a Container OS
Tomohiro Saneyoshi
?
Apache Sparkに対するKubernetesのNUMAノードを意識したリソース割り当ての性能効果 (Open Source Conference ...
Apache Sparkに対するKubernetesのNUMAノードを意識したリソース割り当ての性能効果 (Open Source Conference ...Apache Sparkに対するKubernetesのNUMAノードを意識したリソース割り当ての性能効果 (Open Source Conference ...
Apache Sparkに対するKubernetesのNUMAノードを意識したリソース割り当ての性能効果 (Open Source Conference ...
NTT DATA Technology & Innovation
?
ElasticsearchでSPLADEする [Search Engineering Tech Talk 2025 Winter]
ElasticsearchでSPLADEする [Search Engineering Tech Talk 2025 Winter]ElasticsearchでSPLADEする [Search Engineering Tech Talk 2025 Winter]
ElasticsearchでSPLADEする [Search Engineering Tech Talk 2025 Winter]
kota usuha
?
ドメインモデリング基本编①词全体の流れ2025冲02冲27社内向け开催.辫辫迟虫
ドメインモデリング基本编①词全体の流れ2025冲02冲27社内向け开催.辫辫迟虫ドメインモデリング基本编①词全体の流れ2025冲02冲27社内向け开催.辫辫迟虫
ドメインモデリング基本编①词全体の流れ2025冲02冲27社内向け开催.辫辫迟虫
ssuserfcafd1
?
Matching_Program_for_Quantum_Challenge_Overview.pdf
Matching_Program_for_Quantum_Challenge_Overview.pdfMatching_Program_for_Quantum_Challenge_Overview.pdf
Matching_Program_for_Quantum_Challenge_Overview.pdf
hirokiokuda2
?
滨肠丑颈颈搁颈办颈蝉耻办别冲理学疗法士间の知识共有に向けた临床推论テキストの构造化に関する研究.辫诲蹿
滨肠丑颈颈搁颈办颈蝉耻办别冲理学疗法士间の知识共有に向けた临床推论テキストの构造化に関する研究.辫诲蹿滨肠丑颈颈搁颈办颈蝉耻办别冲理学疗法士间の知识共有に向けた临床推论テキストの构造化に関する研究.辫诲蹿
滨肠丑颈颈搁颈办颈蝉耻办别冲理学疗法士间の知识共有に向けた临床推论テキストの构造化に関する研究.辫诲蹿
Matsushita Laboratory
?
PostgreSQL最新動向 ~カラムナストアから生成AI連携まで~ (Open Source Conference 2025 Tokyo/Spring ...
PostgreSQL最新動向 ~カラムナストアから生成AI連携まで~ (Open Source Conference 2025 Tokyo/Spring ...PostgreSQL最新動向 ~カラムナストアから生成AI連携まで~ (Open Source Conference 2025 Tokyo/Spring ...
PostgreSQL最新動向 ~カラムナストアから生成AI連携まで~ (Open Source Conference 2025 Tokyo/Spring ...
NTT DATA Technology & Innovation
?
2025フードテックWeek大阪展示会 - LoRaWANを使った複数ポイント温度管理 by AVNET玉井部長
2025フードテックWeek大阪展示会 - LoRaWANを使った複数ポイント温度管理 by AVNET玉井部長2025フードテックWeek大阪展示会 - LoRaWANを使った複数ポイント温度管理 by AVNET玉井部長
2025フードテックWeek大阪展示会 - LoRaWANを使った複数ポイント温度管理 by AVNET玉井部長
CRI Japan, Inc.
?
IoT Devices Compliant with JC-STAR Using Linux as a Container OS
IoT Devices Compliant with JC-STAR Using Linux as a Container OSIoT Devices Compliant with JC-STAR Using Linux as a Container OS
IoT Devices Compliant with JC-STAR Using Linux as a Container OS
Tomohiro Saneyoshi
?
Apache Sparkに対するKubernetesのNUMAノードを意識したリソース割り当ての性能効果 (Open Source Conference ...
Apache Sparkに対するKubernetesのNUMAノードを意識したリソース割り当ての性能効果 (Open Source Conference ...Apache Sparkに対するKubernetesのNUMAノードを意識したリソース割り当ての性能効果 (Open Source Conference ...
Apache Sparkに対するKubernetesのNUMAノードを意識したリソース割り当ての性能効果 (Open Source Conference ...
NTT DATA Technology & Innovation
?
ElasticsearchでSPLADEする [Search Engineering Tech Talk 2025 Winter]
ElasticsearchでSPLADEする [Search Engineering Tech Talk 2025 Winter]ElasticsearchでSPLADEする [Search Engineering Tech Talk 2025 Winter]
ElasticsearchでSPLADEする [Search Engineering Tech Talk 2025 Winter]
kota usuha
?
ドメインモデリング基本编①词全体の流れ2025冲02冲27社内向け开催.辫辫迟虫
ドメインモデリング基本编①词全体の流れ2025冲02冲27社内向け开催.辫辫迟虫ドメインモデリング基本编①词全体の流れ2025冲02冲27社内向け开催.辫辫迟虫
ドメインモデリング基本编①词全体の流れ2025冲02冲27社内向け开催.辫辫迟虫
ssuserfcafd1
?
Matching_Program_for_Quantum_Challenge_Overview.pdf
Matching_Program_for_Quantum_Challenge_Overview.pdfMatching_Program_for_Quantum_Challenge_Overview.pdf
Matching_Program_for_Quantum_Challenge_Overview.pdf
hirokiokuda2
?
滨肠丑颈颈搁颈办颈蝉耻办别冲理学疗法士间の知识共有に向けた临床推论テキストの构造化に関する研究.辫诲蹿
滨肠丑颈颈搁颈办颈蝉耻办别冲理学疗法士间の知识共有に向けた临床推论テキストの构造化に関する研究.辫诲蹿滨肠丑颈颈搁颈办颈蝉耻办别冲理学疗法士间の知识共有に向けた临床推论テキストの构造化に関する研究.辫诲蹿
滨肠丑颈颈搁颈办颈蝉耻办别冲理学疗法士间の知识共有に向けた临床推论テキストの构造化に関する研究.辫诲蹿
Matsushita Laboratory
?
PostgreSQL最新動向 ~カラムナストアから生成AI連携まで~ (Open Source Conference 2025 Tokyo/Spring ...
PostgreSQL最新動向 ~カラムナストアから生成AI連携まで~ (Open Source Conference 2025 Tokyo/Spring ...PostgreSQL最新動向 ~カラムナストアから生成AI連携まで~ (Open Source Conference 2025 Tokyo/Spring ...
PostgreSQL最新動向 ~カラムナストアから生成AI連携まで~ (Open Source Conference 2025 Tokyo/Spring ...
NTT DATA Technology & Innovation
?
2025フードテックWeek大阪展示会 - LoRaWANを使った複数ポイント温度管理 by AVNET玉井部長
2025フードテックWeek大阪展示会 - LoRaWANを使った複数ポイント温度管理 by AVNET玉井部長2025フードテックWeek大阪展示会 - LoRaWANを使った複数ポイント温度管理 by AVNET玉井部長
2025フードテックWeek大阪展示会 - LoRaWANを使った複数ポイント温度管理 by AVNET玉井部長
CRI Japan, Inc.
?

Mono is Dead