
Show HN: KCP: a new low-latency, secure network stack - skywind3000
https://improbable.io/blog/kcp-a-new-low-latency-secure-network-stack
======
Jedd
> 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_...](https://en.wikipedia.org/wiki/Space_Communications_Protocol_Specifications)

------
cryo
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](https://github.com/skywind3000/kcp)

------
fxtentacle
I am surprised that they don't even mention
[http://enet.bespin.org/](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.

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

~~~
fxtentacle
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](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.

------
XelNika
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.

------
the_duke
How does KCP compare to QUIC?

~~~
AkshatM
I came here to ask the same question.

~~~
rand0mstring
ditto lol

------
psandersen
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?

------
rand0mstring
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](https://forum.syncthing.net/t/connections-over-udp/9382)

------
ohnoesjmr
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.

------
wongarsu
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.

~~~
vbezhenar
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.

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

~~~
vbezhenar
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.

~~~
SahAssar
WAN is not the same as WLAN.

~~~
vbezhenar
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.

~~~
SahAssar
> 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.

~~~
vbezhenar
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.

------
mleonhard
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?

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

~~~
comex
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.

