concurrency - 为什么 go.net/websocket'api 不使用 channel 来发送和接收消息？

Question

go.net/websocket 包中有 Read() 和 Write() 函数，用于通过网络套接字发送和接收消息。为什么它不返回一个用于发送和接收消息的 channel ？我觉得像 websocket、net 这样的包是使用 go channel 的完美场所。这个设计决定背后的原因是什么？

Answer 1

我不知道 WebSocket 的确切语义，但总的来说，我认为网络套接字不能很好地映射到 channel 中。 There was actually a netchan package试图通过一般 channel 做到这一点，但已停止。

我认为尝试通过一个 channel 实现支持大量协议(protocol)存在很多问题。消息从哪里开始和结束？ channel 应该缓冲一条大消息，还是逐 block 给它等等？每个协议(protocol)的语义差异太大，因此 Go 为您提供了较低级别的套接字读/写，就像您在其他语言中找到的一样，并留给您决定如何处理数据。

请注意，我说的是一般的套接字 channel 。 WebSocket 是一个定义明确的协议(protocol)，使用 channel 的实现可能适用于它。至于为什么没有选择 channel ，最好问一下go.net/websocket的作者(试试golang-nuts谷歌群)。我认为它在某种程度上是有道理的，因为它现在的 API 类似于常规的 Go 套接字 API。

请注意，不使用 channel 不会使 API 成为非并发的。只要连接在单独的 goroutines 上处理(它们是 Go 的 HTTP 服务器)，它们就会被并发处理。使用或不使用 channel 只是这里方便的问题。