Skip to content

Commit f628749

Browse files
committed
Remove readLoop
Closes #93
1 parent d8e872c commit f628749

File tree

7 files changed

+103
-206
lines changed

7 files changed

+103
-206
lines changed

README.md

+4-10
Original file line numberDiff line numberDiff line change
@@ -123,24 +123,18 @@ it has to reinvent hooks for TLS and proxies and prevents support of HTTP/2.
123123
Some more advantages of nhooyr/websocket are that it supports concurrent writes and
124124
makes it very easy to close the connection with a status code and reason.
125125

126-
nhooyr/websocket also responds to pings, pongs and close frames in a separate goroutine so that
127-
your application doesn't always need to read from the connection unless it expects a data message.
128-
gorilla/websocket requires you to constantly read from the connection to respond to control frames
129-
even if you don't expect the peer to send any messages.
130-
131126
The ping API is also much nicer. gorilla/websocket requires registering a pong handler on the Conn
132127
which results in awkward control flow. With nhooyr/websocket you use the Ping method on the Conn
133128
that sends a ping and also waits for the pong.
134129

135130
In terms of performance, the differences depend on your application code. nhooyr/websocket
136131
reuses buffers efficiently out of the box if you use the wsjson and wspb subpackages whereas
137-
gorilla/websocket does not. As mentioned above, nhooyr/websocket also supports concurrent
132+
gorilla/websocket does not at all. As mentioned above, nhooyr/websocket also supports concurrent
138133
writers out of the box.
139134

140-
The only performance con to nhooyr/websocket is that uses two extra goroutines. One for
141-
reading pings, pongs and close frames async to application code and another to support
142-
context.Context cancellation. This costs 4 KB of memory which is cheap compared
143-
to the benefits.
135+
The only performance con to nhooyr/websocket is that uses one extra goroutine to support
136+
cancellation with context.Context and the net/http client side body upgrade.
137+
This costs 2 KB of memory which is cheap compared to simplicity benefits.
144138

145139
### x/net/websocket
146140

accept.go

-4
Original file line numberDiff line numberDiff line change
@@ -81,9 +81,6 @@ func verifyClientRequest(w http.ResponseWriter, r *http.Request) error {
8181
// Accept will reject the handshake if the Origin domain is not the same as the Host unless
8282
// the InsecureSkipVerify option is set. In other words, by default it does not allow
8383
// cross origin requests.
84-
//
85-
// The returned connection will be bound by r.Context(). Use conn.Context() to change
86-
// the bounding context.
8784
func Accept(w http.ResponseWriter, r *http.Request, opts AcceptOptions) (*Conn, error) {
8885
c, err := accept(w, r, opts)
8986
if err != nil {
@@ -143,7 +140,6 @@ func accept(w http.ResponseWriter, r *http.Request, opts AcceptOptions) (*Conn,
143140
closer: netConn,
144141
}
145142
c.init()
146-
c.Context(r.Context())
147143

148144
return c, nil
149145
}

limitedreader.go

+3-4
Original file line numberDiff line numberDiff line change
@@ -1,7 +1,6 @@
11
package websocket
22

33
import (
4-
"fmt"
54
"io"
65

76
"golang.org/x/xerrors"
@@ -20,9 +19,9 @@ func (lr *limitedReader) Read(p []byte) (int, error) {
2019
}
2120

2221
if lr.left <= 0 {
23-
msg := fmt.Sprintf("read limited at %v bytes", lr.limit)
24-
lr.c.Close(StatusPolicyViolation, msg)
25-
return 0, xerrors.Errorf(msg)
22+
err := xerrors.Errorf("read limited at %v bytes", lr.limit)
23+
lr.c.Close(StatusMessageTooBig, err.Error())
24+
return 0, err
2625
}
2726

2827
if int64(len(p)) > lr.left {

0 commit comments

Comments
 (0)