CODEWITHSUNDEEP
concurrencywebsocketgo
Oguz Bilgic
Oguz Bilgic

Reputation: 3480

Why does not go.net/websocket'api use channels for sending and receiving messages?

go.net/websocket package has Read() and Write() functions for sending and receiving messages through the web socket. Why does not it instead return a channel for sending and receiving messages? I feel like packages such as websocket, net are perfect places to use go's channels. What is the reasoning behind this design decision?

Upvotes: 1

Views: 163

Answers (1)

justinas
justinas

Reputation: 6867

I don't know the exact semantics of WebSockets, but in general, I don't think network sockets map well into channels. There was actually a netchan package that tried to did this with channels in general, but it was discontinued.

I think there many problems to try and support a whole lot of protocols with one channel implementation. Where does the message begin and end? Should the channel buffer a large message, or give it chunk by chunk, etc.? The semantics of each protocol differ too much, so Go gives you the lower-level Read/Write for sockets, just like you'd find in other languages and leaves it for you to decide how to handle the data.

Note that I'm talking about socket-channels in general. WebSocket is a well-defined protocol and an implementation using channels might work well for it. As for why channels weren't chosen, it would be best to ask the authors of go.net/websocket (try golang-nuts Google group). I think it makes sense in a way, as its API as it is now is similar to the regular Go socket API.

Note that not using channels does not make the API non-concurrent. As long as connections are being handled on separate goroutines (which they are, with Go's HTTP server), they'll be handled concurrently. Using a channel or not is just a matter of convenience here.

Upvotes: 2

Related Questions