What we can learn from game developers? 

There will be no code 

Main problems in games • Performance • Performance • Performance 

Solutions • Intrusive lists • Better CPU cache utilisation • Makes structures look „weird” • Entity-Component-System • Try to manage data independently form logic • Separate of concerns • Datagram protocols • Connection-less communication • Loosing package isn’t a problem 

Intrusive lists are completely pointless for our case So I will not get into details 

Entity-Component-System • Component - collection of data • Should be small • Contain no logic • Entity - collection of Components • In general sense - common ID for the components • System - logic over Components • Contain logic • Modifies one or more components • Do not care about Entities • Listen on events in log 

No content

Live 

Live Fluffy 

Live Fluffy Placeable 

Live Fluffy Placeable Mobile 

Live Fluffy Placeable Mobile Jumpy 

Live Fluffy Placeable Mobile Feedable Jumpy 

Live Fluffy Placeable Mobile Weight Feedable Jumpy 

Live Fluffy Placeable Mobile Edible Weight Feedable Jumpy 

Live Fluffy Placeable Mobile Edible Weight Feedable Jumpy 

Placeable Mobile Jumpy Weight Jumping 

Placeable Mobile Jumpy Weight Jumping Moving 

Placeable Mobile Jumpy Weight Jumping Placeable Mobile Moving Weight 

„Real example” Electronic Medical Record system 

Entity-Component • Patient • Name (first name, last name) • Vitals (pulse, body temp., etc.) • Illness • Practitioner • Name • Authentication • License 

Systems • Authentication • Authorisation • Vitals measurement • Morgue 

Pros • Adding features to entities is simple • Making snake jumpy is as simple as adding component to it • Removing features is simple • Making rabbit immovable is as simple as removing component from it • You can dynamically add features to entities • Less edge cases, as system is not aware of the entities that do not contain given components 

Cons • Eventually consistent • Systems tends to grow and touch a lot of components at once • Unexplored technique in webdev land 

QUIC 

TCP - pros • Nice when you can keep connection open • Quality of Service • Guarantee of delivery • TLS 

TCP - cons • No multihoming (at least in IPv4) • One missing package will delay all next messages until delivered • Three-way handshake 

Hello, would you like to hear a TCP joke? Yes, I'd like to hear a TCP joke. OK, I'll tell you a TCP joke. OK, I'll hear a TCP joke. Are you ready to hear a TCP joke? Yes, I am ready to hear a TCP joke. OK, I'm about to send the TCP joke. It will last 10 seconds, it has two characters, it does not have a setting, it ends with a punchline. OK, I'm ready to hear the TCP joke that will last 10 seconds, has two characters, does not have a setting and will end with a punchline. I'm sorry, your connection has timed out... ...Hello, would you like to hear a TCP joke? 

UDP • Connectionless • No delivery guarantees • No QoS • No congestion negotiation - can cause package drops 

QUIC • Implementing TCP guarantees on top of UDP • Still connectionless • Encrypted • No three way handshake • Multihoming • Implemented in user space • Non-blocking on missing packages 

HTTP 3 = HTTP 2 over QUIC • Multi-network connections handled via multihoming • Faster delivery, even better than via HTTP 2 push • Encryption „reusage” • Less traffic when establishing encryption suite 

–George Santayana Those who cannot remember the past are condemned to repeat it. 

FIN @hauleth 

Questions?