You're absolutely right. Disregard my comment. On Wednesday, September 18, 2019 at 1:10:38 PM UTC-4, Jochen Voss wrote: > > Dear Ilia, > > Thank you for your comment. In my mind, Read and Write are made for > streaming data, whereas a websocket connection transports messages. How > would I handle message types and message boundaries when using the > io.Reader and io.Writer interfaces? (I do try to implement these > interfaces for the *contents* of the messages themselves, see my > SendMessage and ReceiveMessage functions.) > > Many thanks, > Jochen > > On Wednesday, 18 September 2019 14:37:49 UTC+1, Ilia Choly wrote: >> >> You should try to make Conn implement io.Reader and io.Writer >> >> On Tuesday, September 17, 2019 at 6:29:08 PM UTC-4, Jochen Voss wrote: >>> >>> Dear all, >>> >>> Because I wanted to learn about the websocket protocol, I have >>> implemented a websocket server in Go: >>> >>> code: https://github.com/seehuhn/go-websocket >>> documentation: https://godoc.org/seehuhn.de/go/websocket >>> >>> I would be happy to receive feedback about my code. >>> >>> Specific questions: >>> >>> - Does the API look reasonable? Anything to improve? >>> >>> - I use the function readMultiplexer (at the end of reader.go) to read >>> all frame headers from the network connection, and to make sure that the >>> readers of the frame bodies don't step on each other's feet. Similarly, >>> the function writeMultiplexer (at the end of writer.go) coordinates all >>> writers and performs all writes to the network connection. This system is >>> held together by a tangle of go channels. The code is much messier than I >>> would like it to be. Is there a way to structure such code so that it >>> is easier to reason about, so that I can be more confident that it is >>> correct? The bits a struggled most with are the various ways the >>> connection can be closed (closed by server explicitly or because of a >>> protocol error, closed by client with/without close frame). >>> >>> - I attempted to profile the code, to find whether there are any >>> performance bottlenecks. My code for this is in websocket_test.go >>> (function BenchmarkEcho), but the profiles then only ever show the code >>> waiting for data on go channels or for data from the network. My feeling >>> is that I was really benchmarking the network connection and not my code. >>> Is there a way to improve BenchmarkEcho to get more meaningful results? >>> >>> Many thanks, >>> Jochen >>> >>>
-- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/f03c246f-89c3-4400-8d9e-7912738359f9%40googlegroups.com.
