• Advertisement

Archived

This topic is now archived and is closed to further replies.

Rakknet vs. OpenTNL

This topic is 5034 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Has anyone used Raknet or OpenTNL and have an opinion on which they prefer and why? I''ve used Raknet for some demo stuff and it was dead simple to use. I wasn''t doing anything too fancy so I didn''t come across any limitations that might exist. Eventually I will be writing a more complex game that will need important things like network security, etc. So I figured I''d ask and see what people think. Regards, Jeff

Share this post


Link to post
Share on other sites
Advertisement
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

  • Advertisement