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

[laggyluk]

Trying to use it in my project just now, RNL could use some more (any) documentation

[paul_nicholls]

You rock as usual @BeRo

cheers,
Paul

[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