Design: oferece suporte para socket (udp e tcp)?

Ele pode ser arquivado passando funções do host.

Eu quero portar meu programa de rede que usa udp, mas não encontro as funções apropriadas.

@ csy2002 Se estiver usando C ou C ++, você pode tentar usar Emscripten .

Ele compila programas C / C ++ para WebAssembly e fornece wrappers WebAssembly para C stdlib, C ++ stdlib, SDL, OpenGL e muito mais.

Em muitos casos, os programas C / C ++ funcionam apenas com o Emscripten, sem nenhuma modificação.

@Pauan obrigado pela sua resposta. meu código nativo está usando c ou c ++ e eu quero usar udp para transportar fluxo de mídia (dados de vídeo ou áudio), mas não encontro as funções apropriadas.
porque alguns motivos, eu não posso usar webrtc para mídia, então eu justamente encontrando outra solução.

@ csy2002 Não sei C ou C ++, mas meu entendimento é que o Emscripten suporta (basicamente) todo o stdlib C / C ++, então as funções C / C ++ existentes devem funcionar bem. Portanto, seu código existente deve funcionar.

No entanto, embora você possa usar APIs C / C ++ existentes, ele usará internamente WebSockets para a conexão , portanto, seu servidor deve aceitar WebSockets. E os WebSockets são apenas TCP.

Isso não é uma limitação no WebAssembly, é uma limitação no próprio navegador da web: o navegador só permite que você use HTTP (S), WebSockets ou WebRTC . Não tem suporte para sockets raw (UDP ou TCP).

Se você estiver em um navegador e precisar da comunicação não confiável do UDP, sua única opção padrão é usar o WebRTC. O WebRTC é geralmente para conexões ponto a ponto entre usuários, mas você pode fazer seu servidor ser um "ponto" WebRTC para que o usuário abra uma conexão WebRTC com o servidor. Este não é um território bem estabelecido até onde eu sei, então eu não conheço nenhum exemplo completo disso para apontar alguém. ( PeerJS é um exemplo simples de canais de dados WebRTC sendo usados ​​no lado do cliente.) Além disso, nem todos os navegadores (como o Edge) oferecem suporte a canais de dados WebRTC, então, a menos que você esteja usando apenas o suporte de áudio + vídeo de WebRTC, você precisará um fallback WebSocket (TCP) se desejar oferecer suporte a esses navegadores.

Acho que WebAssembly ou mesmo WebAPIs devem oferecer suporte a protocolos de camada inferior, como TCP e UDP, etc. O WebRTC ou WebSocket é um protocolo de camada superior, que foi embrulhado com tantas coisas desnecessárias e limitações. Por exemplo, não poderíamos fazer polyfills de conexão QUIC ou usar controle de transmissão TCP personalizado em alguns casos.

Se a segurança for preocupada, algumas regras poderíamos fazer. Por exemplo, poderíamos fazer uma solicitação de comprovação para políticas CORS.

Por exemplo, poderíamos fazer uma solicitação de comprovação para políticas CORS.

Muitos servidores públicos não adicionarão suporte para essas solicitações de comprovação. A ausência de resposta pode ser tratada como "não há restrição neste servidor". Mas por que não criamos uma permissão especial? Não acho que esse tipo de conexão deva ser feito sem a aprovação explícita do usuário.

Muitos servidores públicos não adicionarão suporte para essas solicitações de comprovação. A ausência de resposta pode ser tratada como "não há restrição neste servidor". Mas por que não criamos uma permissão especial? Não acho que esse tipo de conexão deva ser feito sem a aprovação explícita do usuário.

Não acho que o problema seja se os servidores públicos oferecem suporte a solicitações de comprovação, já que a verificação de segurança é feita apenas pelo cliente (por exemplo, navegador). Se os servidores públicos não responderem com a resposta de comprovação correta, o cliente pode bloquear as chamadas subsequentes das APIs de nível inferior.

@Pauan alguma ideia de por que esse assunto não está encerrado? Com base no seu comentário

Isso não é uma limitação no WebAssembly, é uma limitação no próprio navegador da web: o navegador só permite que você use HTTP (S), WebSockets ou WebRTC. Não tem suporte para sockets raw (UDP ou TCP).

Eu não acho que isso jamais será suportado. Algum comentário?

@ondrejtomcik Não faço parte dos grupos de trabalho WebAssembly ou W3C, então não posso comentar sobre isso.

Mas, na minha opinião pessoal, esse recurso deve ir para o próprio navegador, não Wasm, então seria melhor abrir um novo problema com o W3C.

Conforme mencionado acima, se você tem como alvo a Web (via Emscripten), provavelmente terá que portar sua lógica de rede para usar WebSockets ou experimentar o WebTransport .

Se você está almejando ambientes de servidor, dê uma olhada no WASI, ele ainda não foi implementado, mas há solicitações de recursos (https://github.com/bytecodealliance/wasmtime/issues/70).

Isso não é algo que entra no próprio WebAssembly: é fornecido pelo host / incorporador.