RakNet .NET

[Rick]

So RakNet's new version has a .NET port. I took that, compiled it and then also compiled the generated source into it's own .NET DLL. So all you have to do is put RakNet.dll in the same dir as your exe, and then add a reference to RakNet.Net.dll in your project. It's built with .NET 4.0 in VS 2010.

 

(just put this below dll in your exe dir. don't reference this one in your project)

http://dl.dropbox.com/u/1293842/RakNet.Net/RakNet.dll

 

(add a reference to the below dll)

http://dl.dropbox.com/u/1293842/RakNet.Net/RakNet.Net.dll

 

 

I also have in the works my own RPC (remote procedure call) system. Basically instead of sending messages back and forth between client/server and dealing with all of that, this system let's you "call" functions on the remote computer by name. It'll basically be as simple as deriving from a base class and giving the method you want exposed to the network a custom attribute.

[L B]

Why don't you use System.Net(.Sockets)?

[Rick]

RakNet can be thought as a level above System.Net.Sockets making life easier on the developer. It's an asynchronous UDP based system that handles staying connected and guaranteed packet delivery automatically for you. All you have to worry about is connecting, and sending data.

 

As you may know UDP is kind of like the only way to fly when making networked video games, but by default it's unreliable and not always connected. RakNet takes care of all that for you so you can just focus on sending data for you game.

 

It gives you the ease of using TCP with the benefits of UDP.

[L B]

For an action game, UDP is required. However, in the event of making a RPG, TCP suffices. I agree that an additional layer is useful for UDP though.

[Rick]

For an action game, UDP is required. However, in the event of making a RPG, TCP suffices.

 

You are right, but if a library encapsulates all the hard UDP stuff for you, then why not just use 1 library for everything? That's my thought on it anyway. Either way, I'm trying to make it even easier by being able to "call functions" on the remote machine instead of sending messages directly. That should make things slightly easier. Also need a replication system too. .NET should help a ton with both of these with reflection.

[L B]

Send a string (with a byte prefix of its length) of the method namespace and name, that should do it.

 

Server.Invoke("MyNameSpace.StaticClass.Foo");

 

Or, for parameters, make it a "params object[] parameters", get the type of the object, send the length of the array, etc. etc. Could all be relatively easily done, but I highly discourage it. If someone does any packet editing, he will be able to call any private function on the server.

[Rick]

If someone does any packet editing, he will be able to call any private function on the server.

 

Which is why it wouldn't be done that way

 

The methods won't have to be static. They will be able to be part of an instance, and the programmer will have to assign an attribute to that method and derive that class from a specific class in order for it to be callable. RPC is basically hiding message sending (the "normal" way of game networking) with some setup.

 

The parameter will be a RakNet BitStream object and the ip address of who sent it.