DarkBASIC Professional Discussion->MultiSync - Connection is too laggy
D
Dark Developer Joined: 31st Aug 2006
Location: Mindspace
Posted: 21st Jun 2007 15:34
Hi!

I'm working on an online game with MultiSync, but my game is too laggy either on lan, and I dont know why... I have only 1 player connected...

My client code:

+ Code Snippet
Rem Message ID 1, general position and rotation message
Net put byte 1
Net put int Object position x(1001)
Net put int Object position y(1001)
Net put int Object position z(1001)
Net put int Object angle x(1001)
Net put int Object angle y(1001)
Net put int Object angle z(1001)
Net send


My sever code:

+ Code Snippet
 While net get message()

   Select Net get byte()

    Rem General message
    Case 1
     Position object 1000+Net message from(),Net get int(),Net get int(),Net get int()
     Rotate object 1000+Net message from(),Net get int(),Net get int(),Net get int()
    Endcase

   Endselect

 Endwhile


Could anybody help me out please?
B
Benjamin Joined: 24th Nov 2002
Location: France
Posted: 21st Jun 2007 15:50
The problem is that you are sending and receiving integer values, use floats and it'll work fine.
D
Dark Developer Joined: 31st Aug 2006
Location: Mindspace
Posted: 21st Jun 2007 16:00
I used to work with float values but I was allways getting the same problem. And then I tried to use integers...

Is there any general reason that causes lag? Do I transfer too much data in one sync? I cant imagine what is the reason.

When I test it in one pc, using my internet ip, it is perfect. No lag, no bugs. But when I try to connect to my pc with my brother's, its laggy.

Your examples run with no bugs, so I'm sure I did something wrong...
B
Benjamin Joined: 24th Nov 2002
Location: France
Posted: 21st Jun 2007 16:07
Using integers will make movement appear extremely choppy, so that's definitely not helping things anyway.

Apart from that, there's nothing wrong with that code.

+ Code Snippet
Net put byte 1
Net put float Object position x(1001)
Net put float Object position y(1001)
Net put float Object position z(1001)
Net put float Object angle x(1001)
Net put float Object angle y(1001)
Net put float Object angle z(1001)
Net send


+ Code Snippet
  While net get message()

   Select Net get byte()

    Rem General message
    Case 1
     Position object 1000+Net message from(),Net get float(),Net get float(),Net get float()
     Rotate object 1000+Net message from(),Net get float(),Net get float(),Net get float()
    Endcase

   Endselect

 Endwhile
D
Dark Developer Joined: 31st Aug 2006
Location: Mindspace
Posted: 21st Jun 2007 16:14
OK, but I get the same result (lag) with floats......
M
Math89 Joined: 23rd Jan 2004
Location: UK
Posted: 21st Jun 2007 16:21
Of course, you can't receive the data each frame. Every multiplayer game must have a system to smooth the movements.
D
Dark Developer Joined: 31st Aug 2006
Location: Mindspace
Posted: 21st Jun 2007 16:25
Oh, I didnt know that...

Can I find some tutors how to design a system like that somewhere?
D
Dark Developer Joined: 31st Aug 2006
Location: Mindspace
Posted: 21st Jun 2007 17:01
But I dont understand... Its is perfectly running in localhost...

How to etablish a LAN-based connection with MultiSync?
I
IanM Joined: 11th Sep 2002
Location: In my moon base
Posted: 21st Jun 2007 20:01
When transmitting to localhost, you aren't actually transmitting - you are just copying memory, which is fast.

When you switch to a lan you are moving the data across a 33mhz bus, into a buffer on your network card which is then transmitted using a serial protocol onto your lan, and then the reverse happens on the receiver. Each of these steps take time.

Also, if you are transmitting lots of data from different machines, you'll get network collisions (two or more NICs transmitting at the same time on the same piece of wire), causing delayed retransmissions. For UDP, sometimes the packet can be dropped altogether, causing the data to never be received.

If you are transmitting your data every frame (which I assume that you are doing), even though there isn't a lot of data in the packet, and if all machines are receiving this and responding, you'll soon cause your connections to grind to a halt, resulting in ... choppy movement!

Try to reduce the number of transmissions you do (eg, once every 10 frames or so) and see if that helps - of course, you'd need to add code to keep objects moving between transmissions to keep things looking reasonable.

Here are a few sites that contain examples/explanations of networking code in actual games and the system used to support multiplayer (dead-reckoning, delta, prioritising etc):
http://unreal.epicgames.com/Network.htm
http://web.archive.org/web/20060322211154/http://www.bookofhook.com/Article/GameDevelopment/TheQuake3NetworkingModel.html
http://www.gamasutra.com/features/20010322/terrano_01.htm
J
jinzai Joined: 19th Aug 2006
Location: USA
Posted: 21st Jun 2007 20:39
It isn't so much collisions; they are actually pretty rare. TCP takes a miniumum of 3 packets to connect; packets are retransmitted when the TTL (Time-To-Live) is exceeded without confirmation of delivery, and there are other reasons why TCP is not generally suitable for transmitting lots of information to many users. Each connection is unique; and it is not a suitable paradigm for the entire game when connected to the Internet.

TCP also blocks on connect, transmit and receive. That is significant to consider, as it affects the server a great deal. TCP is a complex protocol for a reason, its ultrareliable...but ultraslow and cumbersome. UDP is the antithesis of that - that is why they should be used together, not exclusive of one another.

Wikipedia has alot of useful information on TCP/UDP...really all of it. It would be a good idea to study that - it would explain it very well.

Your results make sense - its not Multisync - its TCP. Its not entirely clear to me, but perhaps you might receive the messages into the player's buffer instead of getting the values piecemeal and attempting to use them that way.
I
IanM Joined: 11th Sep 2002
Location: In my moon base
Posted: 21st Jun 2007 22:44
I didn't know that MultiSync was TCP ... before you ask where I've been to not know that, see my location!

I'm not sure that I agree with using a mix of TCP & UDP - the synchronisation problems of handling two different delivery channels would seem to me to be harder to deal with than implementing a reliable channel over UDP. There's also the possibility of swamping your UDP traffic with your TCP traffic, or vice versa.

Anyway, seeing as Multisync uses TCP, I doubly suggest that the amount of data being transmitted is reduced. I don't know if Ben disables the nagle algorithm when transmitting data from his plug-in, but that could also be causing a problem if it's still enabled.
J
jinzai Joined: 19th Aug 2006
Location: USA
Posted: 21st Jun 2007 23:36
That is funny to me, too IanM...been out of the loop for about 6 years now, but alas - I have no moonbase.

TCP is for making the connection, and console type commands only. TCP/UDP is the prevailing method for all but the most trivial of applications. I am working on that with Multisync and Tempest, they seem to work well together, I wonder why!

The thing about sending TCP packets that are intentionally smaller than the message relates back to what you said about collisions, and also effective use of bandwidth throughout the Net.

In order to avoid collisions, a NIC, upon sensing a transmission on the line, will hold off transmitting for the length of time needed to transmit an MTU (Maximum Transmittable Unit). If the packet is too small, it will create a large silence in the local network, which is propagated throughout the nets it is sent through. It is a fine line, as the packet gets routed, it gets bigger on send, and smaller on receive. You get it coming and going in other words when using TCP.
B
Benjamin Joined: 24th Nov 2002
Location: France
Posted: 22nd Jun 2007 0:17
I don't know if Ben disables the nagle algorithm when transmitting data from his plug-in

Nope, to be honest MS is designed purely around the need to reliably send ordered data, perhaps in a turn based scenario. I wouldn't personally touch TCP for throw away data (ie. data such as positions that get resent at a set interval) as there's no point the system constantly trying to reliably send old data that isn't relevant anymore. Plus, in such a case a slightly lower than adequate connection speed can result in catastrophe (akin to purposely making a machine check for messages slower than another machine sends them).

So yes, this could be caused by nagle/delayed ack. I don't think I've ever tested it with two PCs side by side, so I've never seen the effects of it, but I can imagine it being the case.

I'd do some experimenting myself only it's a little hard to run downstairs to the other PC in in under a millisecond after pressing a key.

TCP/UDP is the prevailing method for all but the most trivial of applications.

Actually, I do see that some games use purely UDP. Some of the features of TCP can be emulated to an extent, and when knowing the exact use of these features it's sometimes possible to take advantage of the way data transmission is handled in the game. It's possibly personal preference, though I prefer the single protocol approach as it makes it simpler for the poor soul who has to configure his router (or for the NAT traversal technique).
G
GatorHex Joined: 5th Apr 2005
Location: Gunchester, UK
Posted: 22nd Jun 2007 1:55
Benjamin can correct me if I'm wrong but I think..

Tempest = Peer 2 Peer = Quake / War Rock = packets sent every n time = a lot of traffic = best for a fast action games - less players

MultiSync = Server 2 Clients = Tibia / WoW = packets sent when a player presses a different key = low bandwidth = many player = better for slower games

They both require a different mind set when programming.