my game BLOODLUST is getting to much lag
Author
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
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.
This would let you worry about writing the game and not worry so much about networking issues.
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]
> 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
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
I don''t think this is typically a TCP issue. Most probably a problem in your networking architecture.
Author
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
- 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
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]
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]
If you say so Cahaan, but I disagree. This:
sounds an awful lot like TCP waiting on a frame to me.
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.
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
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
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
