Net Library Usage
The net library is one of a number of ways to send data between the client and server.
The major advantages of the net library is the large size limit compared to usermessage and console commands, 65533 bytes (around 64KiB) per message, and the ability to send data backwards - from the client to the server.
When you send a net message, you will most likely get an error which contains a shortened URL. This is because the message isn't precached. To precache a message, just call this once server-side:
To be able to send data with the net library, there must be something to handle that data when it's received. We use the function net.Receive, which has two arguments: the name of the net message and the callback function to run when the message is received.
Below is an example of receiving a net message:
Once our net message "MyMessage" is sent, the receiving function is called. The first argument of the receive function is the length of the message (it can be used for debugging or networking protection), the second is the player who sent it, this is only used when net.SendToServer is called (see below).
Now that we have a function to receive it, we need to send the message.
Prior to sending a net message, the string name of the message must be precached once serverside with util.AddNetworkString.
Then to start sending a net message, call net.Start with the name of the message. Then,
- Serverside: Use net.Send, which has one argument: a Player or a table of players. If you're sending to all players, use net.Broadcast.
- Clientside: Use net.SendToServer.
For example, if you wanted to send the myMessage net message to the first player on the server, you would do
We send an empty net message, next we will look at sending data in net messages. Generally empty net messages are used as a simple way of alerting the player of something that has happened on the server which the client does not know about unless the server tells them about it, for example, after a certain time has passed on the server, an empty net message could be sent to the client to tell them that a menu should be opened.
To send data, after calling the net.Start function, you can use the following functions, each for their specified data type:
For reading data, there are functions for each writable type of data above, generally being net.Read(Type).
It is recommended you have a basic understanding of hooks before you attempt these.
GM:PlayerDeath is a hook that is only called serverside. If we want to tell every player that a player has died we can use the net library.
Since chat.AddText is a function that we can only use on the client we need to find a way to tell the client that a player died. The solution is simple, in the GM:PlayerDeath hook, use net.WriteEntity to send the entity to the client, read the entity then run chat.AddText with the colors we want.
Challenges (Don't progress until you have done these!):
- Can you make it tell everyone who the player was killed by?
- Can you make it so that it only tells the attacker they killed a player?
We want to know how old the player is, and we also want everyone on the server to know about it. The problem is, VGUI functions can only be called clientside, but don't worry, the net library is here!
Notice how we don't actually tell the server who we are using net.WriteEntity. This is because serverside, net.Receive's second argument is the player who sent it. We'll go in to more depth about net message security after this example.
Challenges (Don't continue until you have done these!): Can you make the age message show in color? Can you make the message also show the players favorite food?
When sending a net message from client to server, you pose a huge security risk. Let's pretend for a moment that someone has written this code serverside:
Take a look at this code. Can you figure out what could happen if this code was actually used on a server?
Let's break it down. This net message bans a player when the BanPlayer net message is sent to the server. However, there are no checks to see if the player is actually an admin or not. This means people could send their own net messages, from outside the script that it was created in, gaining access to ban any player on your server. To prevent this, follow 1 simple rule:
DON'T TRUST THE CLIENT
Don't preform checks on user input clientside then assume that they are fine serverside. Don't be lazy and only check data in the realm where it can be easily manipulated. You should look out for negative numbers, people sending net messages very fast, people trying to write entities that should never be written, as long as many other things. Before you publish your code, try as hard as you can to break it. You are still able to ask user for input, the concern is in validity of that input.
net.WriteEntity(LocalPlayer())on clientside and
local caller = net.ReadEntity()on serverside. Do not do this, this will expose your server code and it can be exploited!
An easy way to secure your Net functions:
When you design your net communication it's important to make it effective as possible.
Here is some sections you can check:
The less data you can send with the same efficiency, the better.
You don't need to send the whole derma menu to client every time. Create a clientside function that opens this menu and send empty net message from serverside.
Net cost before:
(length of the code + 1) * 8 bits per message.
Net cost after:
0 bits per message.
As a beginner you are allowed to use 32 bits in the second parameter in net.WriteUInt and net.WriteInt, however this is too much if you send small numbers. net.WriteUInt and net.WriteInt pages have tables you can use to find amount of bits you need.
For example player sends a number he chose, you know the number should be in range from 0 to 64. The number represents amount of players to affect (server has 64 slots). We don't have negative values, so we use net.WriteUInt. We need 7 bits to fit 65 numbers (0-64).
7 bits is better than 32 for sure, however here we can use our logic: if this is sent by a player then there is at least one player, so it can't be
0, we can make player to choose from 1 to 64. This is wtill 7 bits, but if we subtract 1 when sending (and adding 1 back on reading) we can do 6 bits.
Net cost before:
32 bits per message.
Net cost after:
6 bits per message.
net.WriteTable's problem it doesn't know how large your number can be, it doesn't differ vectors from normalized vectors. net.WriteTable sends key type, key data, value type, value data. Writing the type costs 8 bits. Vector costs vary amount of bits. net.WriteTable writes all numbers as doubles which is 64 bits. net.WriteTable writes all vectors (normalized and not) as vectors.
|Bits written||Value type||Value||Description|
||Key type (UInt)|
||Value type (UInt)|
||Key type (UInt)|
||Value type (UInt)|
||End of the table|
Total: 283 bits per message minimum. ~349 bits per message maximum.
This is super expensive, since we know our fields in the table we can get rid of keys (From 283-349 to 91-157).
We also know our values so we don't need to send their type.
At this point you should stop using net.WriteTable.
Let's use net.WriteNormal for the normalized vector (costs less bits and doesn't lose precision that much) and net.WriteFloat for normalized number (if you need full precision use net.WriteDouble, but here it's not that important):
|Bits written||Value type||Value|
Total: 35 bits per message minimum. 59 bits per message maximum.
I think the difference is pretty obvious.
If you need to send large amount of data you can compress it.
This method saves net bandwidth but may increase CPU time.
First we need to get the length of the compressed string, then read it and decompress.
lenargument from the net.Receive and use it instead of
local len = net.ReadUInt( 16 )
Net channel may overflow if too many messages or too much data were sent. Here is what can be done for this:
You can find a balance between time and size of net messages.
If you experienced lag, you should probably split the net message into parts, unless you need to send it instantly.
Find an optimal delay for sending messages. Can you send them once per minute instead of a second?
If you need to send large data and you can't delay it or split use compression method mentioned above.
net.Start has second parameter
unreliable. Which decide how to send your net message: on reliable layer or not.
Reliable layer may overflow on large data.
You can switch to unreliable mode. This should help your net messages not to overflow but they are not guaranteed to reach the client. This can be used to send information that doesn't break anything if it gets lost.