 |
kuanatV2EX 第 634702 号会员，加入于 2023-06-19 11:38:40 +08:00今日活跃度排名 1319 |
| V2EX 是否会考虑增加专栏功能？ V2EX • kuanat • 26 天前 • 最后回复来自 kuanat | 5 |
| 分享一些 Go 在全栈开发中的经验
11 Go 编程语言 • kuanat • 4 天前 • 最后回复来自 kuanat
|
41 |
kuanat 最近回复了
13 小时 51 分钟前 回复了 qinconquer 创建的主题 › 程序员 › app 软件中的热门榜单怎么做的呢 |
榜单如果只有 10~20 个这样，更新频率不高的话，建议人工。
程序只负责筛选出一定量的备选。
程序只负责筛选出一定量的备选。
3 天前 回复了 fu82581983 创建的主题 › Kotlin › Kotlin 2.0.0 正式版发布了 |
@Jirajine #34
官方早就说过不想做 LSP 了，之前我试了一段时间那个第三方做的 LSP ，差得还是有点远。所以我说希望 LSP 跟 IDE 能跟上，达到八成水平，支持我用 neovim/VS Code + LSP 就很满意了。这个事情上有得选是第一步。
官方早就说过不想做 LSP 了，之前我试了一段时间那个第三方做的 LSP ，差得还是有点远。所以我说希望 LSP 跟 IDE 能跟上，达到八成水平，支持我用 neovim/VS Code + LSP 就很满意了。这个事情上有得选是第一步。
3 天前 回复了 busterian 创建的主题 › Android › app 反布局分析调试如何绕过 |
爆破思路的话，跳转无障碍应该是 startActivity(Intent) 的形式，把它拦截了。也有可能是带 Result 的版本，一起把 onResult 也拦截了。
正向思路的话，我不知道 dump activity 相关的 API 是什么，当然应用也不可能监听 API 的调用。只是这个 API 调用会有副作用，应用程序可以检测某个事件或者相关的状态变化来做出页面跳转的行为。
这就需要你逆向看下代码或者动态跟踪一下，目标程序可以利用的方式太多了。
正向思路的话，我不知道 dump activity 相关的 API 是什么，当然应用也不可能监听 API 的调用。只是这个 API 调用会有副作用，应用程序可以检测某个事件或者相关的状态变化来做出页面跳转的行为。
这就需要你逆向看下代码或者动态跟踪一下，目标程序可以利用的方式太多了。
3 天前 回复了 fu82581983 创建的主题 › Kotlin › Kotlin 2.0.0 正式版发布了 |
写 Kotlin 可比写 Java 爽太多了，等 LSP 和 IDE 跟上，体验还会更好。
4 天前 回复了 easychen 创建的主题 › 分享创造 › 为了自动化写了很多脚本，却总是边用边丢，所以我写了一个脚本管理工具 https://juejin.cn/post/7369211590363430923 |
@easychen #45
我之前的思路局限在脚本和工作流都是人在写之上，如果把视野展开，让 AI 来做胶水类型的工作（这本来也是语言模型的强项），现在就具备可用性了。
我也有尝试用 AI 来辅助生成功能性脚本，目前遇到的主要问题是没有很好的验证机制，很多时候需要人参与代码审计。另外目前基于提示词的运作方式接近于声明式编程，生成代码的实现方式比较不可控，更增加了人工判断的成本。
我之前的思路局限在脚本和工作流都是人在写之上，如果把视野展开，让 AI 来做胶水类型的工作（这本来也是语言模型的强项），现在就具备可用性了。
我也有尝试用 AI 来辅助生成功能性脚本，目前遇到的主要问题是没有很好的验证机制，很多时候需要人参与代码审计。另外目前基于提示词的运作方式接近于声明式编程，生成代码的实现方式比较不可控，更增加了人工判断的成本。
5 天前 回复了 meshell 创建的主题 › 程序员 › 有深入研究的 golang websocket 的大佬吗？遇到一个 30 秒自动断开的问题？ |
@meshell #24
继续往下查吧，wh.srv 可能做了些什么操作。随便猜一下，可能是某个 context 有 30s 的设置，超时之后直接在 http 层面触发了 defer Close() 之类的操作，这个操作完成了 tcp 层面 FIN/ACK 的关闭，结果导致 ws 层面是没有 opClose 消息的。
我看了一下 gobwas/ws 的代码，UpgradeHTTP 这里就把 net.Conn 的 deadline 给清除了（设置了 time.Time 的零值）。（既然是无超时，理论上每次读 message 的时候 err := conn.SetReadDeadline(time.Time{}) 这个重置就没有必要了，不过与你的问题无关）
继续往下查吧，wh.srv 可能做了些什么操作。随便猜一下，可能是某个 context 有 30s 的设置，超时之后直接在 http 层面触发了 defer Close() 之类的操作，这个操作完成了 tcp 层面 FIN/ACK 的关闭，结果导致 ws 层面是没有 opClose 消息的。
我看了一下 gobwas/ws 的代码，UpgradeHTTP 这里就把 net.Conn 的 deadline 给清除了（设置了 time.Time 的零值）。（既然是无超时，理论上每次读 message 的时候 err := conn.SetReadDeadline(time.Time{}) 这个重置就没有必要了，不过与你的问题无关）
5 天前 回复了 meshell 创建的主题 › 程序员 › 有深入研究的 golang websocket 的大佬吗？遇到一个 30 秒自动断开的问题？ |
@meshell #17
你给的截图里，最后一次客户端 ACK 确认服务端 Pong 之后，服务端主动发送 FIN ，说明断开是服务端的行为。
这个断开没有 opClose ，说明不是你的程序、也不是 ws 库的行为。
因为你是本地测试，也不会涉及防火墙。
由于 Ping/Pong 的间隔是 2s ，有双向通信，说明不是 Idle 相关的超时。也就是说，并不是 KeepAlive 等机制触发的先断开底层，再断开上层。
整个协议层面，在 ws 之下，还有（大概率）标准库 net/http ，再下层就是系统的 tcp socket 了。
我记忆中标准库 DefaultTransport 有个 30s 超时，查了一下 https://go.dev/src/net/http/transport.go 确实有，但是应该与你的问题无关。
正好你说你用的不是 http.client ，可以贴一下最小可复现的完整代码。因为之前的代码看不到 conn 的来源，可能是有哪个地方设置了超时参数。
你给的截图里，最后一次客户端 ACK 确认服务端 Pong 之后，服务端主动发送 FIN ，说明断开是服务端的行为。
这个断开没有 opClose ，说明不是你的程序、也不是 ws 库的行为。
因为你是本地测试，也不会涉及防火墙。
由于 Ping/Pong 的间隔是 2s ，有双向通信，说明不是 Idle 相关的超时。也就是说，并不是 KeepAlive 等机制触发的先断开底层，再断开上层。
整个协议层面，在 ws 之下，还有（大概率）标准库 net/http ，再下层就是系统的 tcp socket 了。
我记忆中标准库 DefaultTransport 有个 30s 超时，查了一下 https://go.dev/src/net/http/transport.go 确实有，但是应该与你的问题无关。
正好你说你用的不是 http.client ，可以贴一下最小可复现的完整代码。因为之前的代码看不到 conn 的来源，可能是有哪个地方设置了超时参数。
Select Language