You should use WebRTC then, I think. - Alon
On Thu, Jan 16, 2014 at 9:18 PM, Bram Stolk <[email protected]> wrote: > Thanks, > > > So if I understand correctly: WebSockets is TCP and WebRTC may be either > UDP or TCP, without direct control on what is used? > http://stackoverflow.com/questions/18897917/does-webrtc-use-tcp-or-udp > > In my application I cannot afford TCP, as I need to absolute lowest > latency, and cannot tolerate acknowledgements, retransmissions, etc. > It is a shared physics sim on two different machines and will only work > with minimal latencies. > (Packetloss disturbs TCP greatly in latency and even more so in > throughput.) > > Bram > > > On Thursday, January 16, 2014 6:09:57 PM UTC-8, Anthony Pesch wrote: > >> 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.
