UDP sockets

[Bram Stolk]

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/ 

15:51:28.003 Firefox can't establish a connection to the server at ws://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

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

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

...

Thx,

  Bram

 

[Ivan Vučica]

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

--
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 emscripten-disc...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Bram Stolk]

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

--
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 emscripten-disc...@googlegroups.com.

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

[Anthony Pesch]

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

[Alon Zakai]

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

[Bram Stolk]

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

To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-discuss+unsub...@googlegroups.com.

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 emscripten-discuss+unsub...@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.

[Alon Zakai]

You should use WebRTC then, I think.

- Alon

To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-disc...@googlegroups.com.

[Ivan Vučica]

On Thu, Jan 16, 2014 at 9:18 PM, Bram Stolk <b.s...@gmail.com> 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,

First I would highly recommend rethinking the game/app architecture if it is so highly sensitive on latency. The worst gaming experiences I had always involved games that went through "sync lost" halfway through a two-hour RTS match.

I am saying this because you say the game will work only with minimal latencies, so I presume the game will have issues even if I introduce, say, 20 different wifi networks around that wreak havoc on your channel 6 2.4GHz wifi. Oh, and for fun I'll throw in 40 students connected on that same wifi that are downloading movies of dubious legality using certain peer-to-peer technologies.

With that said, I am not in any way suggesting you should be even considering TCP. But your wording about latency making the whole system break down makes it sound like the game might have issues with UDP as well.

Finally, in browser, I don't think you'll get any closer to UDP than WebRTC's data channels. Sadly, you can have no guarantees. A lot of web technologies exposed by browsers are black boxes.

Best you can do is try and see if the approach works for you with current generation of browsers.

If you want to play with proprietary stuff, you could always try talking to a script running in the Flash plugin or an applet running in the Java plugin and let them do the actual UDP connections. For "a few" reasons, I don't think that's a good idea, but I'll just put it down nonetheless.

Good luck!

[Ivan Vučica]

On Thu, Jan 16, 2014 at 9:18 PM, Bram Stolk <b.s...@gmail.com> wrote:

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

...and looking closer to the link you posted, looks like reliable data channels use SCTP, which is (according to the Book of Knowledge) a message-based reimagining of TCP, including reliable data transfer.

According to this: http://www.webrtc.org/chrome#TOC-Data-Channels- and this: http://tools.ietf.org/html/draft-ietf-rtcweb-data-channel there is also a concept of nonreliable data channels.

So try to request a nonreliable data channel and see what happens!

[Bram Stolk]

Ivan,

Thanks.

About the architecture: I think I've got that covered.

In my game, each datagram that a peer receives is useful in its own right, regardless of which other datagrams arrived.

There is no synchronization that can get lost, just a continuous scale of update frequency.

(Only if there is a prolonged absence of datagrams, I consider the online match aborted.)

The longer the period between updates from peer, the more my local sim will deviate from the remote sim.

A lost datagram is easily overcome: it just uses the information of the next datagram instead.

A lost packet in TCP will have far more severe consequences: the sender will reduce throughput by half.

And later packets get blocked until preceding ones are delivered. It's nasty.

In my sim, I'm only interested in the latest packet, and have no further interest in old ones.

That's so nice about UDP: a lost packet has no effect on subsequent datagrams.

When I find the time, I will investigate unreliable service from WebRTC.

Thanks,

Bram

--

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 emscripten-disc...@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.