-
Notifications
You must be signed in to change notification settings - Fork 20
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
Should wasi-sockets have an opinion about broadcast? #63
Comments
Both broadcast and multicast require specialized socket options. None of which are currently specified or implemented, so implicitly they're unsupported. I agree it couldn't hurt to clarify this in the docs. |
Oh! That makes sense, then. Despite having used it before, I somehow imagined that it was all handled implicitly using special addresses. Now I'm not sure where I got that idea. Thanks for clarifying! |
Also, multicast?
I originally raised this question here: bytecodealliance/wasmtime#7148 (comment)
In brief, I'm wondering if it's intended for wasi-sockets to have any special knowledge of UDP broadcast, or if they should be handled implicitly the same way all other restrictions on target addresses are.
If the answer is "it's all just UDP, so we do what UDP does and don't add any weird extras to the API" then would it be worth explicitly drawing attention to this in the spec? E.g. "if in doubt about how this API will behave, assume it is the same as the corresponding behaviour in Berkley sockets" or something?
Thanks! 💖
P.S.: I don't have any strong opinion about this — even about documenting it. I just thought just in case it hadn't been discussed that might be worth raising.
The text was updated successfully, but these errors were encountered: