UDP connection?

[JustArchi]

Hey there!

I noticed that it's possible to run SK2 client in two modes: TCP (default) or UDP. I know the difference between those protocols, but my question is, is there any use case where you would actually want to run steam client with UDP connection? I doubt steam has any retransmission implemented with UDP, so probably the likehood of requests being lost in the abyss is quite high, do I miss some obvious use case? I'm trying to find out the reason for implementing such option, as maybe it is useful, and I just can't see how.

Thanks!

[DoctorMcKay]

I doubt steam has any retransmission implemented with UDP

It does. Steam's UDP is basically TCP over UDP. It has sequencing, acknowledgement, retransmission, etc. All the stuff you'd expect from TCP. It's the default protocol used by the proper Steam client.

I'm unfamiliar with how SteamKit handles UDP connections, but using UDP could theoretically help you to detect dropped connections faster than TCP, depending on how your OS handles TCP.

[JustArchi]

It's the default protocol used by the proper Steam client.

Why does SK2 uses TCP by default then? Is there any rationale? I'm trying to decide myself between those two, so that info is actually very useful for me.

[Netshroud]

I have no idea.

FYI, the Steam client defaults to TCP on single-core machines and UDP on multi-core machines.

[JustArchi]

That's interesting information, thanks @Netshroud. I'm wondering why is that so, I mean they probably had a reason behind that. I'm not quite sure what reason though, as it seems weird to me that the decision which protocol to use is based on number of cores (threads?) of the CPU. UDP has less overhead, but if they decided to implement all TCP features in, such as sequencing, acknowledgement and retransmission, then it seems kinda pointless to even make UDP a variant, especially as user can't decide between those two, otherwise I'd even bring some foolish argument such as working around some firewalls.

Leaving this issue open in case somebody else ( @azuisleet @voided ) wants to add something to the discussion, as it would be quite nice to find out the reasoning of steam behind that, and what connection should be used in what case. In the meantime I added a proper switch to my ASF project, so perhaps other users can tell me more about this mystery based on their own usage.

[DoctorMcKay]

You can force the Steam client to use TCP using a -tcp switch. I presume there's also a -udp one.

[Netshroud]

I can't find a -udp in the disassembly - or even the core-based behaviour I outlined above, which somebody at Valve posted on SPUF eons ago.

Unless somebody can find otherwise, looks like Steam might now default to UDP and only use TCP if requested to via the command line.

[JustArchi]

My random thoughts:

Using UDP in SK2 leads to random crash ATM, check out #260 for more details, so definitely do not use it for other purpose than experimental tests.

The feature might be useful to workaround some firewalls, one of my ASF users is actually using UDP because apparently network firewall blocks TCP to Steam ports. Not important at all, but it's good to have a choice.

Personally I think that steam defaults to UDP mostly for overhead and latency reasons - things like voice chat require low latency by default, and that might be even the only reason why UDP is preferred, considering the fact that Valve implemented majority of TCP logic into their UDP steam variant, which seems a bit silly to me (I'd probably decide to use TCP for majority of things, and UDP only for some things that require such approach).

Still, random thoughts, I really doubt that there is any advantage of using UDP in SK2, unless somebody tries to work around some kind of firewall or a proxy. But it's definitely good to have a choice, and quite nice that steam network supports both ways.

[yaakov-h]

Closing as inactive and answered.

I'll leave the attached bug open until I (or someone else, if anyone wants to volunteer) can have a closer look.

For users behind firewalls and proxies, websocket is probably now the way to go. 😄