Networking is still kicking my butt. At the end of the previous post, I’d started what I refer to as “Network Round 4” and I’ve already retired that version. It actually temporarily became the “com.qubekwest.net.old” package (referred to just as “old” later) as a place to constantly refer back to it as I write what I now call “Network Round 5.” This has obviously taken a bit of work, but it isn’t really as horrible as it probably sounds, honest.
The cause of this new iteration of the network code is actually that I’d gotten pretty far with the previous version, and then realized that I sort of had no idea how to actually use it. Meaning, it probably worked, but I didn’t have any clean patterns to follow to use it in something useful. After piles of refactors to try to make it useful, I gave up. This in turn inspired a collection of interfaces that I wanted to write and that occasionally conflicted with names already in my networking code. The best solution I could come up with to make this as easy as possible was to strip the network code back to nothing as described above with the “old” package and start making new files in the “net” package that was now completely empty.
This creation of interfaces helped me to determine two things at the same time. The first was the things that a “user” of the network engine (which is actually other pieces of code, not people) would need it to be able to provide, and the second was the things that the network engine does that don’t need to be exposed to anyone else. Those results may be immediately obvious to other people, since that’s exactly what interfaces are supposed to do, but in this case it was actually supremely useful.
From the first category of “need to be able to provide” I knew that I needed a collection of methods that the server had to be able to do to actually be a server. For example, it needed to be able to send data to clients. What surprised me a little was the number of different ways I had to be able to send data to the client. My primary pattern is that I’m sending data from a specific source to a specific target. Other methods build on that concept for the ability to send updates to other users that are near me in the world. Maxing out the idea of sending to groups there are also methods for broadcasting a single piece of data from a specific source, but to all connected users. This covers things a server needs to be able to do for other pieces of code.
The second category of “don’t need to be exposed” included things like “accept a connection.” I initially put a method to accept a connection in the interface for a server, but then realized that there is literally no code outside of the network itself that would ever call it. If you think about it for a moment, you will probably realize that the method for accepting connections must be there, but that it will be called because of network traffic, not by some other piece of code. That means that it can really be a private method on the network server code itself and building the interface helped me to realize that.
There are several other interfaces as well. I’ve defined what it means to be a network worker thread, which is a piece of code that actually does the work of the server. There can be any number of workers in a server, and they each get incoming data handed to them if they want it. They can’t affect each other, but they all get a shot at doing something with the data as it comes in. There are also handlers that create a sort of call back structure that allows clients to send data to the server where a response is expected.
This whole ball of wax is being implemented with the Java’s NIO package patterns. I still feel it is vastly more complex than other ways of doing things, but I’m also pretty confident that the result will perform better with more people connected to the server than the standard socket approach would. I’m hoping that makes this all worth it. I’ve actually spent almost six months working on, researching, writing and rewriting, and generally being frustrated by the network code, so I sure hope so.