> I am working on a high-performance game that runs over ssh.

Found your problem.

But it is an interesting world where you can casually burrow into a crypto library and disable important security features more easily than selecting the right network layer solution.

▲

eieio 6 hours ago | parent | next [-]

the obtuseness is the point! This is true of a lot of my work[1][2][3].

The problems you run into when doing things you shouldn't do are often really fun.

[1] https://news.ycombinator.com/item?id=42342382

[2] https://news.ycombinator.com/item?id=37810144

[3] https://news.ycombinator.com/item?id=42674116

	▲	properbrew 4 hours ago \| parent \| next [-]
		These were great reads, thanks for linking. The writeup around the UUID page was super interesting!
	▲	arwineap 5 hours ago \| parent \| prev [-]
		This is hackernews not consumer news You should feel free to explore / abuse all options :)

▲

ycombinatrix 6 hours ago | parent | prev [-]

Yea UDP is technically more performant, but then you need a crypto layer + reliable message delivery layer + bespoke client. Using a plain old SSH client is cool.

However, there are existing libraries for exactly this use case - see https://github.com/ValveSoftware/GameNetworkingSockets

I guess QUIC libraries would also work.

▲

convolvatron 6 hours ago | parent [-]

its not really a question of 'udp performs better'. in tcp we have to live to head-of-line blocking on losses and congestion control. if you don't care about receiving every packet, but only the most recent, then udp is a good choice.

running without congestion control means that you avoid slowstart. but at a certain rate you run into poorly defined 'fairness' issues where you can easily negatively impact other flows. past that point, you can actually self-interfere and cause excessive losses for yourself.

quic uses congestion control, but uses latency estimates and variance as a signal to back off. it still imposes an ordering on a per-stream basis. so it might not be ideal either.

sctp has a mode which supports reliable and unordered, which might be something to consider

so really - if you care about latency and have a different reliability model, its worth unpacking all these considerations and using them to select your transport layer or even consider writing a minimal one yourself

	▲	ycombinatrix 6 hours ago \| parent \| next [-]
		>in tcp we have to live to head-of-line blocking on losses and congestion control. Is this not a performance consideration? Either way, using plain old SSH means a metric bajillion computers have a client for your game built in.
	▲	5 hours ago \| parent \| prev [-]
		[deleted]