Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

x/net/websocket: remedy neglect; merge with gorilla websocket? #18152

Open
zombiezen opened this issue Dec 1, 2016 · 56 comments
Open

x/net/websocket: remedy neglect; merge with gorilla websocket? #18152

zombiezen opened this issue Dec 1, 2016 · 56 comments
Labels
Milestone

Comments

@zombiezen
Copy link
Contributor

@zombiezen zombiezen commented Dec 1, 2016

It is not well maintained, and essentially everyone uses https://github.com/gorilla/websocket.

This was raised as a concern in #17244: because it is in the x/net repository, people attach greater value to it than it really ought to have.

/cc @dsnet

EDIT 2016-12-02: Copying in my better-phrased problem statement from later in the thread:

The problem I see is that the ownership/maintenance story of x/net/websocket is unclear. It may suit your needs, and that is fine! However, it's not getting the same level of support as the standard library or even gorilla/websocket; it has no established owner AFAIK.

Along the lines of #17244, there is concern that it elevates the status and visibility of the package. I've anecdotally heard of it confusing many new users whose needs were much better filled with gorilla/websocket. I have not heard of someone using gorilla/websocket and then deciding to use x/net/websocket instead.

@zombiezen zombiezen added the Proposal label Dec 1, 2016
@bradfitz
Copy link
Contributor

@bradfitz bradfitz commented Dec 1, 2016

We can't just delete something and break people who aren't vendoring it.

We can document that it's deprecated perhaps.

Or somebody could maintain it.

@bradfitz bradfitz added this to the Proposal milestone Dec 1, 2016
@zombiezen
Copy link
Contributor Author

@zombiezen zombiezen commented Dec 1, 2016

Deprecated might be fine, but my experience is that I (and other devs I've talked to) have wasted time trying to use the package only to find out it fails in production and that Gorilla's package works.

@dsnet
Copy link
Member

@dsnet dsnet commented Dec 1, 2016

I support a strong deprecation message. Would that message endorse the Gorilla implementation?

If we implement golang/lint#238, I think that will help people avoid wasting time developing with deprecated packages or features.

@bradfitz
Copy link
Contributor

@bradfitz bradfitz commented Dec 1, 2016

"fails in production" -- what are the open bugs? There's not much to WebSockets. I'm afraid we're going to spend more time discussing things on this bug than we would just fixing any such issues.

@cespare
Copy link
Contributor

@cespare cespare commented Dec 1, 2016

Beyond any bugs that could be fixed by maintenance, the deeper problem with x/net/websocket is that it has the wrong API. It puts an io.Reader/Writer interface on top of what is fundamentally a message-based protocol.

I agree it should be documented as deprecated in favor of gorilla/websocket.

@zombiezen
Copy link
Contributor Author

@zombiezen zombiezen commented Dec 1, 2016

It's been long enough since I last tried to use it, but off-hand, you cannot implement a correct websocket reverse proxy with the current API, since it tries to implement io.Reader/io.Writer. Websocket, for better or for worse, is a frame-oriented protocol, not a stream-oriented protocol.

@bradfitz
Copy link
Contributor

@bradfitz bradfitz commented Dec 1, 2016

I agree it has the wrong API. But we could add ReadMessage and WriteMessage to it and deprecate Read and Write.

I am in favor of maintaining less code, though, (not that we ever maintained x/net/websocket much?), and I have no personal or sentimental connection to x/net/websocket, and we actually use gorilla/websocket in Camlistore these days, but it still feels core enough that we should have an official answer for websockets in x/net.

I suppose this all kinda depends on the policy for x/* we figure out in #17244.

@davecheney
Copy link
Contributor

@davecheney davecheney commented Dec 1, 2016

@cznic
Copy link
Contributor

@cznic cznic commented Dec 1, 2016

Please do not deprecate it. At work, we are using golang.org/x/net/websocket exclusively and we have never had any problem with it*. Quite the opposite, in our use case it's more robust than what we've ever expected.

*: Of course, that says nothing whatsoever about any trouble anyone else might have with it.

@bradfitz
Copy link
Contributor

@bradfitz bradfitz commented Dec 1, 2016

@cznic, "deprecate" does not mean "delete".

@cznic
Copy link
Contributor

@cznic cznic commented Dec 1, 2016

Yep. But I guess it means "no more bug fixes for you, ever".

@bradfitz
Copy link
Contributor

@bradfitz bradfitz commented Dec 1, 2016

No, not really. Deprecated is not black & white. We continue to fix bugs in other deprecated stuff when there's a good bug report and a clear fix and super minimal risk of breaking existing users. It just means we're not adding features to it, or means that a better way is known to exist.

@cznic
Copy link
Contributor

@cznic cznic commented Dec 1, 2016

Great news, honestly. But then again, why to mark it deprecated in the first place? We can cope with it getting no attention from people not loving it, but we do and if we run into a bug we need to resolve, we would be more than happy to contribute the fix.

Status quo anybody?

@bradfitz
Copy link
Contributor

@bradfitz bradfitz commented Dec 1, 2016

But then again, why to mark it deprecated in the first place?

To tell users they might be happier elsewhere.

@zombiezen
Copy link
Contributor Author

@zombiezen zombiezen commented Dec 2, 2016

Precisely to @bradfitz's point: Deleting may be too strong, but I want to send a strong signal that there's a much better maintenance story for gorilla/websocket. Effort spent on x/net/websocket may be better spent on gorilla/websocket.

@gopherbot
Copy link

@gopherbot gopherbot commented Dec 2, 2016

CL https://golang.org/cl/33806 mentions this issue.

gopherbot pushed a commit to golang/net that referenced this issue Dec 2, 2016
Updates golang/go#18152

Change-Id: Ia3df3f9668847690e60a2af0680cf1bd66042384
Reviewed-on: https://go-review.googlesource.com/33806
Reviewed-by: Ross Light <light@google.com>
@cznic
Copy link
Contributor

@cznic cznic commented Dec 2, 2016

To tell users they might be happier elsewhere.

I really really really don't want to sound snarky, but by that logic, the Go repository might be marked deprecated as well - just because users might be happier with Rust, C, Java, ...?

Effort spent on x/net/websocket may be better spent on gorilla/websocket.

I have no intention, nor desire to suggest or propose, regardless how impossible and foolish that would be, to delete github.com/gorilla/websocket, just because we don't and probably never would use it.

@bradfitz
Copy link
Contributor

@bradfitz bradfitz commented Dec 2, 2016

I really really really don't want to sound snarky,

Yet you did. And it's not very productive. It's actually just noise in this thread.

If you want to be productive, though, step up and maintain golang.org/x/net/websocket. That's one of the options I listed in my first comment (#18152 (comment))

@zombiezen
Copy link
Contributor Author

@zombiezen zombiezen commented Dec 2, 2016

I apologize, @cznic. The current proposal process biases bug titles to be action-based (do X) versus focused on problem statement, so I should have described the problem instead of a proposed plan of action. Maybe this is something we should consider improving in the proposal process.

The problem I see is that the ownership/maintenance story of x/net/websocket is unclear. It may suit your needs, and that is fine! However, it's not getting the same level of support as the standard library or even gorilla/websocket; it has no established owner AFAIK.

The other issue I see is along the lines of #17244, where there is concern that it elevates the status and visibility of the package. I've anecdotally heard of it confusing many new users whose needs were much better filled with gorilla/websocket. I have not heard of someone using gorilla/websocket and then deciding to use x/net/websocket instead.

@bradfitz
Copy link
Contributor

@bradfitz bradfitz commented Dec 2, 2016

And to be clear, @cznic, I'm quite serious about you maintaining x/net/websocket. As a user of it, you're better suited to be a maintainer of it than a random contributor looking for work to do. And you maintain enough other stuff that you know what the process entails.

@cznic
Copy link
Contributor

@cznic cznic commented Dec 2, 2016

It's actually just noise in this thread.

I respectfully disagree. I see no proof why it's different (wrt people happier with something else). I'm ready to acknowledge you're right if you can actually explain your judgement in some other way than simply claiming my point has no point (just noise in your words).

Nonetheless...

If you want to be productive, though, step up and maintain golang.org/x/net/websocket.

And to be clear, @cznic, I'm quite serious about you maintaining x/net/websocket. As a user of it, you're better suited to be a maintainer of it than a random contributor looking for work to do. And you maintain enough other stuff that you know what the process entails.

Regardless of us (at work) never having a problem with it, how do you expect me to maintain x/net/websocket? Serious question from a person having only R/O access to it.

I apologize, @cznic. ...

@zombiezen Relly appreciated, but there's nothing to apologize for. I don't agree with the proposal, but that's nothing personal. If I made an impression otherwise then it's my duty to apologize for my fault - sorry.


PS: @ALL Getting the company's approval to use Go and/or code from golang.org/whatever is one thing. The same for code from other domains is not the same.

@bradfitz
Copy link
Contributor

@bradfitz bradfitz commented Dec 2, 2016

Regardless of us (at work) never having a problem with it, how do you expect me to maintain x/net/websocket? Serious question from a person having only R/O access to it.

If you send us CLs, we'll +2 and you can submit.
If others send you CLs, we'll give you access to +2 their CLs and you can submit.

@bradfitz
Copy link
Contributor

@bradfitz bradfitz commented Dec 2, 2016

I respectfully disagree. I see no proof why it's different (wrt people happier with something else). I'm ready to acknowledge you're right if you can actually explain your judgement in some other way than simply claiming my point has no point (just noise in your words).

I find your comparison between recommending a maintained package and recommending a whole alternate language not even remotely equivalent. They're pretty absurdly different. You also found it ridiculous, which is why you prefaced it with "I really really really don't want to sound snarky". You can't just say something outlandish and preface it with "Not to be $X or anything, but ....".

By the time most people are selecting a websocket package, they've already selected their programming language (Go, in this case). On the off chance they haven't yet selected their programming language (say, they're writing a prototype application to decide whether they like the Go ecosystem), that argues even more in favor of @zombiezen's point that we should point them to the solution that's going to be make them happy, rather than the first thing they stumbled into.

Hence https://golang.org/cl/33806

@groob
Copy link
Contributor

@groob groob commented Dec 2, 2016

Thank you Brad,

Not to add noise to the issue, but we've recently had to introduce websockets to our app and had this debate do research to find out wether x/net/websocket would work. Luckily I was aware of discussion in #17244 which mentions websocket vs the gorilla package. The mention will help others save time and avoid using something just because it looks official.

@cznic
Copy link
Contributor

@cznic cznic commented Dec 2, 2016

If others send you CLs, we'll give you access to +2 their CLs and you can submit.

Let's roll.

@leaxoy
Copy link

@leaxoy leaxoy commented Dec 2, 2016

But how about implement it in standard package net/websocket?

@bradfitz
Copy link
Contributor

@bradfitz bradfitz commented Dec 2, 2016

@leaxoy, no thanks. Unmaintained code in x/ is bad enough. We don't also want more code in std, especially if it's unmaintained. See https://golang.org/doc/faq#x_in_std

@Inuart
Copy link

@Inuart Inuart commented Sep 28, 2017

any updates?

@garyburd
Copy link
Contributor

@garyburd garyburd commented Sep 28, 2017

There's agreement about moving the package, but I don't have time to do the work.

@pciet
Copy link
Contributor

@pciet pciet commented Dec 25, 2017

Google Cloud Platform has a beta websocket API: https://issuetracker.google.com/issues/35886348

Despite lack of maintainers I'd still like to reopen the idea of a standard library package net/websocket for Go 2.

@ivoras
Copy link

@ivoras ivoras commented Feb 14, 2018

I think I may be encountering this error when using Gorilla's websockets, which apparently isn't present in this implementation: gorilla/websocket#43 .

I have a WebSocket server, with two goroutines per connection: one reading messages and pushing them to a channel, and the other pulling them from the channel, processing them and writing the results to the connection. So far, it looks like at semi-random points I get spurious "unexpected EOF" messages on the Gorilla implementation. I yet need to try Google's.

@binary132
Copy link

@binary132 binary132 commented Apr 30, 2018

Looks like Gorilla's ws implementation needs a maintainer.

gorilla/websocket#370

@nhooyr
Copy link
Contributor

@nhooyr nhooyr commented Sep 22, 2018

@garyburd regarding your comment above

The most important change is to restructure the API to allow for concurrent writers.

Why is that important and what would this sort of API look like?

@nhooyr
Copy link
Contributor

@nhooyr nhooyr commented Mar 30, 2019

I started working on a new WebSocket library for Go.

The main features being a minimal easy to use API that will work with WebSockets over HTTP/2.

https://github.com/nhooyr/websocket#websocket

Right now the entire implementation is stubbed out as I wanted to get some feedback on the API.

@jech
Copy link

@jech jech commented Mar 30, 2019

@jech
Copy link

@jech jech commented Mar 30, 2019

@nhooyr
Copy link
Contributor

@nhooyr nhooyr commented Apr 7, 2019

I just tagged v0.1.0, it passes all of the autobahn tests except for compression which I'll add later.

https://github.com/nhooyr/websocket

Let me know what you think.

edit: Have tagged v1.0.0 now 🎊

@nhooyr
Copy link
Contributor

@nhooyr nhooyr commented Sep 21, 2019

I opened a PR to add my library to the deprecation message as well. golang/net#51

Should we make the deprecation message stronger as discussed in #33215?

It seems to actively have issues with pings as described by @fjl at ethereum/go-ethereum#19798 (comment)

The issue here isn't that github.com/x/net/websocket doesn't handle ping (it does). We are seeing the reproducer behave this way because SetWriteDeadline interacts badly with the built-in ping frame handler. Whenever the RPC client wants to write something, it sets a write deadline. In the reproducer it only writes once to establish the subscription. When the ping frame arrives 12 seconds after the write, the write deadline that's set has already passed and writing the pong frame fails. The pong write error is returned from Read, causing the client to reconnect.

I looked over the code and confirmed this is an issue. The ping handling code never resets the write deadline and instead relies on the user of the Conn to reset the deadline to zero after reading which is definitely confusing behaviour. I suppose this could be fixed pretty easily but people ought to just use gorilla or mine. Mine also has a net.Conn wrapper to make such a transition easier. I'll add this to the deprecation message.

gopherbot pushed a commit to golang/net that referenced this issue Sep 21, 2019
 My library is a well maintained alternative as well and is easier to transition to thanks to the [NetConn](https://godoc.org/nhooyr.io/websocket#NetConn) wrapper.

Updates golang/go#18152

Change-Id: Iff9addebcee4f39dbd9f015d0fbe7613e4ee45dd
GitHub-Last-Rev: 0ae267b
GitHub-Pull-Request: #51
Reviewed-on: https://go-review.googlesource.com/c/net/+/193217
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
@golang golang deleted a comment from hadv Jan 6, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
You can’t perform that action at this time.