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

Question

go.net/websocket包具有通过 Web 套接字发送Read()和Write()接收消息的功能。为什么它不返回用于发送和接收消息的通道？我觉得像websocket,这样的包net是使用 go 频道的完美场所。这个设计决策背后的原因是什么？

Answer 1

我不知道 WebSockets 的确切语义，但总的来说，我认为网络套接字不能很好地映射到通道中。实际上有一个 netchan 包试图在一般的频道上做到这一点，但它被停产了。

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

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

请注意，不使用通道不会使 API 非并发。只要连接是在单独的 goroutines 上处理的（它们就是 Go 的 HTTP 服务器），它们就会被同时处理。是否使用频道在这里只是方便的问题。