@gabezhao
@shiny

新的盲点，之前我也用过拍立淘和京东拍照搜索。

app 自带的拍照功能截取有毛病，没截取全，导致找不到。

这会儿为了问 AI 、发帖拍工整并准确截取，却忘记重新把照片喂给淘宝。

的确找到了一两款，尽管手把和图里的比起来有些差异

指虎不是违禁词，能单独搜索到对应的东西，缩减关键词 “指虎 杯” 在淘宝总算找到一款。

看来就是它了

@andyJado 然而，淘宝和京东都找不到，我猜“指虎”是违禁词

@andyJado 找了图，虽然很搞笑，但这真的比图中的要有效分担手指压力呀 😂

@whileFalse 维基百科上对于马克杯的解释是

马克杯的意思是大柄杯子，因为马克杯的英文名是“mug”，所以音译成马克杯。

你找到了盲点，这不尽管有柄但不够大，我应该称其为“茶杯” 🤔

为啥没有人提到 Microsoft.Office.Interop.Word (狗头）

我把 C#的命名习惯带去 js ，异步方法一律 Async 后缀，这样就能一眼看出

我用 Winform 缝合 Blazor （

https://learn.microsoft.com/aspnet/core/blazor/hybrid/tutorials/windows-forms?view=aspnetcore-8.0

在 C#玩 TCP 当然是 Kestrel ，微软自家出品的 Socket 封装，客户端和服务端都能用，用上它之后再也不用自己操心缓冲区了，PDU 边界（低情商俗称：粘包分包）什么的更是雕虫小技

https://learn.microsoft.com/dotnet/api/microsoft.aspnetcore.server.kestrel.transport.sockets.socketconnectioncontextfactory.create?view=aspnetcore-8.0

购物类 APP 用完就将其杀死，从未遇到过顽固推送，估计是杀死 APP 的同时通知栏内容也跟着消失吧

绿色守护免费版就够用了

XPERIA 电池保养可以设置充电电量限制在 80%或 90%, 妈妈再也不用担心我充过头了

@0o0O0o0O0o #6
米如果是几斤真空小包装,按件计
卷纸按卷计
似乎没有毛病?

@liuhan907 回来报喜
正经项目换 kestrel 重构之后，目前压测连接承载能力摸到 3 万了，需要花一点时间来 accept ，问题不大～

@liuhan907
压测了一下 Kestrel 的 TCP 服务端，花了几秒钟来 accept 两万 TCP ，虽然有部分重连，但还是全都连上了

看来以后可以用它，妈妈再也不用担心我维护不好 Socket 和 SAE 了，乐。

@liuhan907

另外，我看 Kestrel 源代码时注意到监听是单线程异步，这可能会 accept 不过来，经验告诉我如果几万 TCP 同时打进去，能进去的可能会只有几千个

https://github.com/dotnet/aspnetcore/blob/main/src/Servers/Kestrel/Transport.Sockets/src/SocketConnectionListener.cs#LL67C64-L67C64

@liuhan907 能用 ws 是我的梦想，一直在做梦，苦于设备目前只支持 TCP 接入
如果走 ws 就不需要专门开一种 TCP 服务端了，做好高可用使劲加 Web 服务器就成）

@liuhan907 #58
源代码看起来有点枯燥，倒是发现原来 core 内置的 K 服务还能处理自定义 TCP 这就有意思了，正好有个新的小规模项目可以走这条路整整😋

https://github.com/davidfowl/MultiProtocolAspNetCore/tree/master/KestrelTcpDemo

@liuhan907
那就简单来说说 (＾ o ＾)ﾉ

测试环境是 linux k8s 集群，所在节点 4 核 16G （后来加到了 8 核），非独占，还有一些其他东西跑，但不占太多 CPU

最开始的版本是图省事，嫌复杂懒得用 SocketAsyncEventArgs （ SAE ），监听开单线程阻塞，接收就用 Socket.Select 方法批量轮询，把筛出来的 Socket 滥用 Task.Run 处理接收和协议解析，可以想象线程池会有多窘迫，再多的 MinThread 也处理不过来，只会徒增 CPU 使用率。

单线程阻塞监听真是太天真了，大量 TCP 同时发起的时候根本 accept 不过来，后来改用 SAE 监听，一上来就安排 1024 个躺在端口前迎接，回调不直接处理，而是放进自己创建的工作线程排队创建应用层会话，加入会话管理器。这下几乎没有连不进去的了。

后来多几次改进调优就变成完全 SAE 了，监听和接收还有发送全都走 SAE ，只是 SAE 的回调依旧信不过，不在这里做过多的处理，而是自己开线程排队，也能观测一下队列数量来评估性能。

总算是稍微拯救了一下这难看的数据。

要问为什么自己撸 Socket 而不用现成框架，我不想回忆被 SuperSocket 折磨的那些年 _(:з)∠)_
辩解：协议单一，而且相对简单，可以自己来❌