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 On Fri, Jan 17, 2014 at 6:03 PM, Ivan Vučica <[email protected]> wrote: > 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, > > 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! > > -- > 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.
