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