Im looking for resources, books, videos anything I can grab on how to design a multiplayer (Online) game such as an RTS that uses pure native sockets, like how to handle packets, prediction, caching, etc.

Any referral is appreciated

It sounds like you're actually looking for PROGRAMMING info, not DESIGN info.

cebugdev2 said:
uses pure native sockets, like how to handle packets, prediction, caching, etc.

For trying to help, why are you asking about those things? That's an odd mix of topics.

Using “pure native sockets, like how to handle packets” has been out for favor a long time. There are major security concerns, there are layers on top of it that provide authentication, encryption and data security, team/party/session connectivity, network hardware negotiation, and more. That's still a topic you can study, but it's not the level most game programmers work at. If you're looking at resources, perhaps look at the source of enet and similar libraries. The underlying technology for IPv4 (from 1982) and IPv6 (from 1998) have many decades of books about the protocols. Knowing what about them you're interested in could help know what you're trying to do. If you are learning about them because you are trying to make modern games, you're looking at the wrong end of history; you wouldn't spend much time studying the Model T Ford if you wanted to learn about modern cars. Yes the underlying technology of raw sockets is part of the networking stack, but if you're touching it in a modern game things have gone terribly wrong. Either that, or you're on a library development team working on the core tech of the network library, and wanting to be a networking specialist that doesn't really work on game code. It can be useful to know about as a bit of underlying knowledge, but if your interest isn't for primarily academic knowledge it will have little use in modern game development.

Asking about prediction and caching could mean quite a few things. Dead reckoning can help with some networking problems of latency, using the last known physics information like position, speed, and forces to guess where it is right now. Before you can get into that, you'll want to learn about topics like server authoritative versus client authoritative gameplay, object ownership, and latency mitigation techniques. Usually prediction and caching are at odds, since caching means data is stale and cached, but prediction needs fresh data to estimate how things are going to appear. Again, knowing what about the topic you're interested in would help figure out what you're trying to do and how to answer.

1. connect, bind, accept, send, recv, close
2. TCP.
3. DONT THREAD IT, set everthing to non blocking instead, after the connection established!
4. ensure to receive all the data you have sent before processing it with your game code (so use a few bytes to indicate the length at the beginning of each packets for example)
5. your network code will be preferably a few 100 lines, do not overcomplicate or overthink it.
6. try not to send more than a few 100 bytes at once.
7. server must use linux (~15k connections) or bsd (~25k connections), because windows is not a real operating system, just a toy
8. rely on iptables for ddos protection, dont try to implement it in the server
9. use newer kernel, for example linux 5.x

For basics on networking start here - https://beej.us/guide/bgnet/​

It is about as readable guide as you can get on basics of network programming. That's the start.

Once you know the basics - https://gafferongames.com/​ had a very good set of articles on making somewhat reliable UDP protocol. Read it and understand it.

The next step is designing your networking architecture, that's where it starts becoming specific for your project. At that point you need to start asking yourself questions like the following and solve them:

1. How can player set up a game?
2. How can other players connect to those games?
3. Managing lobby prior to game start?
4. Communication service between players?
5. What data does the game need to transfer to be fully working for everyone?
6. How many players each single player in a game needs to communicate to?

Once you're set on how the networking for your project will work, then you can start assembling it together.

Hint from endless headaches with networking in large scale projects (few that I can think off from past weeks at work): Test often, test in PROPER live-like environments, docker together with solid version control is your friend, you will need a server and multiple machines to test physically - DO NOT SKIP THIS STEP

Geri said:

1. connect, bind, accept, send, recv, clos
2. TCP.
3. DONT THREAD IT, set everthing to non blocking instead, after the connection established!
4. ensure to receive all the data you have sent before processing it with your game code (so use a few bytes to indicate the length at the beginning of each packets for example)
5. your network code will be preferably a few 100 lines, do not overcomplicate or overthink it.
6. try not to send more than a few 100 bytes at once.
7. server must use linux (~15k connections) or bsd (~25k connections), because windows is not a real operating system, just a toy
8. rely on iptables for ddos protection, dont try to implement it in the server
9. use newer kernel, for example linux 5.x

1, 2: Those functions are fine if using TCP. TCP is fine to use if you're making an RTS where the player will queue commands ahead of time. (See the “1,500 archers on a 28.8k modem” article for this model.) If you're using UDP, you will want sendto/recvfrom instead.

3. Threading is fine, but what you don't want is “a thread per socket.” Use your favorite asynchronous I/O abstraction – boos::asio, Windows IO completion ports, libevent, or whatnot. You should treat networking like a message queue that goes one way, each way – not as a request/response system.

6. Modern games can send dozens of kilobytes per net tick. This is totally possible for people with 10 Mbit/s or more internet, which is almost everyone these days. It still matters to encode data in a smart way so it doesn't take too much space though, because it will reduce cost/load, as well as let you send network packets more often!

7. Windows can be a fine server OS. Roblox used it for a very long time. I believe both EverQuest, WoW, and Guild Wars used Windows servers. The main challenge there is cost, not performance – the NT kernel is pretty good, and the I/O completion port mechanism is still competitive.

8. IP Tables still run on the server, so it doesn't matter if you try to prevent DDOS in the server binary, or in IP Tables – the packets still make it to the server. You need to filter the traffic much higher up; ideally you'll use a scrubbing data center to avoid the DDOS making it to you at all; if that's not in your budget, you should at least filter the traffic at your outermost gateway/load balancer, not let the traffic get all the way to the server hardware.

9. You should always use the latest patch level of whatever OS you're using. Running unpatched (or even expired, like Windows 7 or XP) OS-es doesn't just make you vulnerable, but also means your machine might be used as a slave for botnets that attack other people.

hplus0603

I would like to point out a few things. iptables uses kernel level modules to do the filtering, and relying on it will be magnitudes more fast, secure and reliable than a hand-crafted solution in your program. The second is the speed of the internet. 10 mbit/s. Well i consider myself a giant geek, but i still only have 3 mbit/sec right now. On paper. In reality, its more like 2 mbit/sec, and if there is at least one task that takes half of this bandwidth, it takes about half minute for me to open google.com, and this is the only isp in my 30km range. Except for the mobile based providers, limiting you to something like 64 kbit/sec after reaching like 8 gbyte traffic per month, and thats what most normies have here instead. My isp didnt bothered to rise the internet speed since 2012. I am not saying this is normal or true for the entire world and population, obviously not, but assuming everyone will have 10 mbit isnt true either. So i would like if you would reconsider recommending people to use multiple kbyte packet sizes in video game communication, or at least if you recommending this behavior, then you should mention them to create a fallback method, which users with potato internet can also use to enjoy the game.