Reading UDP stream
Blitz3D Forums/Blitz3D Programming/Reading UDP stream
| ||
| Since there's no threads in B3D, how should I read the stream? If I have a game that loops say with 60 fps (17ms per loop), it might not be enough to perform RecvUDPMsg only once in that loop. One resolution I thought was loop RecvUDPMsg over until it returns 0. Isn't there a risk that during a peak this could cause fps to drop? If I define a maximum number of packets read in one loop, would it help? The ideal method would be creating another Blitz exe to deal with the communications only (a separate thread), but it would need to communicate somehow (UDP also?) with the client program, which would still be looping with 17ms? How about the buffer of received packets? If the game reads the packets too slowly, when do they start to drop out? Does Blitz buffer these packets or the OS? What's the size of that buffer? |
| ||
| The idea is not to send at that rate. send as little info as possible, at as low a rate as possible. Generally send slower than the lowest ping. This minimises data-rearrangement (does NOT solve it completely). |
| ||
| I have a work-around on the data rearrangement, so it's not an issue here. I'm not going to send all data every tick. It's just that there could be situations where multiple packets are sent about things not related to each other. The question is that if such bursts arrive, should the program read multiple packets per loop or just one. I'm also afraid that if the frame rate drops for some reason I'm only able to guess, it would danger the fluidness of the net game, causing important packets being read really late or even timing out. |
| ||
| Personally I'd read the stream until it will return null, every frame. Someone correct me if I'm wrong here, but I guess to read out the UDP stream means to read out a buffer of incoming data, so this may be much faster than the connection speed. UPD has never been a problem to me, but TCP, and especially when sending data to a webserver. In that case I do non longer wait for a handshake of the server, but simply close the stream right after sending data to it. But that's a TCP issue. In your situation I'd make some speed tests to make sure if there's a buffer or not. Or maybe there's some information about it, somewhere out there. |
| ||
| . Last edited 2012 |
| ||
| Reading the stream until there's no info to read could be disastrous especially if you're using just one socket for all clients. Make a client type and pass the new connection socket to the client type socket. Then check each client socket once per cycle for a packet. Reading 1 packet per cycle from each player should be plenty to keep the game smooth. CounterStrike sends anywhere from 10 to 30 packets per second just to give you an idea of what's average for a commercial FPS. But of course it depends on your game type also. |
| ||
| I was thinking about that net-pgm thingy for the server side, where received data from client has to be resent to other clients without delay. Communication between net-pgm and game logic program using disk sounds like a real bad idea. Especially when Windows buffers disk I/O. I was originally thinking about UDP for this. I think it might be better than TCP since there's no change of packet loss (or is there?) and there's no need to send files (pictures or sound). It's a nuisance to do special programs to test only one thing, but I guess I have to because this affects the fundamentals of the multiplayer code. |
   |