Multiplayer Buffer
Blitz3D Forums/Blitz3D Programming/Multiplayer Buffer
| ||
| Hello, I've nearly finished writting a multiplayer game in Blitz but i'm a little stuck on 1 problem. I'm still fairly new to Blitz but i've had a good look through the commands and cannot see the solution. When too many players connect to the server the game looses sync. I want to support up to 32 players and my data packet for each player is 36 bytes. I think what is happening is that the network buffer is only 512bytes, so when I have more than 14 players the network buffer is overfilling and getting cropped. Is it possible to increase the buffer size at all? I'm using the TCP command set and need a buffer size of 1152 bytes. Here's a piccy to wet your lips :)  |
| ||
| wet eyes would be more realistic when I look at the washed out non-contrast textures |
| ||
| Dreamora is a troll. They look great andy! Best look at a lib like rottnet on the general discussion forum as this uses UDP and is likely not to suffer those limitations. Worth a look? |
| ||
| Thanks HaemoglobinLocust, i've asked in that thread about the network buffer although i'm dreading the thought of rewritting all my network code ! Thanks also Dreamora, if nothing else you helped keep my thread higher up the forum list... I think perhaps you should look again when I post more pictures of the game and you get to see more than just a tiny segment from just 1 of the 27 maps which feature many texture sets and contrast levels. |
| ||
| I want to support up to 32 players and my data packet for each player is 36 bytes. What is the frequency of packet transmission? Is it a dedicated server program or player hosted? If there were buffers involved they would be per connection so I doubt that is your problem. When you say lose sync do you mean the data communications fail or you are suffering timing problems. If it is a timing problem you should describe exactly how your server is managing it's connections. |
| ||
| Thanks for the start skid, but it is 36 bytes for 32 players to each player. The data is "typically" sent 4 times a second (250ms delay), but for players experiencing high action that can raise slightly. Each player is receiving a 36 byte data packet per active player/bot in the game, so alas it does go over 512bytes per player on a single data packet. The problem I think is that when this overflows the packet gets chopped off so my next attempt to read 36bytes gets an offset in the data stream, causing the link to fail. This happens whenever I have a certain number of players or more (my calculations say this should be 14, but I cant test properly until tonight but that seems roughly right). It is player hosted. The host receives a 35 byte packet from each player and then returns a "36 byte per player" packet back to the sender. |
| ||
| If you check the ReadBytes command docs you will note the command returns actual bytes returned, I'm guessing you are not taking this into account. The easiest way to read from a socket is either with fixed packet sizes so you can easily use ReadAvail() to confirm a data packet is available or with a 4 byte header which get's quite a bit messier. |
| ||
| I hadn't realised that asset of readbytes however there would still be complications in using that because it would meen I could keep a stable connection for 14 players but anything beyond that is just not going to get through. That's why i'm trying to increase the buffer size for each connection. I would have thought it would just be 1 command, but BB doesnt seem to have it :/. I wonder if UDP has a similar limit? 512 bytes is only 4kbits. I'm trying to use 1152 which is 9.216kbit, 4 times a second is 36.504k/bits a second, which doesnt seem excessive to me, especially as some commercial games are now demanding LAN/Broadband to play multiplayer. |
| ||
| for a somewhere fluent game experience you need 10 - 20 transfers per second ... which gives 92 to 184 kbit ... which is a bit high. anything above 100ms isn't fluent enough for a 3D shooter and especially people on broadband ( most europeans as there are no flatrates for ISDN / 56k anymore ) won't really enjoy 250ms pings |
| ||
| I think you are confusing transmission frequency with ping. How about you lay off the flak until you've played the game, in the meentime i'm trying to find a solution to a networking problem, not discuss how much data broadband users want to have as a minimum standard. (can you say "gameplay"?). I'm not saying my game is good, i'm just saying it's unfair to slate it's visuals when you haven't seen them, and slating it's network play when it isn't even finished yet is hardly fair. I see nothing wrong with 4 updates a second (rising during action as said above) with the gameplay on offer in my game. Thanks |
| ||
| 4 updates a second is just fine for most game types. Dreamora, you don't really seem to know what you're talking about. Andy, it sounds like this is a TCP problem. Do you get the same problem if you make a small test program using TCP to transfer 512+ byte packets? That way I could look at your code and try and find a workaround. Either that or use UDP (RottNet or BlitzPlay) :-) |
| ||
| Andy, Looking very nice. Is there anyway you can try to compress the packet before you send it and unpack it when it arrives? - BlitzPlay uses a few tricks and saves quite a lot of bits in doing something similar. IPete2. |
| ||
| Short of compression routines I really cant seperate the data down much more without infringing on gameplay, I already have quite a polymorphic data packet design. Wheter it's sending player chat, bullet info, or chat it all squeezes into those 36 bytes so the only way to compress beyond that is either to do things like make yaw 256 directional and after that, .zip/.rar style compression which has an overhead. All of that has a system overhead. The thing is i'm hoping the buffer size is just a variable, perhaps an internal one to Blitz, that can just be changed. I think i'll email the Blitz team about it and see if they can offer sollice, otherwise i'll have to recode the multiplayer stuff to UDP or one of the userlibs you guys have kindly suggested. |
| ||
| Andy, How about sending the chat separate as most wont be fighting and chatting at the same time. IPete2. |
| ||
| I sort of already have because the data packet is polymorphic, so if there is chat to send the data packet sends chat info instead of other information, the frequency also fluctuates to compensate and large messages are sent over several packets. |
   |