ID:36714
 
Keywords: c, net, networking, remoting
Once again I am having trouble deciding the best route to take to network a client/server interface.

To clarify, this is what I mean by each of the following terms:

Remoting: Creating remote objects/proxies on the client that you can call on from the server.
.NET Remoting: The System.Runtime.Remoting class library.
General Networking: The connection between two sockets, without reference to the objects being marshaled.
Marshaling: Serializing an object or its interface and sending it to the client.
Channel: An end point (IP and port) on the server to a single object to directly connect it to another object.
Proxy: The interface of an object stored on the client that does not contain the object values, but instead references the server's object upon requests.
Sink: Performs a task on a message before sending/receiving the raw message.


My problem is that I keep learning of new functionality in the .NET Remoting library, and it keeps thinning the line of whether or not it's worth it to make a custom remoting lib (which may take about a few weeks to a month more to polish) that duplicates the function of .NET remoting but is more customizable and has a priority towards multiplayer gaming.

Here is what this library needs to have (whether .NET remoting or my alternative):

  • Needs to transfer as few bytes as possible while not sacrificing security.
  • Needs to encrypt messages if the lib user specifies to.
  • Needs to authenticate senders.
  • Needs to be able to use TCP, HTTP, and UDP protocols.
  • Needs to handle almost everything for the lib user. The only thing the user should have to do is define a message, configure settings, and call a couple of methods.
  • Specifically, needs to handle synchronization, proxies, and delegating objects/tasks internally.
  • Needs to use as little processing as possible without sacrificing organization.
  • As a personal objective, needs to impress potential employers for me, whether through intimate knowledge of .NET Remoting, or through good large-project architecture and great knowledge of general programming.
  • Can't use more than a single port on the client and server.
  • Needs to be able to connect and send/receive data with clients made in other languages, such as ActionScript. It also shouldn't put that developer through too much trouble of creating a parser.



Now, here are the pros and cons as far as I can see them:

.NET Remoting:

Pros:

  • Does most of the internal work for you.
  • I'm not 100% positive, but because of its use of channels, I believe it would transfer the data in a more compact form.
  • Would demonstrate intimate knowledge of fundimental .NET remoting technologies to employers.
  • Less time to create, less headaches.


Cons:

  • Unable to customize many aspects for you, and the things you can customize are difficult to impliment.
  • May possibly force the user to perform more work to use the library.
  • Can't use UDP protocol, which is essential for high traffic gaming.
  • Although channels would probably make for less traffic, I can't let it use multiple channels and define more than one port on the client/server without sacrificing other fundamental qualities such as ease of use and not having to use 10,000 ports to run a game. So it might not actually send messages in a more compact form.
  • Does not easily allow you to send in configurations and forget it. A lot of hard-coding configurations is required.
  • It's hazy as to whether this can connect with external programs under a TCP channel and whether or not its messages would be hard to parse even if it's in SOAP.


Alternative Remoting Framework:

Pros:

  • Fully customizable. Given the time, I could duplicate all .NET remoting technologies, as well as add a ton more features.
  • Can use the UDP protocol.
  • Has a simpler implimentation for sinks.
  • Handles almost everything for the lib user.
  • Demonstrates a great knowledge of large project architecture and general programming practices.
  • Can easily communicate with clients made in other languages.


Cons:

  • Potentially could rise the amount of data per message by 100-200 more bytes, depending on if .NET Remoting is still compact when using only a single channel. I may be able to fix this, but I won't if it will force the user to do more work to use the lib.
  • Takes far more time to create.
  • May be difficult to synchronize and delegate objects and tasks. I'm not sure if it will be difficult, but I remember this as my largest problem with my last networking library.




So what do you think? Am I wasting my time making a large library as an alternative or is it the better route?
I've started tending towards using libraries in all cases. I generally dislike using libraries since they're normally laid out in a way which makes no sense to me and require you to have read a gazillion pages of documentation to do anything meaningful with.
The .Net stuff's quite good because it generally makes sense, plus the user doesn't need to download any extra libraries to use it (although this isn't exactly a major problem).

I'd say it depends on what you need. Using a prebuilt library would be preferable to me in all cases unless I absolutely positively needed a feature that they don't have.
If there's a killer feature you absolutely must have, and .NET remoting doesn't have it, then find a different pre-rolled solution, or roll your own.

If you can live with .NET remoting, then by all means go with that. The less code you have to write and debug and maintain, the better. And since it's a standard .NET library, there's no worries about dependencies.

One consideration. If this is a precursor step to something else, then it might make sense to build the something else on top of .NET remoting first, but sufficiently encapsulated so that you can easily swap in another remoting framework later. That way you can get something up and running quickly first, which boosts personal morale and allows you to ensure that you design works. It may turn out that the features you thought you needed weren't actually that important after all; maybe you don't really need UDP, for example. And if not, you won't have lost anything in implementation time - and as a bonus, you have a real live application to test your framework on from day zero.

I've been completely rewriting Mayhem Intergalactic's networking backend recently, and I'm glad I'm doing it. It was really something to see the whole networking system suddenly pop back up in its entirety once I'd debugged the last backend problem. =)
I wish I was programming on your level =(
Less wishing and more learning, then. =)
You should just go with whats a win win situation out of win or failure. Doing more then one can be more time comsuming but learning always expains your options.
Kunark, I got time to actually help you make a game and more. I want to do it this time, i want to make a name for myself on byond. We can do it togher or ima do it myself either way ima prolly going to buy alot of books and devote alot of time to making it happen. so ima leave my byond pager up 24/7 u can page me anytime.