1 reply to this topic

[Ronchon le Nain]

Greetings,

I'm having trouble receiving messages on my client.
Sometimes ( seems to be when a lot of messages are received at same time ), it's like there is a blackout where no message is received for a while ( a few steps), even they've been actually sent correctly by the server.

As i don't really understand fully what the 39dll functions do, i have a few questions.
In all exemples i see, listenning to messages is done via doing a while loop with a receivemessage function in it. Then, if there is no message, the loop is broken and the program continues reading the code.
This loop is therefore executed once per step. Then what happens if the message is received at a moment when the program is not in this loop, but doing something else like reading the drawing event of some random object for exemple ? I guess the message is "stocked " until the receive message loop is executed again at the next step ?

Now, creating a large ds_grid or running a script can make the game freeze for few miliseconds. What happens if a message arrives at that moment ? Is it stocked until the receivemessage function is executed again too ? Can it be that messages received during such a freeze might be lost ?



As info, this is the code where i listen to messages on clients, in the step event of an object handling the online part :
What makes me beleive my client doesn't receive the messages is that, as you can see there, any incoming message is written in a log file and when the 'blackouts' happen, message that have been sent by server don't even appear in that log, meaning no message was received... When the blackout ends, things go back to normal. Blackouts seem to last about half a second.

if connected = true
{
while(1)
{

// Incoming commands
// -------------------------------------------------
// 1 -- Recieving any messages from server

  size = receivemessage(servertcp, 0, buf_in);            
  //If no message then exit the while() loop
  if(size < 0) break;
  //If socket was closed gracefully                       
  if(size == 0)                             
  {
    instance_destroy(); //Then disconnect
    break;              
  }
            
            file_text_write_string(global.events_log, "-------------------------------------")
            file_text_writeln(global.events_log)
            file_text_write_string(global.events_log, "           Message received")
            file_text_writeln(global.events_log)
            file_text_write_string(global.events_log, "        Buffer size ="+string(size))
            file_text_writeln(global.events_log)


   
// 2 -- Executing command asked by incoming message
.......


} 
}

What could possibly cause messages sent by server not to be received by client for a while (because i checked that the messages are actually sent by server )?
Could it be because of this, that i found on the topic of Http Dll 2 ? Cause it sure looks like it...

The DLL also fixes an annoying bug/feature in 39dll that can cause data to be lost. With 39dll, the maximum amount of data that can be recieved as a whole is limited by the operating system. Windows will only buffer a fixed amount of data, e.g. 64KB. This might not be enough if you're trying to send large files. If too much data is buffered by the receiver, the sender has to wait to send more data. Since 39dll's sendmessage function doesn't wait, part of the data is lost if too much data is sent at once. This DLL does additional buffering to avoid this problem, so no data is ever lost. You can buffer as much data as you want on both the sending side and the receiving side.

Edited by Ronchon le Nain, 28 November 2011 - 11:12 AM.

[Medusar]

Strange... lost messages. Should not happen.

they've been actually sent correctly by the server.

How do you know this for sure?

I guess the message is "stocked " until the receive message loop is executed again at the next step ?
[...]
Is it stocked until the receivemessage function is executed again too ? Can it be that messages received during such a freeze might be lost ?

When the computer receives a message, it sends the message to a buffer for the program to read. This buffer is not emptied until the program responsible for it empties it, aka you call the receivemessage function. So yes, all messages received are buffered (by the OS, not by your program). Whether or not your program happens to be busy at that particular time is no problem. If the buffer is full, problems might arise.
This OS buffering thing is also the reason why you use a while loop by the way. The client may receive more than one message in a single step, so it may have more than one message in the buffer. You therefore want to read the entire buffer every step.

What makes me beleive my client doesn't receive the messages is that, as you can see there, any incoming message is written in a log file

Nah... whether the program is busy or not should not matter.

when the 'blackouts' happen, message that have been sent by server don't even appear in that log, meaning no message was received.

Yeah... wonder why. Lost underway??? You appear to be using tcp (not udp) so that's unlikely... though TCP is slower than UDP that doesn't account for half a second.

Could it be because of this, that i found on the topic of Http Dll 2 ? Cause it sure looks like it...
<snip quote>

It's unlikely to be a buffer overflow. You clear the buffer once a step so it should never reach that kind of size. Or you should be trying to send some rather giant amounts of data all at once.

Question: does the client's game still run (aka does it still execute steps), or is it stuck in some kind of loop every once in a while? That could account for the half-second lag more easily. Not for the lost messages.

What kind of connection are you on? Loopback (both server and client on the same computer), local area network (server on other computer on your home network) or internet (server on some remote desktop)?