Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Is it just me or is networking really hard?

gafferongames.com

Post reply on HN
Print view View original

181–188 of 188 posts

Re: Is it just me or is networking really hard?

#181

Post by zurn »

Dylan16807 wrote: post #177
pyre wrote: post #167

Earlier quoted context omitted.

I was using "never implement your own crypto" as an example. I think that "never implement your own crypto" is a more important rule to follow than anything regarding TCP. On the other hand, if you don't know much about networking, trying to reimplement TCP over UDP isn't likely to gain you better performance. As with most things, there is no substitute for knowing what are doing.

I know it was an example, but the crypto saying is actually a good rule of thumb, while "don't do TCP" is a pretty bad rule of thumb. You don't need to know that much about networking to get something that's better than TCP in this specific use case. It may be unoptimized and terrible but your goal is latency. Just pretend that 5% of packets will get lost and do something to compensate, and you beat TCP on imperfect…

There's a lot of work besides performance to get right in a transport protocol though. Just getting the retransmission working like you want is a small part of the job.

WebRTC went for UDP-encapsulated SCTP in order to get a transport without HOL blocking. I'd look into that or an existing UDP game net transport (like Enet) first.

Re: Is it just me or is networking really hard?

#182

Post by Gibbon1 »

davnicwil wrote: post #124
akerl_ wrote: post #55

Earlier quoted context omitted.

I'd argue that the cases where a hash table's performance characteristics come into play are few and far between for most developers, and when they do, it's way more relevant that the person have a general idea how to profile perf in their code and say "yup, this is the spot that I need to worry about optimizing first". By marking down people who don't know how to implement a hash table, you're cutting out a large ch…

I did an interview once where they asked me questions around the implementation of a hashmap. At the time I'd been working about a year out of university, and had not in that job come across any situation where I'd needed to know anything about how hashmaps worked under the hood (if anyone had a first job where you did, I'm happy for you, yours was a lot more interesting than mine). Any remnant of an explanation I'd…

The comment about mirror approach to interviewing reminds me of the first place I worked. At one point we needed to hire someone to do something outside the usual skill set. The CTO interviewed a bunch of people and hired the one that knew slightly less than he did. What O got was the ones that knew what they were doing, disagreed with the CTO on some issues, and so were out of the running.

Re: Is it just me or is networking really hard?

#183

Post by _urga »

perlgeek wrote: post #140
nubb wrote: post #122

Earlier quoted context omitted.

UDP is used when it's designed by network engineers. That's why we have VOIP and video streaming - all are served UDP. dont get me started on the lack of multicast out there. imagine game servers running multicast. one day.

> UDP is used when it's designed by network engineers. UDP is used when low latency and low jitter is more important than complete information. For telefony it's better to lose a few packets than to wait a second or two for a retransmit. Some for game state, I believe. And I do believe that TCP was also designed by network engineers :-)

UDP is a lower level protocol than TCP so it's not an either/or as in "use UDP when low latency etc." is important and TCP when not.

Rather, you'd want to use a protocol built on UDP whenever you want something faster, better, more reliable than TCP.

Re: Is it just me or is networking really hard?

#184

Post by themeisterman »

chetanahuja wrote: post #117

"You can’t even imagine a way that reliability could be implemented on top of UDP that beats TCP? What total bullshit" This. This "TCP already does it best in every situation" is a common trope usually spouted by people who know nothing about what TCP does and why. The easiest way to get over this misconception is to ask yourself, can you think of a protocol that not only works well over all sorts of networks, all th…

Parallel TCP connection is the fasted available today. Much faster and more reliable than UDP. Cleo Jetsonic, specifically. https://www.cleo.com/products/secure-data-integration/cleo-j...

Re: Is it just me or is networking really hard?

#185

Post by Dylan16807 »

zurn wrote: post #180
Dylan16807 wrote: post #152

Earlier quoted context omitted.

Downloads will work just fine if you're dropping .1% of packets. Skype is very resilient to dropped packets. Console use isn't quite so fast that a half-second hiccup is a big problem. But a naive game implementation over TCP will stutter badly and obviously every time.

Yep, and that's different from the hopelessly choppy last mile. The question here is if there's a big difference between a good (not naive) implementation over TCP vs various DIY UDP schemes, and whether that difference justifies the big complexity increases in game design due to trying to cope with out of order/lost events.

You can only do so much over TCP. Unless you are willing to put in a significant delay, dropped packets will cause problems. You can hide them, but there will still be shots that miss, enemies that were never where they displayed, etc.

Re: Is it just me or is networking really hard?

#186

Post by animal531 »

exDM69 wrote: post #103
techdragon wrote: post #47

Earlier quoted context omitted.

Sorry but that needs a rather large asterisk applied to it. In the current era of 120Hz LCD displays and a Billion dollar market for video games. It's becoming very evident that the "best", not in a AAA title sense, but in the 'so popular it becomes a sport with professional players" sense, games are those that have put a LOT more effort into the implications of their network synchronisation algorithms. Some game eng…

Very good point! Back in Quake 1 days, the gameplay framerate was only 15 frames per second, so a more crude mechanism would do. I guess modern AAA games synchronize their clocks with an algorithm similar to what NTP is using. We're still talking about discrete time steps, though, so there's some tolerance for a little clock mismatch.

Usually these days we use client/server for most games, meaning that initially the server is taken as being authoritative on time. It can collect and use a running average of pings to/from all clients which it can then use to order events (ie. did I do X before you did Y?). But that's where the really hard (and fun!) coding and choices start, such as for example future prediction and unrolling of actions.

Roughly speaking, for prediction (to lessen the effect of perceived lag), the server could predict that I was moving forward up to the last packet received, so I'm probably still going to be moving forward. It can then use the predicted values in all calculations until it receives an actual packet informing it what actually happened (at which point it will need to decide how to handle possibly conflicting information, which is handled the same as below).

For unrolling, if you have for example a 50ms ping and I 100ms; then at T+51ms you tell the server that you killed me, but I do the same at T+100ms - effectively compensating for the 50ms of lag difference between us you should die since I killed you 1ms before you killed me. BUT now it really depends on the server choices, do you kill me because your message got there first (old-school FPS); or does the server wait for my info since I'm involved in the action and then retroactively adjust you? Worse, since the server only gets my info on T+100 you will at best only get it at T+150, meaning that you will perceive 99ms of being alive (and maybe during which you killed someone else) which the server will then have to discard before killing you (some modern FPS use this scheme, you'll notice it where you peek out around a corner from safety and then go back, before suddenly being dead from an impossible shot). Also tough is the fact that it's not a single unroll, during the extra 99ms of being alive you would have still been sending packets to the server which then all have to be unrolled.

Re: Is it just me or is networking really hard?

#187

Post by fanf2 »

jwatte wrote: post #165
nubb wrote: post #122

Earlier quoted context omitted.

UDP is used when it's designed by network engineers. That's why we have VOIP and video streaming - all are served UDP. dont get me started on the lack of multicast out there. imagine game servers running multicast. one day.

Multicast at global scales is fundamentally broken. Every router on the internet would have to know about every potential peer wanting to join a multicast group.

Wide-area multicast is usually one-way, which is much easier: each router only needs to know each which streams are to be fanned out to which of its nearest downstream neighbours, and where to forward upstream multicast group join requests.

Re: Is it just me or is networking really hard?

#188

Post by Schwolop »

The best part of this article is the two comments at the end. The first is by the person who posted the Reddit question that prompted the entire rant, describing how asking them question made them rethink everything, and how they ultimately settled on a UDP design just like the one promoted in this article. The second is by the article's author: "Bravo and well done. I’m quite impressed".
Post reply on HN