-
Notifications
You must be signed in to change notification settings - Fork 29.8k
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
Adding Websocket support to core #19308
Comments
Re: Inspector.
|
i'm not wholly against this but i would like to factor in how much stuff we put into all our release binaries. if we can come up with more creative ways for shipping stuff like this i'm totally a +1 (#19307) |
I am still -1 on this. |
@mscdex can you be explicit in your reasoning? |
@devsnek for the same reasons I gave in the linked issue. |
As discussed in #1010 and as a maintainer of |
Since this original post we've added http2. While you listed a bunch of protocols not all of them are supported natively by the browser. https://developer.mozilla.org/en-US/docs/Web/API/WebSockets_API |
@MylesBorins I don't think node should aim to become a (DOM-less) browser. Anyway, my "vote" and reasoning still stands. |
It's more about communicating with browsers, not becoming one. |
http2 is an argument against being too eager to absorb protocols into core. Neither its API nor its implementation are all that great; it would have benefited from iterating outside core for a while. I guess you could construe that as an argument in favor of websockets: third-party modules have existed for years and their APIs and implementations have pretty much crystallized by now. |
This is a great idea. While today Node is already an indispensable tool for web developers it does not enjoy the same full seat at the table of web browser tech advancement despite being held completely captive by it. Few agree on the controversial edicts like Node has a big opportunity to become a full fledged user agent (web browser) and first class support for web features will be a part of that. +1! |
PRs welcome. Re: websockets I'm still -1 for the time being. This is something that has been done quite well by userland and there are still unanswered open standards questions about http2+ws that require more thought and experimentation. |
When http2 was added, I think one of the considerations were that we could do a lot of low level stuff in C++ land that was hard or even impossible(?) to do efficiently in user-land. Is there a similar reason for wanting to bring WS into core, or is it just to have more features? |
@jasnell can you point me towards the open standards discussion regarding h2 + ws? |
The ietf httpbis working group is working on this .... https://tools.ietf.org/html/draft-ietf-httpbis-h2-websockets-00 It's still super early in the process tho there is some early implementation happening. |
Ideally there should be a clear general framework on how to decide whether something belongs to the core or not. I would consider points like
|
@kof I fully agree with all your points except this one – there is no reason to believe that code in Node core is better-written or better-maintained than userland code in general. I think a better question in its place would be “Is it hard to do effeciently without native addons?”. |
@addaleax The idea behind that point is: if it is in userland, it is likely there will be multiple competing implementations, which will result in attention not being fully focused on a single code base and as a result lower quality, just because less people are working on it or using it. I have no data to back it up. Userland is good when a feature needs experimentation. |
No.
Yes it is.
Yes.
No.
Not necessarily but optimizations in core may help. In
Yes I think the community will benefit from WebSocket in core. There are a lot of userland implementations. The most popular are ws, faye-websocket, and websocket. Combining the the best parts of each one of them to create a single module in core would be great imho. |
+1, mainly because @lpinca has been doing a great job in maintaining |
pinging @jcoglan and @theturtle32 |
So far I haven't seen any concrete comments on why implementing WS in core would be better than having it in user-land. I'm sure @lpinca have done a great job maintaining I just think there need to be concrete examples on how core can provide a better WS implementation than user land 😃 |
i don't think there's anyone saying we would do a better job. i think the argument is better integration and since we can ship it with a native backing users will get a perf boost without having to install anything. |
@devsnek Could you provide an example of how the integration would be better if WS was in core? Regarding native backing then n-api and pre-compiled binaries should remove the requirement of having users compile stuff (if I understood your argument correctly). |
It seems the main argument for adding ws to Core is to reduce binary dependencies. Since both native dependencies are buffer-based, I think they may be good candidates for adoption of WebAssembly. @lpinca has that been seen as a possibility? |
For an API, I'd like to propose the WhatWG WebSocket API, as much as we can implement the standard (I know there will be some inconsistencies around events). If we run into any serious problems with the API design we can attempt to work with the whatwg to update the standard. It seems like @TimothyGu has participated in this document along with @domenic. re: http/2 + ws, if we get an implementation going we can participate in trying to solve this problem!
I think implementing standards in core, especially ones implemented in the webplatform, can help the ecosystem focus on creating better abstractions on top of a protocol like WS, and avoid having to implement the base protocol themselves. If the various ecosystem modules share a kernel it allows there to be collaboration across projects with a shared interest, and potentially brings more people to help maintain core itself. |
@watson userland implementations work and I'm a big supporter of small core but HTTP(s) and many other modules are in core because they are so popular that it made sense to create a core module for them. The same is valid for WebSocket in my opinion. Quoting @domenic from nodejs/NG#10 (comment)
Is core interested in supporting WebSocket? That's an open question. I think it should. @TimothyGu we didn't explore that possibility but that's definitely a good idea. We already have prebuilt and n-api based binaries for native addons. Removing binary dependencies is not the reason why I would like to see WebSocket in core though. The question is, why is HTTP and HTTP2 in core and WebSocket isn't? They all are in the same league and they all can live in userland if wanted. On top of that a good part of the WebSocket implementation is already in core as the upgrade mechanism is already available and supported in core. @MylesBorins If we ever decide to experiment with WebSocket in core, API need to be discussed. I think we want to support piping data around so a websocket should be implemented as a |
I can't establish a vote for this, although would be a nice to have. I found that WebSocket implementation isn't that solid neither in the Browser. Is high cpu consuming and so far I couldn't see any implementation in a big scale (which I would have guess they would be using it); eg: Facebook, Twitter and Gmail, they rather relay on polling. I guess is mainly related on the cost created on the Server side due being really hard to scale it (eg. Load balancing). Not sure Node wants to make his capacity in supporting it. |
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This thread is old and contains much history, so please forgive me if I miss anything. WebSocket is defined as RFC 6455. Everything else is API and implementation specific. To achieve complete inter-agent conformance in the most primitive way possible you only need to adhere to RFC 6455 which only includes Node's net (insecure sockets/servers) and tls libraries. Most Node WebSocket implementations execute as an HTTP upgrade. That is how the browser implements this, but that is not necessary. RFC 6455 provides no mention of HTTP except for specific plain text in a one time connection header. This means a WebSocket is merely a TLS or TCP raw socket with:
Required components, tasks essential to achieve RFC 6455 specific criteria:
The above list is all I have written in my own implementation to make this work with browsers and other Node instances. I need to review RFC 6455 and see what features I ignored as extraneous for my own needs, for example the connection security nonce is required by RFC 6455 (and implemented by the browsers) but is not necessary in practice. Also RFC 6455 requires that messages to be masked if sent from a client, but not if sent from a server. Browsers strongly adhere to this. I have found this otherwise to be entirely unnecessary as it only exists to isolate message traffic from interference and outside the browser role (client/server identity) becomes irrelevant after socket establishment. Nonetheless, this must exist by default to achieve RFC 6455 conformance and should be disabled via option. Nice to have list of optional features, things unique to WebSocket implementation but not required to achieve RFC 6455 transmission:
Everything else should be deferred to user land dependencies or other Node core libraries. There are some gotchas in writing the code that require playing with socket establishment and managing multiple sockets simultaneously. |
Proposal for a standards compliant client and server in less than 900 lines of code: #49478 |
Should this issue really be closed? We still do not have a WebSocket server in Node.js core. |
What's the way forward here? Unlike client WS, there's no WS server standard to follow. Before anyone suggests copying commercial cloud vendors' proprietary APIs: no. Just no. |
Nearly everyone uses ws at the moment, no? Pave the cow paths? :)
Aral
…On Fri, Oct 13, 2023, at 10:25 AM, Ben Noordhuis wrote:
What's the way forward here? Unlike client WS, there's no WS server standard to follow.
Before anyone suggests copying commercial cloud vendors' proprietary APIs: no. Just no.
—
Reply to this email directly, view it on GitHub <#19308 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAKGRQATENGA7DXYKPIFBDX7ECJLANCNFSM4EU7UOJQ>.
You are receiving this because you were mentioned.Message ID: ***@***.***>
|
There are others, but yes, |
Ultimately I don't see a reason to have a server implementation, |
Performance, maybe? I like |
eh, I like having |
I have an app currently using WebSocket client from ws. |
That is expected. The ask is to support We might add additional options in the future, but the goal is spec compatibility on first instance. |
Shouldn't this been solved by #49830? |
Closed by #49830 |
The original thread where adding this was discussed #1010 was closed with a decision by the iojs TC to rather implement lower level buffer methods, but that was abandoned.
There is an open EPS to add the feature, but we have since abandoned the process.
Some of the people who originally were -1 changed their opinions in #1010 more recently. In fact, we already ship a partial implementation of ws in the inspector.
I think it might be worth us revisiting adding WS to core.
/cc @eugeneo @rauchg
The text was updated successfully, but these errors were encountered: