Archived

This topic is now archived and is closed to further replies.

wrfstudios

my game BLOODLUST is getting to much lag

Recommended Posts

wrfstudios    122
My players are experiencing lag - im not sure but i think this is because im using tcp/ip - with tcp/ip its my understanding that the system will stop and wait until every single packet sent is recieved. With 5-8 players no lag - but when about 10+ log on it starts lagging. I dont think its my system because i monitor when packet is sent and recieved and it simply hangs for a few seconds every 30 seconds or so. Like its waiting for a packet so everyone else has to wait. Any ideas? ALSO: you can check out my game at http://www.lasthalfofdarkness.com/bloodlust Thanks Bill

Share this post


Link to post
Share on other sites
Guest Anonymous Poster   
Guest Anonymous Poster
You could try using ReplicaNet instead. You can download it at http://www.replicanet.com/
This would let you worry about writing the game and not worry so much about networking issues.

Share this post


Link to post
Share on other sites
RonHiler    214
quote:
Original post by wrfstudios
My players are experiencing lag - im not sure but i think this is because im using tcp/ip - with tcp/ip its my understanding that the system will stop and wait until every single packet sent is recieved.

Yep that is correct. Sounds like that's probably your problem. And now you know why most multiplayer games use UDP. TCP is good for slow paced games, like turn based stuff, but it doesn't fare well with twitch games. The only way to fix it is to go with UDP. Of course, then you will have to deal with reliability and ordering issues, which is probably what you were trying to avoid using TCP in the first place

Nice looking game, by the way.

-Ron



[edited by - RonHiler on September 2, 2003 10:32:58 AM]

Share this post


Link to post
Share on other sites
cbenoi1    484
> when using DirectPlay and TCP/IP, will this problem still exist?

DirectPlay 8 and up use UDP for network communication. Reliable and in-order packets follow the same route, but are monitored with special acknowledgment return packets. You could experience similar lag with DirectPlay if you mark all your packets as ''reliable and in-order'', but with DP you have to ability to lower down your contraints in favor of a better performance and network utilization. This is not something you can do with pure TCP as the protocol is cast in stone.

-cb

Share this post


Link to post
Share on other sites
wrfstudios    122
ok - this is my design...let me know if anyone sees any fundamental design problems...

- all the clients send in their requests and cordinates every 1 second to the server.

- each time the server receives data from the client it takes in that data and then sends the other players info and cordinates back to the client that just sent the data.

so only when the client sends data to the server is when the server processes and sends data back to client (updating all players info on clients machine)

But i think when too many people (or client software) send data to the server it cant handle it so the "buffer gets full" maybe? or because more people are sending data to server theres more of a chance for staggering data? I dont know.

Any ideas?
Thanks
Bill

Share this post


Link to post
Share on other sites
Cahaan    122
What kind of architecture/sockets did you use for the server ? Asynchronous ? non-blocking ?

Perhaps a flaw in your protocol ? Perhaps you're losing some data from the network buffer where you could read it again to receive the whole data?
Most probably it is a protocol flaw, you say you HAVE to wait for some packets before being able to do anything else ? Are you using blocking sockets ? if not, then it's most probably an design issue and your best bet would be to make it more "asynchronous" without the need to receive data before doing anything else. If your protocol is doing that, switching to UDP wouldn't fix it IMHO.

Really hard to say without any code to read, that can be a lot of things, but I'm pretty sure it's not related to TCP itself.
Using TCP shouldn't cause so much troubles with a number of 12 users.

The best thing to do is testing, debugging, testing, debugging. Try to isolate the problem by repeating tests. You should probably try to write complete informations about what's happening (and what's not happening) to some textlog files, use timers, trace your code, and so on.

Good luck anyway.





[edited by - Cahaan on September 2, 2003 10:53:13 PM]

Share this post


Link to post
Share on other sites
RonHiler    214
If you say so Cahaan, but I disagree. This:
quote:

it simply hangs for a few seconds every 30 seconds or so


sounds an awful lot like TCP waiting on a frame to me.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster   
Guest Anonymous Poster
It depends on his implementation.

So 12 players.

Players A-L:

A : sends request + coorindates TO server : estimated ~24 bytes

SERVER : recvies packet_of_A( 24 bytes )

SERVER : sends A_update ( coordinates + misc ~ 16 bytes ) to all 12 players (including A) 16*12 = 192 bytes estiamted.

Say a update of 10 ups on the server side.

An active momenent in the game say all of the users do something to warrent an update within a second.

192*12 = 2028 bytes of data / sec. That is a packet between 192 - 2028 can be created for each client, within a single tick depending upon the conditions of when the server recives the request+coorindates packets from the clients.

Factor in Nagels Algorithim for TCP_IP, the packets can be larger.

So if it''s on the large end of the specturm, the client chokes, TCP_IP expontinal fallback kicks in, and if you''ve impelmented a simple round robin method to handle the connections, you will block on the offending client, lagging everyone. However if you''ve implmetned either a multithreaded or async method, it shouldn''t effect the other clients, except that they too might experience lag on the larger packets.

So it''s very possible for your clients to expereicne lag just due to your network protocols, or it could be a bug

Good Luck!

-ddn

Share this post


Link to post
Share on other sites