The WebRTC backend is less tested, but it is used in multiplayer
BananaBread,

https://developer.mozilla.org/en-US/demos/detail/bananabread

so it is functional enough for that. WebRTC in general though is quite new,
for example last I checked chrome didn't have the proper binary DataChannel
stuff, only firefox did, but looks like chrome might have added it meanwhile

http://peerjs.com/status

- Alon



On Thu, Jan 16, 2014 at 6:09 PM, Anthony Pesch <[email protected]> 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.
>

-- 
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.

Reply via email to