Hey Bram, Emscripten currently has two networking back ends, based on WebRTC and WebSockets respectively.
What Ivan said is correct, the closest would be to emulate UDP over WebRTC, but even then the sockets couldn't communicate with an existing UDP server without a middle man doing some sort of translation (something similar to Websockify I'd imagine) unless the server was also compiled with Emscripten. I've not done much work with the WebRTC backend, so I can't speak on how complete it is. However, I've done a lot of work on Emscripten's WebSocket backend and can say it is very functional (at least enough to run Quake3 on it). It supports emulating TCP and UDP sockets with WebSockets. For TCP connections, you can get away with only compiling the client and using Websockify in front of a native server instance, But for UDP sockets, you'd have to compile the server as well when using it. - Anthony On Thu, Jan 16, 2014 at 4:49 PM, Bram Stolk <[email protected]> wrote: > Thanks Ivan, > > Yeah, if the browser can't do it, that's it. > Too bad, as no UDP means that multi player action games in the browser > will be hard to do, especially long distance. > Damn, so close to a full port of my game. > > Oh well, c'est la vie. > > Bram > > > > > On Thu, Jan 16, 2014 at 4:43 PM, Ivan Vučica <[email protected]> wrote: > >> Whatever Emscripten can and cannot do is limited by what JavaScript can >> and cannot do. >> >> To the best of my knowledge, the closest you can get are WebRTC data >> channels. Sadly, I stopped tracking WebRTC when, after months of hoping it >> becomes more usable for XMPP Jingle interop with older clients, it >> continued steering in the other directions. And a compatibility breakage >> discouraged me further (sure, new API allows trickle candidates but...eh). >> Anyway, these days data channels may or may not be available and they may >> or may not allow non reliable datagram level transmissions. They are, >> however, your best hope. >> >> Long term, the best option is still simply to avoid treating Emscripten >> as a black box and a magical C(++)-to-Javascript compiler (although it is >> very magical!) and take a look at what modern browsers can and cannot do. >> >> And to the best of my knowledge, programmatically sending a single IP or >> UDP datagram is one of the things they cannot do for security issues. Heck, >> that's the reason we have "same-origin" policies and hacks to override it >> in case we control the destination server... :-) >> >> sent from phone >> On 17 Jan 2014 00:12, "Bram Stolk" <[email protected]> wrote: >> >>> Hi, >>> >>> >>> I saw that there is a UDP test in >>> tests/sockets/test_sockets_echo_client.c so I assume UDP sockets are >>> possible with emscripten. >>> But when trying to send a datagram over an unconnected socket, I get >>> this in the browser console: >>> >>> *15:51:08.088 GET http://lobby.stolk.org:7460/ >>> <http://lobby.stolk.org:7460/> * >>> *15:51:28.003 Firefox can't establish a connection to the server at >>> ws://lobby.stolk.org:7460/ <http://lobby.stolk.org:7460/>.* >>> >>> >>> So the single datagram send somehow gets translated into full blown >>> TCP/IP connection with http communication over it? >>> >>> Is it possible to send datagrams without connection in firefox using >>> emscripted source code? >>> >>> When running the sockets test that comes with emscripten, I get: >>> >>> *...* >>> *test_getaddrinfo (test_sockets.sockets) ... ok* >>> *test_gethostbyname (test_sockets.sockets) ... ok* >>> *test_getnameinfo (test_sockets.sockets) ... ok* >>> *test_getprotobyname (test_sockets.sockets) ... ok* >>> *test_inet (test_sockets.sockets) ... ok* >>> *test_inet2 (test_sockets.sockets) ... ok* >>> *test_inet3 (test_sockets.sockets) ... ok* >>> *test_inet4 (test_sockets.sockets) ... ok* >>> *test_nodejs_sockets_echo (test_sockets.sockets) ... WARNING root: -I >>> or -L of an absolute path "-I/home/bram/src/emscripten/tests/sockets" >>> encountered. If this is to a local system header/library, it may cause >>> problems (local system files make sense for compiling natively on your >>> system, but not necessarily to JavaScript). Pass '-Wno-warn-absolute-paths' >>> to emcc to hide this warning.* >>> *do_msg_read: allocating 14 bytes for message* >>> *do_msg_read: read 14 bytes* >>> *do_msg_write: sending message header for 14 bytes* >>> *do_msg_write: wrote 14 bytes 14* >>> *[killing 693]* >>> *[kill succeeded]* >>> *[killing 693]* >>> *[kill succeeded]* >>> *WARNING root: -I or -L of an absolute path >>> "-I/home/bram/src/emscripten/tests/sockets" encountered. If this is to a >>> local system header/library, it may cause problems (local system files make >>> sense for compiling natively on your system, but not necessarily to >>> JavaScript). Pass '-Wno-warn-absolute-paths' to emcc to hide this warning.* >>> *do_msg_read: allocating 14 bytes for message* >>> *do_msg_read: read 14 bytes* >>> *do_msg_write: sending message header for 14 bytes* >>> *do_msg_write: wrote 14 bytes 14* >>> *do_msg_read: read 0 bytes* >>> *[killing 735]* >>> *[kill succeeded]* >>> *[killing 735]* >>> *[kill succeeded]* >>> *ok* >>> *test_sockets_echo (test_sockets.sockets) ... running websockify on >>> 49160, forward to tcp 49159* >>> *WebSocket server settings:* >>> * - Listen on :49160* >>> * - Flash security policy server* >>> * - SSL/TLS support* >>> *[Websockify on process [759, 760]]* >>> * - proxying from :49160 to 127.0.0.1:49159 <http://127.0.0.1:49159>* >>> >>> *WARNING root: -I or -L of an absolute path >>> "-I/home/bram/src/emscripten/tests/sockets" encountered. If this is to a >>> local system header/library, it may cause problems (local system files make >>> sense for compiling natively on your system, but not necessarily to >>> JavaScript). Pass '-Wno-warn-absolute-paths' to emcc to hide this warning.* >>> *[killing 759]* >>> *[kill succeeded]* >>> *select failed: Interrupted system call* >>> *[killing 759]* >>> *[kill succeeded]* >>> *ERROR* >>> *test_sockets_echo_bigdata (test_sockets.sockets) ... running websockify >>> on 49170, forward to tcp 49169* >>> *WebSocket server settings:* >>> * - Listen on :49170* >>> * - Flash security policy server* >>> * - SSL/TLS support* >>> *[Websockify on process [782, 783]]* >>> * - proxying from :49170 to 127.0.0.1:49169 <http://127.0.0.1:49169>* >>> >>> *WARNING root: -I or -L of an absolute path >>> "-I/home/bram/src/emscripten/tests/sockets" encountered. If this is to a >>> local system header/library, it may cause problems (local system files make >>> sense for compiling natively on your system, but not necessarily to >>> JavaScript). Pass '-Wno-warn-absolute-paths' to emcc to hide this warning.* >>> *[killing 782]* >>> *[kill succeeded]* >>> *select failed: Interrupted system call* >>> *[killing 782]* >>> *[kill succeeded]* >>> *ERROR* >>> *test_sockets_partial (test_sockets.sockets) ... running websockify on >>> 49180, forward to tcp 49179* >>> *WebSocket server settings:* >>> * - Listen on :49180* >>> * - Flash security policy server* >>> * - SSL/TLS support* >>> *[Websockify on process [814, 815]]* >>> * - proxying from :49180 to 127.0.0.1:49179 <http://127.0.0.1:49179>* >>> >>> *...* >>> >>> >>> >>> >>> Thx, >>> >>> Bram >>> >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "emscripten-discuss" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> >>> For more options, visit https://groups.google.com/groups/opt_out. >>> >> -- >> You received this message because you are subscribed to a topic in the >> Google Groups "emscripten-discuss" group. >> To unsubscribe from this topic, visit >> https://groups.google.com/d/topic/emscripten-discuss/5yWzmkyazYk/unsubscribe >> . >> To unsubscribe from this group and all its topics, send an email to >> [email protected]. >> >> For more options, visit https://groups.google.com/groups/opt_out. >> > > > > -- > > “Programming today is a race between software engineers striving to build > bigger and better idiot- proof programs, and the Universe trying to produce > bigger and better idiots. So far, the Universe is winning.” (R Cook). > > -- > You received this message because you are subscribed to the Google Groups > "emscripten-discuss" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/groups/opt_out. > -- You received this message because you are subscribed to the Google Groups "emscripten-discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
