RNL - Realtime Network Library - The opensource reliable UDP network lib for games

[laggyluk]

Hey, I've been using your library to communicate between two programs. One is made in Delphi, other in Lazarus.
Code is pretty much taken out of provided example and modified to use 'real' network instead of virtual.

It works reliably but I'm having a slight problem, each time I send something to other program it takes about a second or two to arrive (on same machine).
Any idea what can cause such delay?

Sending looks like this:

procedure ServerPing;
var
  buf:TBytes;
  i: Integer;
begin
  setlength(buf,1);
  buf[0]:=byte(mtPing);
  log('ping');
  chrServer.Server.BroadcastMessageBytes(reliableChannel,buf);
end;

and receiving looks like this:

RNL_HOST_EVENT_TYPE_PEER_RECEIVE:begin
        //ConsoleOutput('Server: A message received');
buf:=event.message.AsBytes;
        case eMessageTypes(buf[0]) of
          mtPing: log('pong');

Besides that, handshake error when one program is compiled as x86 and other as x64 is expected?

[BeRo]

Hm, sounds like compiler-related problems, because I myself have no problems interconnecting 32-bit x86 and 64-bit x64 builds, see:



Even i did noticed no problems at interconnecting 32-bit ARM builds (Delphi Client-Side on Android), 32-bit x86 (Delphi Client-Side on Windows) and 64-bit x64 builds (FPC Server-Side on Linux and Delphi Client-Side on Windows) in a commerical project, which's using RNL.

So which exactly for compiler version you are using, and exact which compiler parameters? At FPC you should disable the higher code optimizations, because FPC have often code optimizer bugs, so please test with "-O- -O1" as compiler parameters for to force the lowest code optimization level. And could you give me a example project with sources and binaries, so that I can investigate the problem in a better way?

[laggyluk]

My project uses bunch of external libs but I'll try to make slimmed down example

[laggyluk]

Here it is:
https://www.dropbox.com/s/742wy18m2u...debug.zip?dl=0

No connection error anymore, this time I didn't copy any defines from your example, probably that's the reason.

Still 1 second lag remains, hope you can help me out. Use button to send 'ping' from delphi to laz.

[BeRo]

So, it seems that you're calling RNL broadcast message calls from a different thread than the actual RNL thread, but that is wrong, you do to need all call in the same actual RNL thread, but if you set the Server.Inteerruptable to true, then you can interrupt the RNL event wait timeout in the actual RNL thread from a another thread with Server.Interrupt. so that the actual RNL thread can process for example your own threadsafe message queue without any delay, but the more recommending is not to use the interrupt feature (because Windows, Linux and Android are no realtime operating systems, so there can be always latency-jitter in their thread context switch processes, which can be up to multiple 10ms in extreme really-full-CPU-load cases) and instead to set the event waitout lower from 1000ms to 10ms, 1ms or even with 0ms, if you will mixing the RNL thread and rendering main loop thread into one single thread, so that for example the Monitor VSync or something other in your graphics rendering process would overtake then this save-CPU-load-waiting.

Summary: RNL is single-threaded, so you should use a RNL instance always only in the same thread, either together with your own threadsafe message queues (for example based on my PasMP project), or merge more stuff into the same thread.

See my changes at

https://vserver.rosseaux.net/stuff/rnl_debug_pgd0.zip in your code

and my video at

[laggyluk]

Server.Inteerruptable sounds like a solution to my problem.

If I'd integrate it to main loop, wont' it stall everything for duration of timeout? Setting it to 10 might be fine when running both programs on same machine but if it's connected over the inernets won't that drop packets that take longer to travel or some other side effect?

Thanks for your time.


By the way, another example project in repo for 'real use' scenario wouldn't hurt With two programs connecting and without all the extra code for network debugging.

[Matthias]

Amazing project and contribution!