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.

Jasu, this is actually very easy.
You write a second program that does only the network thing (called here "net-pgm"), receiving streams of data from the net, and save them to harddisk.
The procedure is as follows:
1. let your Main Program start the "net-pgm"
After the start, the net-pgm loops looking for a request-file.
As long as there is none it runs hidden in the background doing nothing. And in its loop it controls if the main program is still running. If not it terminates...

2. in your loop of the main-program send a filedownload request to your net-pgm (this can be a file which contains url and savepath).
Now the net-pgm starts downloading the data from the web, while the main-program in its loop looks for a file called "done.txt" or so.
This file will be placed from the net-pgm when the data is completely saved to disk.

3. The main-Program loads the data from harddrive... and deletes the done.txt file... so both programs "know" that the request is finished

4. repeat as often as needed

Instead of using files it is possible to manage all this via TCP between the 2 programs, but when pictures and textures are needed from the web then they have to be placed as files anyway, that's why I nearly always used the "file-method".

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.