Network protocol overview

Have a question, suggestion, or comment about Aleph One's features and functionality (Lua, MML, the engine itself, etc)? Post such topics here.

Network protocol overview

Post Dec 28th '17, 17:41

Is there a pfhorum post or wiki page anywhere that describes the current networking protocol in A1? I'm looking for a explanation about how the UDP and TCP connections are used, topology, and packet payloads.

At the moment, I'm trying to troubleshoot an intermittent latency issue that I see in some instances which coincides with a spike in UDP traffic. More generally, I often have network questions that I could probably answer myself with a little better understanding of the design.
User avatar

TrajansRow

Post Dec 28th '17, 17:56

There isn't a page, but TCP is used for metaserver communications and game setup (and in-game chat); UDP is used for the game packets themselves. If you want more details, you're going to have to download the code.
User avatar

treellama
Pittsburgh

Post Dec 28th '17, 18:21

Thanks; I’ll have to dig around in the code. Hopefully there some good comments. Incidentally, it looks like SSLP is using UDP also.
User avatar

TrajansRow

Post Dec 28th '17, 22:40

TrajansRow wrote:Hopefully there some good comments.

Haha! I'll try to answer any questions I can.
User avatar

treellama
Pittsburgh

Post Dec 29th '17, 17:54

One thing I’m noticing right away is that the network thread priority on Mach is being set with a legacy syscall, so it’s opting out of modern QoS. I might be able to get better performance just by changing that.

SDLNet also doesn’t appear expose the socket option needed for interactive traffic. ...Easy fix [hack?], I guess.
User avatar

TrajansRow

Post Dec 29th '17, 21:16

I doubt it will help performance any, unless you're on like a single core G4.

SDL_Net doesn't even expose non-blocking reads; we hack even those. When I retire I'll rewrite the whole thing in boost ASIO. Why do you need TCP_NODELAY? So your chat messages arrive 5 ms sooner?
User avatar

treellama
Pittsburgh

Post Dec 29th '17, 21:29

Hey man, those 5 ms could be the difference in GERTing the FALG and not GERTing the FALG.
User avatar

Wrkncacnter

Post Dec 30th '17, 16:09

Who is to say I’m not targeting single core?

Obviously, disabling TCP packet optimization wouldn’t help anything (I mean, it’s right in the name). I was referring to SO_NET_SERVICE_TYPE network layer hints, which do apply to UDP.
User avatar

TrajansRow

Post Dec 31st '17, 13:47

TrajansRow wrote:I was referring to SO_NET_SERVICE_TYPE network layer hints, which do apply to UDP.

I don't see how that one is going to help you either. What experience do you have that makes you think it will?
User avatar

treellama
Pittsburgh

Post Dec 31st '17, 15:17

Network performance is usually very good on a wireless LAN, but the specific problem I’m trying to resolve are semi-periodic spikes in latency when games are hosted on resource-constrained devices (dual arm64 with 1GB RAM, for example). The in-game network diagnostics will sometimes show a simultaneous increase in latency for all clients in the range of 200-500ms. While I don’t know for sure, this suggests to me possible network congestion, de-prioritization, or bookkeeping on the host. There are 1000 other things that can cause this, but I want to investigate the easy stuff first. That’s why I was looking at best practices for QoS and DSCP/WMM; the OS and network need to know if we care less about intermittent cloud syncs or email updates than real-time game traffic.

This is also why it would be useful to understand how traffic flows between players. If data needs to be sent from each player to the host, and then relayed to all other clients, that would further implicate a limitation on the hosting system.
User avatar

TrajansRow

Post Dec 31st '17, 18:16

I have a couple more questions, if you know the answers offhand... My understanding is that clients run independent simulations, which are kept in sync by propagating input from each client to the others. Is that communication the entire state of the key map + mouse deltas, or does the payload represent only changes in input? (In other words, do idle clients send less data than active ones?) Also, is there any substantial data sent during a netgame that is not input-related?
User avatar

TrajansRow

Post Jan 1st '18, 13:33

Data does need to be sent from players to the host, which then relays that information. The alternatives would be too high latency or require too much bandwidth from joiners. Just about every network game works this way.

The intermittent latency is either because you don’t have enough bandwidth to host, or because you’re losing some packets. I recommend switching to a wired connection. The OS and network will ignore any QoS stuff you set, and messing with Aleph One net code is hardly the easy stuff first.

The flag streams from clients are the same regardless of whether they are idle. The protocol allows sending extra data in packets but that’s mainly the net mic. If you stay off that, it should just be input flags.
User avatar

treellama
Pittsburgh

Post Jan 2nd '18, 03:51

Thanks! It's useful to know the bandwidth should be constant during a netgame. I've noticed that a 4-way game requires about 4KB/s sending bandwidth from the host, but that doubles to about 9KB/s if I add in a 200ms delay with the network link conditioner. Maybe the outbound packets are being re-sent in that situation?

I could very well believe the issue I see is a bandwidth limitation (I'm not seeing a ton of evidence of packet loss). The puzzling thing is that the problem is infrequent, but it does seem to occur more often on slower hosts. That's why I was suspecting an intermittent local resource constraint was affecting traffic, which could have been imposed by the OS.

Unfortunately, I can't expect users to use a wired connection. The whole point of this work is so that any group of people can sit down together and play a net game on their mobile devices. The giant bomb I have in my arsenal is ad-hoc networking from the host. That almost always results in reliable performance, but would exclude desktop clients from participating. I suppose the worst-case scenario is to enable that as an option.
User avatar

TrajansRow

Post Jan 2nd '18, 13:14

The host will send all unacknowledged flags every tick, so a 200 ms delay will indeed result in higher bandwidth because it takes that much longer to receive the acknowledgements.

Is the intent to allow a LAN game on mobile devices? You might see if the ring topology still works (it's in the preferences file). If it's Internet play on cell networks that just seems unreasonable to me. Too much latency / jitter to be playable.
User avatar

treellama
Pittsburgh

Post Jan 2nd '18, 19:14

LAN play is the primary goal. I don’t even build with mic support... the best multiplayer experience is when every player is in the same room, IMHO.

I’ll try to see if the ring topology helps; I might even add an option to enable that if the user wants. On the plus side, mobile gameplay works great 95 percent of the time. It’s just these intermittent cases that kind of bug me, but maybe that’s inherent in using a WiFi network. On a good device, you can often play many games without seeing any slowdown.

I’ve noted your advice about playing online via cellular. Fortunately, most mobile players will probably be on some sort of private WiFi.

By the way, how do you think Aleph One contributors feel about mobile distribution? It would be a nice convenience to be able to just grab the engine from the App Store, instead of instructing all players to install the dev kit and build the thing.
User avatar

TrajansRow

Post Jan 2nd '18, 21:24

There is already a mobile version of Aleph One, which wasn't done very well, and hasn't been updated for years. I don't want to see that happen again, so I'm very wary about App Store distribution. I'd imagine hopper is too. So it would take some convincing to get me to be OK with another one.
User avatar

treellama
Pittsburgh

Post Jan 2nd '18, 22:14

You’re right; the port needed some help. This is partly an attempt to fix that. It’s a fork of blezek’s original code and is about ready to turn into a giant pull request for him.

If you need convincing, feel free to try it for yourself:

git clone --recursive https://github.com/TrajansRow/marathon-ios
echo '#define APPIRATER_APP_ID 123456' > marathon-ios/Secrets.h
mkdir CompiledScenarios
ln -s /Applications/Marathon\ Infinity.app/Contents/Resources/DataFiles CompiledScenarios/M3A1
open marathon-ios/AlephOne.xcodeproj
User avatar

TrajansRow

Post Jan 7th '18, 03:45

Based purely on the exceptionally high quality of his YugePax video review, I have a feeling his app would be well done as well. I personally would never want to play an FPS on a phone, but it actually looks mostly playable.
User avatar

Wrkncacnter

Post Jan 7th '18, 14:56

Just watching the video (my laptop is not in any shape to build for iOS at the moment), it does look mostly playable; 3D touch must help a lot.

As for the review, I was expecting a comprehensive review. He left out some of the maps.
User avatar

treellama
Pittsburgh

Post Jan 7th '18, 17:42

Well, I obviously ran out of pedialyte!

The project has come a long way since I made that video. The old fixed D-pad has been replaced with an improved movement system, and there is better trigger control that obviates the need for on-screen buttons. Most maps from the Marathon series can even be played through on TC (3D-touch rocks, BTW, for swimming).

It works surprisingly well for being a tenuous collection of hacks, anti-patterns, and orphaned code paths. I’d encourage anyone with a Mac and iDevice to try it out.
User avatar

TrajansRow


Return to Aleph One Discussion



Who is online

Users browsing this forum: treellama