Reduce Packet Lag... Add a Packet Bufferi

Reduce Packet Lag... Add a Packet Bufferi - Printable Version

+- Mirage Source (https://mirage-engine.uk/forums)
+-- Forum: Mirage Source (Nostalgia) (https://mirage-engine.uk/forums/forumdisplay.php?fid=61)
+--- Forum: Archive (2006-2011) (https://mirage-engine.uk/forums/forumdisplay.php?fid=18)
+---- Forum: Resources (https://mirage-engine.uk/forums/forumdisplay.php?fid=49)
+---- Thread: Reduce Packet Lag... Add a Packet Bufferi (/showthread.php?tid=506)

Reduce Packet Lag... Add a Packet Bufferi - William - 20-12-2006

Originally posted by Verrigan

Difficulty: Medium 3/5

This tutorial is designed to show you how to put a buffer system in your game. Why would you want to do that? Think about it. When a player connects, there are a series of messages sent to that player, and in Mirage, they are sent one right after the other.. If you have large maps, or you have a bunch of items/npcs/spells/etc., the server will send all that data to a user who is connecting.. For small games with small sized maps, this isn't a problem.. Lag is minimal. However, for games with tons of items, spells, etc., you will experience lag when another player connects.

Okay, now introduce a buffering (queue) system.. The server form has a timer that calls a subroutine that is solely responsible for dropping the size of the queue. How does the queue get filled? Instead of immediately sending any data to a player, you make the server add it to the queue. The server then hits the timer's interval, calls the subroutine to drop the queue, which sends messages to each user that is waiting for those messages. The subroutine will go through all connections, check the queue, and deliver messages to each user up to a predefined size limit for each user.. (This tutorial limits that size to 32K per user, per loop, but you can easily customize that limit.)

All that said, I must say that I have only tested this buffer system with one connection, so it might need some work, which is why I set the difficulty at 3.. Some of you might think the difficulty should be 5, but that's why I'm going to tell you this: BACKUP YOUR SERVER BEFORE ADDING THIS TUTORIAL.

Now, on with the tutorial..

Files to Modify

frmServer.frm
modGeneral.bas
modServerTCP.bas
modTypes.bas

*** In addition to the above files, you will need to change any line from:

Code:
Call CloseSocket()

to:

Code:
QueueDisconnect() = True

frmServer.frm
FrmServer is where timers and sockets are stored.. I don't like to do this, but my tutorials are based on the already existing code in the Mirage Source, not redoing the whole thing.. Tongue

So...

Add a timer to the form named: tmrStartMsgQueue with an interval of 100. Then, in the code of frmServer, add the following code:

Code:
Private Sub tmrStartMsgQueue_Timer()

  Call SendQueuedData

End Sub

modGeneral.bas
ModGeneral is where general stuff happens.. The server is initialized here, the AI is in here, etc.

Add the following code somewhere:

Code:
Sub SendQueuedData()

  Dim i As Integer, n As Long

  Dim TmpStr As String

  For i = 1 To MAX_PLAYERS

    TmpStr = ""

    With ConQueues(i)

      If Not .Lock Then

        If frmServer.Socket(i).State  7 Then

          .Lines = ""

        End If

        If Len(.Lines) = 0 And QueueDisconnect(i) = True Then

          Call CloseSocket(i)

          QueueDisconnect(i) = False

        Else

          If Len(.Lines) > 0 Then

             If Len(.Lines) < MAX_PACKETLEN Then

               TmpStr = .Lines

             Else

               TmpStr = Left(.Lines, MAX_PACKETLEN)

             End If

             .Lines = Right(.Lines, Len(.Lines) - Len(TmpStr))

          End If

        End If

        If Len(TmpStr) > 0 Then

          Call frmServer.Socket(i).SendData(TmpStr)

        End If

      End If

    End With

  Next

  DoEvents

End Sub

In Sub InitServer
After this code:

Code:
' Init all the player sockets

    For i = 1 To MAX_PLAYERS

        Call SetStatus("Initializing player array...")

        Call ClearPlayer(i)

        Load frmServer.Socket(i)

add this code:

Code:
ConQueues(i).Lines = "" 'Initialize the lines.

modServerTCP.bas
ModServerTCP handles the data being sent from/received to the server.

In Sub SendDataTo()
Change this code:

Code:
If IsConnected(Index) Then

        frmServer.Socket(Index).SendData Data

        DoEvents

    End If

to this code:

Code:
If IsConnected(Index) Then

        With ConQueues(Index)

          .Lock = True

          .Lines = .Lines & Data

          .Lock = False

        End With

        'DoEvents

    End If

modTypes.bas
ModTypes is where all the data types are stored, and other stuff...

Under this code:

Code:
Type GuildRec

    Name As String * NAME_LENGTH

    Founder As String * NAME_LENGTH

    Member(1 To MAX_GUILD_MEMBERS) As String * NAME_LENGTH

End Type

add this code:

Code:
Type ConDataQueue

  Lock As Boolean

  Lines As String

End Type

Public ConQueues(MAX_PLAYERS) As ConDataQueue

Public Const MAX_PACKETLEN As Long = 32768 'About 32K

Public QueueDisconnect(MAX_PLAYERS) As Boolean

This was tested in a vanilla Mirage Source 3.0.3. So, if you add this to your game, and I only tested this with one player connected.. (I don't have a bunch of users, cause I don't run a Mirage server.. Tongue

) Anyways.. Just like any other tutorials on here... BACKUP YOUR SOURCE!!! I said it twice, now... Hopefully you will take my advice..

It is also possible that I failed to put something in here.. In the event that you find that I forgot something, or you tried this in a vanilla server and it didn't work.. Please post here, but I'm pretty sure I remembered everything.. Smile

- Xlithan - 18-01-2007

Has anybody tested this?

- William - 18-01-2007

Yes.

- Spodi - 18-01-2007

I just want to throw in - this is a great idea, but not when using Winsock control. Reason for this is that the Winsock control has the Nagle Algorithm enabled by default, and I don't think you can turn it off.

The Nagle Algorithm is basically a packet buffer created for office programs where slight packet delays are hardly a problem. The Winsock control was designed for quickly made applications, not online games or anything, so I doubt turning it off was even a consideration in their design.

How it works is that it buffers your packets for about 300ms from the first call. So if you send a packet, it will take at most a bonus 300ms onto your network lag. Thats on top of everything else, not total. If you buffer yourself, you'll probably keep throwing your buffers into the same Nagle buffer, which means it'd have the exact same effect in the long run (almost) to just send a bunch of small packets.

You have to thank the Nagle algorithm, though, since if it wasn't there, any ORPG using the winsock control (Mirage, Elysium, etc) and without a buffer, would probably have a good 2-4kb/sec added on to the packet size just from headers. :wink:

By the way, TCP headers are 20 bytes, IPv4 headers are 20 bytes, so every packet you send is 40 bytes + the data.

- Xlithan - 19-01-2007

Spodi, vbGORE uses the SOX method right? Which would you recommend added to MSE, the SOX method, or IOCP?

- Spodi - 19-01-2007

I really don't have a lot of IOCP experience, but I can't see many large benifits it'd make to a relatively small series of connections. SOX would be the easiest to use since it is designed to be enarly the exact same as Winsock, so the only change you have to make is using Shut instead of Close and not using an array on the control I believe. :wink:

- William - 19-01-2007

Spodi Wrote:I just want to throw in - this is a great idea, but not when using Winsock control. Reason for this is that the Winsock control has the Nagle Algorithm enabled by default, and I don't think you can turn it off.

The Nagle Algorithm is basically a packet buffer created for office programs where slight packet delays are hardly a problem. The Winsock control was designed for quickly made applications, not online games or anything, so I doubt turning it off was even a consideration in their design.

How it works is that it buffers your packets for about 300ms from the first call. So if you send a packet, it will take at most a bonus 300ms onto your network lag. Thats on top of everything else, not total. If you buffer yourself, you'll probably keep throwing your buffers into the same Nagle buffer, which means it'd have the exact same effect in the long run (almost) to just send a bunch of small packets.

You have to thank the Nagle algorithm, though, since if it wasn't there, any ORPG using the winsock control (Mirage, Elysium, etc) and without a buffer, would probably have a good 2-4kb/sec added on to the packet size just from headers. :wink:

By the way, TCP headers are 20 bytes, IPv4 headers are 20 bytes, so every packet you send is 40 bytes + the data.

So you think it's a bad idea to use this?

- TheRealDamien - 19-01-2007

It shows people how packet buffers are created... I personally wouldnt use this tutorial but I got a good understanding of how I wanted mine to go by looking at this. This is good to learn from but I wouldnt go to any mesure on adding it into my engine or game.

A suitable packet buffer can be created for winsock users but I dont think this is it.

Still I belive/think it holds very good value for people to view and understand and create their own.

- Robin - 19-01-2007

TheRealDamien Wrote:It shows people how packet buffers are created... I personally wouldnt use this tutorial but I got a good understanding of how I wanted mine to go by looking at this. This is good to learn from but I wouldnt go to any mesure on adding it into my engine or game.

A suitable packet buffer can be created for winsock users but I dont think this is it.

Still I belive/think it holds very good value for people to view and understand and create their own.

What are you on about..?

Do you use winsock? Do you use the winsock control?

- Harry - 19-01-2007

Kite Wrote:
TheRealDamien Wrote:It shows people how packet buffers are created... I personally wouldnt use this tutorial but I got a good understanding of how I wanted mine to go by looking at this. This is good to learn from but I wouldnt go to any mesure on adding it into my engine or game.

A suitable packet buffer can be created for winsock users but I dont think this is it.

Still I belive/think it holds very good value for people to view and understand and create their own.

What are you on about..?

Do you use winsock? Do you use the winsock control?

Wooooow!!! Slow down there.

He needs to get Visual basic first. :roll:

- Spodi - 19-01-2007

No William, not useless. With the Winsock control, yes (unless you can turn off Nagling in it, often referenced as NoDelay or something), but with SOX and probably IOCP (depending on what the socket library offers), it is absolutely priceless. When you get your packets crunched down a lot on a simple 2d ORPG (since as we all know, not a whole lot of data ever has to be transferred), the big worry becomes sending data as little as possible, and not as much what you are sending. Custom packet buffers give you so much more flexibility on how often you send data. And its fun to play with! Weeee!!! Big Grin

So I'd just add a quick short explanation at the top on why you wouldn't want to use it with WinSock, but that with anything else where you can turn off Nagling, is simply just awesome. :wink:

- Robin - 20-01-2007

Spodi Wrote:No William, not useless. With the Winsock control, yes (unless you can turn off Nagling in it, often referenced as NoDelay or something), but with SOX and probably IOCP (depending on what the socket library offers), it is absolutely priceless. When you get your packets crunched down a lot on a simple 2d ORPG (since as we all know, not a whole lot of data ever has to be transferred), the big worry becomes sending data as little as possible, and not as much what you are sending. Custom packet buffers give you so much more flexibility on how often you send data. And its fun to play with! Weeee!!!

So I'd just add a quick short explanation at the top on why you wouldn't want to use it with WinSock, but that with anything else where you can turn off Nagling, is simply just awesome. :wink:

That must give you such a massive headache.

- Spodi - 20-01-2007

Actually it isn't too bad. Organization is the main key. You just have to look at the packets you have, and think which ones would suffice having a slight delay, and which ones would be fine not coming until any other packets come. For example, if you get a message on new mail, you can just attach it to the next packet instead of letting it send on its own, since a few second delay wont make any difference (unless they are waiting next to the mailbox doing nothing, no one / thing is in the screen, and no one is talking). Its really fun to see what you can come up with. Of course, you wont be able to find as much as you want just looking at the packets. :wink:

- William - 20-01-2007

Well since Im using IOCP it's probably a good idea to use the packet buffer.

- Xlithan - 07-03-2007

I'll have to try and add IOCP again then.

Re: Reduce Packet Lag... Add a Packet Bufferi - William - 02-09-2007

If adding this, disable the nagling algorithm and also change the timer interval from 100 to 25.

Re: Reduce Packet Lag... Add a Packet Bufferi - Robin - 02-09-2007

Ooh, gonna work on this once I finish converting to the API.

Lol @ Reece being naive.

"I'm sure Elysium fixed this"

lolagasm.

Re: Reduce Packet Lag... Add a Packet Bufferi - Tony - 09-12-2008

Apologies for necro..

But disabling the Nagle algorithm and implementing this Packet buffer

would reduce packet lag?

edit\
Why not use IOCP and packet buffering?

Re: Reduce Packet Lag... Add a Packet Bufferi - William - 09-12-2008

Don't use IOCP and don't use a packet buffer.

Re: Reduce Packet Lag... Add a Packet Bufferi - Tony - 09-12-2008

William Wrote:Don't use IOCP and don't use a packet buffer.

Because?

Re: Reduce Packet Lag... Add a Packet Bufferi - William - 10-12-2008

IOCP is unstable, and the code verrigan provided isn't fully bug free. And IOCP is supposed to be used on a server with thousands of connections, a ms server is better without it. So just skip it.

Re: Reduce Packet Lag... Add a Packet Bufferi - GIAKEN - 10-12-2008

I took IOCP out of a game because it kept getting out of memory errors and players were always having account online problems and so on. The game has about 20 people on average.

Re: Reduce Packet Lag... Add a Packet Bufferi - William - 11-12-2008

There are problems with it and GIAKEN has noticed 1 of the problems, people stay logged in.

I don't use IOCP anymore and I'm just stating my opinion that it's a bad idea to use it. The game is much more stable without it.

Re: Reduce Packet Lag... Add a Packet Bufferi - Tony - 11-12-2008

William Wrote:There are problems with it and GIAKEN has noticed 1 of the problems, people stay logged in.

I don't use IOCP anymore and I'm just stating my opinion that it's a bad idea to use it. The game is much more stable without it.

Oh okay, but what about disabling the nagle algorithm and using packet buffering?

Re: Reduce Packet Lag... Add a Packet Bufferi - William - 11-12-2008

Sure you can do that, but you won't gain anything on it. The code he is providing is more like a base packet buffer. I wouldn't use it, nagling is fine.