Show HN: KCP: a new low-latency, secure network stack | Hacker News Reader

Show HN: KCP: a new low-latency, secure network stack

improbable.io

82 pointsskywind300029 comments

> The problem with TCP is that it was designed a long time ago.

I understand the intent here is to suggest that some of the design decisions made over the past five decades don't align with the author's use case, but the fact TCP was originally implemented in the 1970's (though with many subsequent changes) isn't the problem.

Undeniably TCP's got some problems / features that aren't ideal now, but it's also acquired lots of extensions and knobs to turn to make it perform better in different environments.

For example:

> Amongst other techniques, KCP retransmits packets more quickly, anticipates packet loss before retransmission timeouts, and backs off more slowly when packet loss is detected.

SCPS [1] was designed (~15 years ago) to address some of the challenges with TCP on non-ideal networks - including slower backoff & more aggressive ramp up after packet loss. (Satellite comms throughput typically ends up looking like a sawtooth, meaning you waste a lot of bandwidth by TCP being overly cautious.)

I'm not suggesting it's a candidate for improving multiplayer game performance, just a nod to the fact some of these 'new' problems have been considered before.

[1] https://en.wikipedia.org/wiki/Space_Communications_Protocol_...

KCP is truly awesome. I'm using it in a cross-platform Qt project as alternative to UTP or QUICK protocols which both lack easy to embed libraries.

Check out the C library (MIT licensed) on Github:

https://github.com/skywind3000/kcp

I am surprised that they don't even mention http://enet.bespin.org/ which has been used to provide reliable transmission over UDP in plenty of high-profile video game releases.

Someone reinventing the wheel but not doing enough research to find the state of the art seems a bit odd, or amateurish.

Or that might be a strategy decision, because I believe their paid SpatialOS stuff competes with free enet-based plugins (e.g. Mirror) on the Unity asset store.

It looks like KCP isn't a protocol that was invented by SpatialOS but added on as another option. At least as far as is immediately visible by looking at the github

If you click through to KCP's Github repository, the README does discuss enet.

Yes, but this blog post does performance benchmarking against weaker libraries, while not showing the performance of stronger competitors.

https://github.com/skywind3000/kcp/blob/master/README.en.md BTW has exactly the same diagram as this blog post, so even though it mentions enet, it does not show enet's performance in its comparison graph.

Plus it only mentions enet in the case of a (almost catastrophic) network failure where even KCP has a 1+ second ping. Playing any kind of online game with a ping above 0.5s is pure pain, so that situation is not a valid data point for arguing about KCP or enet's pros or cons.

It seems really weird to me that this post doesn't address what aspects of real-time multiplayer gaming need a reliable transport. The idea of a low-latency reliable transport might seem interesting, but client-server communication generally doesn't require a reliable transport because there's no point in delivering outdated data. From what I can tell, it's because SpatialOS is supposed to support server-side simulation and support splitting that work across multiple game servers. Quite niche IMO.

How does KCP compare to QUIC?

I came here to ask the same question.

ditto lol

On a related note, I've been looking for a way of transparently tunnelling all internet traffic through a vps using KCP to improve an unreliable 4G connection and would appreciate any guidance.

To add additional detail, I'm currently using OpenMTCPRouter to bond 4G and DSL but it suffers when one connection starts experiencing packet loss.

There are plenty of guides out there that use shadowsocks which works well for web-browsing, but to be truly transparent need to just set a gateway to route via the tunnel. A docker image or a vm image that makes needs minimal config on both ends would be ideal. Has anyone done something similar?

anyone have thoughts on this?

"Optimization, again. TCP is implemented in the kernel and, in part, in the network card. When using TCP we can make one call to the kernel to hand it a large buffer of data and say “segment and package this as you see fit”. When using UDP, because we have to do that segmenting and packaging ourselves, we hand each packet individually the kernel. Each call to the kernel is expensive and the overhead becomes very significant, especially in Go. The kernel’s TCP stack is also highly optimized for performance while the kernel’s UDP stack is typically not."

https://forum.syncthing.net/t/connections-over-udp/9382

Perhaps the C library is awesome, but I tried using Go implementation and it's a car crash. Also a protocol with no session control is just weird.

TL;DR: A protocol running on top of TCP. It offers encryption, configurability, cheap stream multiplexing and improved latency on unreliable networks at the cost of additional bandwidth overhead compared to TCP and RakNet. Designed for communication between game server and client, where little bandwidth is needed but latency is key.

It seems to replace TCPs retransmission of lost packets with erasure encoding, so single lost packets can be reconstructed from the packets that made it. That should provide a nice improvement in mobile or wireless networks.

> A protocol running on top of TCP

Probably just a typo, but according to the article it actually runs on top of UDP, as an alternative to TCP.

It wouldn’t make sense to build on top of TCP— a protocol which achieves reliability through packet retransmission.

Does it adapt to network conditions? Usually my network does not lose any packets, sounds wasteful to spend so many bytes for a rare event.

your network might not loose packets,

but somewhere between yourself and any other node in the internet, packet loss is quite common.

WAN links drop packets all the time and that is not a rare event.

Ethernet does not drop packets for me. I guess that people who're using WAN don't care much about network quality, otherwise they wouldn't use it in the first place.

WAN is not the same as WLAN.

Then I don't understand why are you saying that WAN is dropping packets all the time. That's not the case for me. It happens, but it means that my Internet is almost unusable and it's rare event. I'm pinging various websites from time to time (because I play online games and dropped packets is very dangerous) and those pings are just fine. Unless it's common occurrence to pass ping packets but drop data packets, that's not happening for me.

> dropped packets is very dangerous

It's not, they are re-transmitted just fine by TCP or over the protocol built on UDP.

Anyway, dropping packets over WAN is just a fact. If you don't think it happens then you are lucky enough to be able to ignore it.

If you also think it never happens on your LAN then either you have better networking than the best datacenters or you are relying on hardware and software so you never see it.

I did not state that it never happens. I'm aware how TCP works. It's dangerous because game becomes unplayable.

My point is, packets do not drop regularly for me. It's an exception rather than a rule. Spending a significant amount of traffic for error correcting codes which won't be used is a waste. Proper network stack should not enable this mode until actual packet drops are observed and should disable this mode if packets stop dropping. If a lot of packets are dropping, it might be worth to put even more error correcting codes, to be able to recover from two dropped packets, and so on.

You got the top level bullet wrong. KCP runs on top of an unreliable packet model (and only provides value in that model); implementer's choice as to the actual mechanism, but that usually means UDP if you want to get it across the existing internet infrastructure.

TLDR: This is a library providing logical connections over UDP with in-order delivery, packet loss tolerance via erasure-encoding, and encryption.

This would be useful for real-time mobile apps. Do mobile connections even support UDP?

How would you develop a protocol that doesn’t use TCP at all?

By building it on top of UDP, which in turn is a thin wrapper around IP.

In theory, you could alternately build a new protocol directly on top of IP, just as TCP and UDP themselves are built, but middleboxes have a habit of dropping anything that's not TCP or UDP. Plus, unprivileged users on standard OSes can't send arbitrary IP packets, so it would require more setup for users.

There are a lot of IP protocols that sit on top of IP. SCTP, IPsec and ICMP sit right on top of IP on the same level as TCP, for example. Most of the time people UDP use a no-op stub and put their protocol on top of UDP, because many operating systems make it hard to implement IP protocols in userspace, and networks tend to have middleboxes that don't work correctly with most IP protocols.

Reply on news.ycombinator.com