WebSocket plugin and Multiplayer Games

I've just downloaded and installed Construct 2 for the first time, hoping to see how difficult it would be to connect to my WebSocket Server software (http://highlevellogic.blogspot.se/2011/09/websocket-server-demonstration_26.html).

I was happy to see that you've already discovered Websockets and that there might be a place for my technology since you don't support them completely. However, I wasn't as pleased with your description at "WebSockets and multiplayer games" scirra.com/manual/153/websocket

I don't think "reliable transmission" means what you think it means. WebSockets are an http "upgrade" built on TCP; which employs the selective acknowledgment (SACK) option, defined in RFC 2018, to address the problem you mention.

Maybe you're describing a problem with the specific package you mention, node.js?

I'm not saying there are no potential latency issues to be addressed, but if not TCP transmission, what do you suggest?

highlevellogic.blogspot.se/2011/09/websocket-server-demonstration_26.html

The implication is UDP is necessary for real-time multiplayer games. WebSockets only support TCP.

The implication is UDP is necessary for real-time multiplayer games. WebSockets only support TCP.

I understand what you're saying, but the jury doesn't seem to have given their final verdict on that question: for example,

stackoverflow.com/questions/13040752/websockets-udp-and-benchmarks

I can rig my server to do UDP. The problem is at the browser end, which in some configurations might not be a problem at all.

This is and always has been an interesting topic. Once with pitfalls. The first myth that must be dispelled is

TCP is slower than UDP. TCP and UDP have the same speed of transfer over the internet. Where the draw back is that TCP has safe guards for lost packets and data fragmentation. This will lead to a bottleneck. Often the bottleneck won't be a problem, but sometimes it can build up and that's where it all goes wrong.

For most real-time games. TCP is fine. It's only in high twitch gaming like Fighters(Street Fighter) and Shooters(Halo, CoD....) where the bottle neck is extremly bad. However RTS games and most other real-time will run fine with TCP.

However the link you show is an excellent source of information that WSS can stream data and then using a frame system reduce that problem subsantially.

However I wrote a shooter in C2 using Photon Websocket. My server on a an Acer netbook located in Vancouver BC Canada, was able to play reliable well with some one from Europe. However, a friend of mine located in Vancouver too. Had an extremly choppy experience.

So distance wasn't the problem. Also my shooter had no latency correction, dead reckoning or any advance stuff. All it implemented was a catchup move to system and worked really well.

Websocket is totally doable. However if you can use UDP you might as well :D

But there are examples of TCP being used for active competitive games like Guild Wars. I won't say TCP is better, but it's certainly usable.

Thanks for that jayderyu. I'm just getting focused on applying my technology to games for the first time. I thought I'd start with games requiring transmission of rather small amounts of data, not streaming large numbers of packets. Right click, left click. Moving through a scene might involve sending a series of messages.

There's nothing a standard transmission protocol can do to defeat lag in transmission times, slow transfers when the Internet is busy, etc. As you mention, there are strategies within applications for dealing with that. For Beta and further development, I'd also very much like to be working with people who understand the issues clearly and are designing appropriately based on that understanding. What actions and interactions hold up well? If the first demos and apps are well-designed with the character of the technology in mind, it would help tremendously. It would also help in further development ... beyond simple websockets ... to be able to focus attention directly on important, well-defined, solvable problems.

For my first plunge, I want to use WebSockets. It's a standard that is now supported by all major browsers subject to Microsoft's traditional delay. But they have promised it will work in their current version. (Although my latest test in v10 on Windows 7 didn't.)

But beyond that, I can do anything that I want to do. If the first phase goes nicely, an installable version can support any transmission protocol, and even direct transmissions between users rather than through a common server. That's just one option. Anything is possible.

One of the great things is that I've developed small footprint components. Even from the start, I envisioned installing even on cell phones.

We have done real world experiments and seen that TCP becomes totally unusable for real-time games over a poor quality link. If you weren't aware, the internet is full of poor quality links. TCP can be made to work for games that have no "twitch" reaction requirement, and have high-quality regionally based servers, such as Bombermine. However if you have a twitch reaction game with a single server, it will be totally useless for entire continents of players.

The problem with TCP is it offers guaranteed and ordered transmission. If a single packet gets lost, no future packets will be received by the client application until that packet is retransmitted. In the mean time, the OS holds up all incoming packets and doesn't let the application see them. Even if new data is coming down the network cable, the OS queues it all up and doesn't let the application see it yet, so that the application only ever sees the correctly ordered sequence of packets. That's what TCP is designed to do.

Over a poor quality link TCP packets go missing every couple of seconds, and can take a second or so to retransmit. The game hangs every time this happens. The result is unplayable. Using UDP it would be possible to still get a decent experience, because missing packets are simply discarded and the next one that happens to arrive usually arrives quickly enough to interpolate over the gap.

So technically TCP does not add much extra over-the-wire latency or overhead, but the retransmission and ordering guarantee at the OS level make it perform substantially worse than UDP for gaming. On that basis, I think that StackOverflow question you linked to is complete nonsense! WebRTC is the only reasonable technology to use for real-time gaming.

Your games hang when waiting for a tcp response? That sounds like the days before browsers supported AJAX?

RTC is for media files.

UDP has packets up to 64K for IPv4 and greater for IPv6, which is way more than needed for most command transfers. So ... I won't be waiting for anything more than a packet, a single packet, which if lost is gone. You don't want that. it means the other players' moves are not recognized.

I don't think TCP is the problem.

TCP is the problem. By hanging I mean all transmission was held up, so remote players stopped moving. It's the OS waiting for a dropped packet to be retransmitted.

WebRTC supports DataChannels, allowing arbitrary data (not just media) to be transmitted, and can use a UDP-based transport as well.

TCP is the problem. By hanging I mean all transmission was held up, so remote players stopped moving. It's the OS waiting for a dropped packet to be retransmitted.

WebRTC supports DataChannels, allowing arbitrary data (not just media) to be transmitted, and can use a UDP-based transport as well.

So, you've got a command like "move right" and it's hung up in transmission somewhere. How does WebRTC solve that?

Mozilla Launches Online Game Using HTML5, WebSockets

tomshardware.com/news/Mozilla-WebSocket-HTML5-BrowserQuest-MMOG,15136.html

TCP is the problem. By hanging I mean all transmission was held up, so remote players stopped moving. It's the OS waiting for a dropped packet to be retransmitted.

WebRTC supports DataChannels, allowing arbitrary data (not just media) to be transmitted, and can use a UDP-based transport as well.

I've just got to say that this seems like a problem on the app development side. Asynchronous communication has been all the rage for over a decade. If you do not receive something, you'll still get the next thing. There is no hang up waiting for something to come in.

WebSockets use event handlers for incoming messages. The app doesn't wait for a message. It just processes it when it comes in. That means your app can handle lossy transmission; even though TCP is reliable, which is also what you want in a game. I don't even know how it would know that a message from another player was coming. So I don't see how, even if you tried to design it to get stuck, it could know when it was supposed to get stuck.

The sticker is transmission time over the Internet, and that can't be controlled by the transmission protocol.

TCP is the problem. By hanging I mean all transmission was held up, so remote players stopped moving. It's the OS waiting for a dropped packet to be retransmitted.

WebRTC supports DataChannels, allowing arbitrary data (not just media) to be transmitted, and can use a UDP-based transport as well.

This is true, but keep in mind WebRTC is P2P and would open the door to hackers if used w/o an authoritarian server