coder / coder/websocket

Document how to have read timeout be larger than idle timeout

未关闭
#425 3 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看
docs
主要语言
Go
星标
5.5k
派生
372
PR 合并指标
30 天内没有已合并 PR

描述

Hi! Thanks for this excellent library.

I have a use case where I want the server to wait up to 10 seconds for the client to start sending data. If the server doesn't get a new Reader within that time, it closes the connection and bails.

However, if the client *does* start sending data, then they have a much longer time limit to finish sending. Say 2 minutes. As far as I can tell, there's not a good way to accomplish this with the current API design.

I saw this issue: https://github.com/nhooyr/websocket/issues/87

Which works IFF the idle timeout is larger than the read timeout.

This is because the `Conn.msgReader` holds on to the context passed in during `Reader()` Example:

```
ctx, cancel := context.WithTimeout(rootCtx, 10 *second)
defer cancel()

_, reader, err := ws.Reader(ctx)
if err != nil {
// Err handling....
log.Error(err)
return
}

// If reading data takes longer than 10 seconds, the timeout above will fire, and the context will be cancelled
// Killing the connnection
data, err := io.ReadAll(reader)
if err != nil {
// Err handling....
log.Error(err)
return
}
```

I can potentially work around this. Instead of using `context.WithTimeout`, I could just use `context.WithCancel`. Then have a `time.AfterFunc()`, which uses atomics to check if we got the reader already. In which case, don't cancel. Example:

```
ctx, cancel := context.WithCancel(rootCtx)
defer cancel()

gotReader := atomic.Bool{}

time.AfterFunc(10*time.Second, func() {
if !gotReader.Load() {
cancel()
}
})

_, reader, err := ws.Reader(ctx)
if err != nil {
// Err handling....
log.Error(err)
return
}
gotReader.Store(true)

time.AfterFunc(2*time.Minute, func() {
cancel()
})

data, err := io.ReadAll(reader)
if err != nil {
// Err handling....
log.Error(err)
return
}
```

I'm not sure what the best way to modify the API would be. You're unfortunately stuck with the io.Reader interface, without the ability to add a context. Thoughts?

贡献指南

这个仓库没有索引到贡献指南

调研方向

Start by reading the Reader entry point and Conn.msgReader, then review the linked issue 87 and the context behavior shown in the examples. Determine whether the current API can support separate time limits for obtaining a Reader and finishing a read, and document the supported approach or the required API design change.

由索引模型根据 Issue 内容生成。

评估

技术栈
go
领域
api, networking
Issue 类型
功能
难度
5/5
预计耗时
一周以上
活跃度
停滞
描述清晰度
需要澄清
新手友好度
20/100

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。