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:
- 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.
- 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:
- 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.
- 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?