Onychohumasia (That’s Right)

Cloned a few of the Git repositories for Thousand Parsec yesterday, and spent a good chunk of today getting to know tpserver-cpp from the inside. It was one of the easier bits to write an ebuild for back in March, so I covered that ground again by compiling it directly. I messed around a bit with running the server locally under different config options and connecting to it with the release version of tpclient-pywx. Reading the included sample configuration files, the protocol specification, and various pages on the Wiki also helped.

One nice thing to find out right off the bat is that tpserver-cpp supports a variety of logging options including syslog, which I originally thought I might have to implement myself as part of separating out the console.

Next thing to look at is what the initial configuration and console are calling internally, and how. I want to separate configuration into what must remain the same during the server’s lifetime and what can change. I’m also looking into allowing the server to toggle into an ‘off’ state (perhaps using the back end of the game-start and network-start options) where the static options can be changed for, say, a new game, without requiring a server restart. This way, you could give multiple people configuration privileges on a server without accounts and trickery on the actual host machine.

So far, it looks like the best way to implement the configuration protocol is in parallel to the existing TP protocol. There’s a lot of code (authentication, TLS, tunneling, etc.) the TP protocol already uses, and there’s no immediately obvious reason why the configuration protocol couldn’t be done similarly so as to reuse it and provide the same sort of functionality. It remains to be seen whether it makes more sense to lump it onto the same port, with users having different privilege levels, or to put it on its own separate port.

Consider this a standing invitation to my mentors and fellow students to jump in and comment on any of my posts. Am I on the right track? Have I misunderstood something? Am I reinventing the wheel? Am I getting carried away? The more feedback I get, the better. Either way, I’m sure I’ll be hammering everyone with questions soon enough.

Apr 23rd, 2008
  1. Anonymous
    Apr 24th, 2008 at 04:17 | #1

    Right track

    It would be the track I would take, as I mentioned the other day on irc. Using the existing protocol and extending makes the best sense I can see.

    [Who needs to get openid working]

  2. Anonymous
    Apr 24th, 2008 at 11:52 | #2

    Lee’s first comments

    I hope you find tpserver-cpp usefully flexible. :-)

    On advantage of having a separate port for config protocol is that you can use the listen socket to control who can connect. For example, it could be limited to localhost, without having to check the IP address.

    I hope you find that libtprl is straight forward and you can understand how the commands fit together. I haven’t yet had time to implement a second set of commands to help guide the server admin through the setup of the server.

    In terms of the protocol, you could reuse the current TP protocol, if it is not too different from what you need. I would suggest creating a page on the wiki and writing down what the protocol should do, which end(s) sends data, what data flows where, examples, etc. You should use the existing infrastructure in tpserver-cpp, such as the Connection class for receiving network events, etc, where it is available. Gnutls will soon be required to build tpserver-cpp, so you don’t need to worry about that.

    (also needing to setup openid)

Comments are closed.