Rakknet vs. OpenTNL

I''m pretty sure Raknet has no analog for TNL''s higher level object management code (ghosting, scoping, prioritization). Also, TNL''s RPC implementation is far superior to what is provided in Raknet, in that it parses the argument list to the RPC and marshalls each element into the bit stream automatically. Plus TNL provides a security model, various forms of DoS protection and more.

** Disclaimer ** I wrote most of TNL, and have only examined RakNet for like half an hour.

Anything that uses RPC for anything low level (like state updates) is not likely to be useful for low-latency, high-interactivity games such as FPS-es or the more responsive RPGs. RPC semantics just aren''t what you want in a game state distribution protocol. Thus, if one of these systems ONLY provide RPC, then that would count against them.

Actually, that''s only true if you''re using RPC systems like CORBA or JavaRMI. They''re very generic and trades speed for usefulness in many cases (since they''re trying to give a seamless distributed computing environment, this is the Right thing to do).

On the other hand, TNL RPC calls are packed and sent as efficiently as anything else. (Speaking technically, they get turned into events and packed across the network in the usual manner. Typical time to propagate is one packet transmission. It just doesn''t get any faster than that.) TNL RPC doesn''t try to give you a seamless distributed computing environment - for instance, they don''t allow return values - so you get a huge speed and efficiency boost compared to Java RMI or CORBA.

Note that I said RPC _semantics_. This means that the procedure calls (may) return data and are always executed in sequence. The implication for what this does to code structure when you have a game loop to keep running is up to you to determine :-)

Sending a message with no return value and no blocking and no strict sequencing is *NOT* "RPC", but that''s what you want when you''re doing low-latency interactive multi-participant games.

It triggers the calling of a remote procedure, so I think it''s fair to refer to it as RPC.

But, yeah, it''s definitely not the traditional sort of RPC.

About your design; If I make two of your RPC "calls":

1) am I guaranteed to get two functions called on the other side?
2) are they guaranteed to be called in order?

I''d heard a few days ago here that TNL had some issues when used with the STL. Is that true, as far as you know?

---

"Sneftel is correct, if rather vulgar." --Flarelocke

hplus - You can specify per RPC what you want. If you want them to be guaranteed and ordered they can be that. If you want them to be unreliable or unordered, that can happen too. You can also restrict the direction of RPCs (client to server, server to client, or both) and support different versions of the same RPC call.

Er... I mean, yes.

sneftel - I believe we recently checked in a fix for our only STL issue. If not, the solution is also on our mailing list. It''s a very minor workaround.