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

does support for socket(udp and tcp)? #1251

Closed
csy2002 opened this issue Nov 24, 2018 · 13 comments
Closed

does support for socket(udp and tcp)? #1251

csy2002 opened this issue Nov 24, 2018 · 13 comments

Comments

@csy2002
Copy link

csy2002 commented Nov 24, 2018

does support for socket(udp and tcp)? if not, has a plan? thanks.

@xtuc
Copy link

xtuc commented Nov 24, 2018

It can be archived by passing functions from the host.

@csy2002
Copy link
Author

csy2002 commented Nov 24, 2018

i want port my network program that use udp, but don't find appropriate functions.

@Pauan
Copy link

Pauan commented Nov 24, 2018

@csy2002 If you are using C or C++, you can try using Emscripten.

It compiles C/C++ programs to WebAssembly, and it provides WebAssembly wrappers for the C stdlib, the C++ stdlib, SDL, OpenGL, and more.

In many cases C/C++ programs just work with Emscripten, without any modifications.

@csy2002
Copy link
Author

csy2002 commented Nov 27, 2018

@Pauan thank you for your reply. my native code is using c or c++, and i want to using udp to transport media stream (video or audio data), but don't find the appropriate functions.
because some reasons, i can't use webrtc for media, so i justly finding another solution.

@Pauan
Copy link

Pauan commented Nov 29, 2018

@csy2002 I don't know C or C++, but my understanding is that Emscripten supports (basically) the entire C/C++ stdlib, so existing C/C++ functions should work just fine. So your existing code should work.

However, even though you can use existing C/C++ APIs, it will internally use WebSockets for the connection, so your server must accept WebSockets. And WebSockets are TCP only.

This is not a limitation in WebAssembly, it is a limitation in the web browser itself: the browser only allows you to use HTTP(S), WebSockets, or WebRTC. It has no support for raw sockets (UDP or TCP).

@Macil
Copy link

Macil commented Nov 29, 2018

If you're in a browser and you need the non-reliable communication of UDP, then your only standard option is to use WebRTC. WebRTC is usually for peer-to-peer connections between users, but you could make your server be a WebRTC "peer" so that the user opens a WebRTC connection to the server. This isn't well-established territory as far as I know though, so I don't know of any full examples of this to point anyone to. (PeerJS is a simple example of WebRTC data channels being used on the client-side.) Also, not all browsers (like Edge) support WebRTC data channels, so unless you're just using WebRTC's audio+video support, then you would need a WebSocket (TCP) fallback if you want to support those browsers.

@lsycxyj
Copy link

lsycxyj commented Sep 22, 2020

I think WebAssembly or even WebAPIs should support lower-layer protocols like TCP and UDP etc. Either WebRTC or WebSocket is an upper layer protocol, which has been wrapped with so many unecessary things and limitations. For example, we couldn't make QUIC connection polyfills or use customized TCP transmission control for some cases.

If the security should be concerned, some rules we could make. For example, we could make a preflight request for CORS policies.

@Mubelotix
Copy link

For example, we could make a preflight request for CORS policies.

Many public servers won't add support for these preflight requests. The absence of response could be treated as "there is no restriction on this server". But why don't we create a special permission? I don't think these kind of connections should be made without explicit user approval.

@lsycxyj
Copy link

lsycxyj commented Apr 16, 2021

Many public servers won't add support for these preflight requests. The absence of response could be treated as "there is no restriction on this server". But why don't we create a special permission? I don't think these kind of connections should be made without explicit user approval.

I don't think whether the public servers support preflight requests or not is the problem, since the security check is only done by client (eg. browser). If the public servers don't respond with correct preflight response, the client can block the subsequent invocations of the lower-level APIs.

@ondrejtomcik
Copy link

@Pauan any idea why this issue is not closed? Based on your comment

This is not a limitation in WebAssembly, it is a limitation in the web browser itself: the browser only allows you to use HTTP(S), WebSockets, or WebRTC. It has no support for raw sockets (UDP or TCP).

I don't think this will be ever supported. Any comments?

@Pauan
Copy link

Pauan commented May 12, 2021

@ondrejtomcik I'm not a part of the WebAssembly or W3C working groups, so I can't comment on that.

But in my personal opinion this feature should go into the browser itself, not Wasm, so it would be better to open a new issue with the W3C.

@ngzhian
Copy link
Member

ngzhian commented May 12, 2021

As mentioned above, if you are targeting the Web (via Emscripten), you likely have to port your networking logic to use WebSockets or try out WebTransport.

If you are targeting server environments, take a look at WASI, it is not implemented yet but there are feature requests (bytecodealliance/wasmtime#70).

This is not something that goes into WebAssembly itself: it is provided by the host/embedder.

@greyltc
Copy link

greyltc commented May 9, 2024

The direct-sockets API is now a thing: https://github.com/WICG/direct-sockets

Here's the specification: https://wicg.github.io/direct-sockets/

This isn't just a concept either, here's a working browser telnet client: https://github.com/googlechromelabs/telnet-client

Maybe this issue could be reopened/revisited.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

9 participants