June 1st, 2008
Here's something encouraging. I run this in Python...
...and the tpserver-cpp log says...
...most excellent.
Now I can move on to making it do stuff with administration frames. According to my milestones, that should be completed in about 3 weeks. Let's see if we can't make that move a little quicker.
On the flip side, I ran into a bit of a problem with logging to the administration client. An AdminLogger object is instantiated by each new AdminConnection, and added to the main Logger set. Problem is, AdminLogger actually needs to send LogMessage frames to the client, and the only way to send frames to the client is through AdminConnection! Obviously, this means AdminLogger needs a pointer to the appropriate AdminConnection object; in the current design, that means passing a pointer to this in the constructor and having the child access the parent, which sounds a little sketchy. On the other hand, the object relationships seem to make sense...
from tp import netlib
c = netlib.Connection( "localhost", 6925 )
c.connect()
c.login( "admin", "admin" )
c.disconnect()...and the tpserver-cpp log says...
2008-06-01 11:37:33 < Info > Accepting new admin (tcp) connection
2008-06-01 11:37:40 < Info > Admin client has version 3 of protocol
2008-06-01 11:37:40 < Info > Admin client on connection 7 is [libtpproto-py/0.2.4 ]
2008-06-01 11:37:49 < Info > Admin login ok by admin
2008-06-01 11:38:00 < Info > Client disconnected
2008-06-01 11:38:00 < Info > Closed connection 7...most excellent.
Now I can move on to making it do stuff with administration frames. According to my milestones, that should be completed in about 3 weeks. Let's see if we can't make that move a little quicker.
On the flip side, I ran into a bit of a problem with logging to the administration client. An AdminLogger object is instantiated by each new AdminConnection, and added to the main Logger set. Problem is, AdminLogger actually needs to send LogMessage frames to the client, and the only way to send frames to the client is through AdminConnection! Obviously, this means AdminLogger needs a pointer to the appropriate AdminConnection object; in the current design, that means passing a pointer to this in the constructor and having the child access the parent, which sounds a little sketchy. On the other hand, the object relationships seem to make sense...
This Week:
The administration protocol extension is now specified in the XML format using the protocol DTD. It uses some of the existing basic frames and most of the new frames are closely related to the Order family from the main protocol. This may not be the "final" specification, but at this point I think the only likely changes are additions.
Logging to administration clients is now fully working in tpserver-cpp. To resolve my previous conundrum, I ended up passing a reference to the AdminConnection object to AdminLogger via a setConnection function, similar to the relationship between PlayerConnection and PlayerAgent. Logging now uses an asynchronous message type similar to AsyncTimeRemaining.
Awaiting updates to libtpproto-cpp before starting the C++ CLI administration client, I've been evolving a little test client module based on libtpproto-py in order to send and receive administration frames and make sure everything is in order on the server side. So far, I've succesfully used it to test, as previously mentioned, everything in the connection up to "logged in" status, and more recently, remote logging.
There is now basic functionality for processing all the administration frame types after logging in on the server side, although at present none of it actually does anything other than some sanity checking.
All told, I'd consider this first official week a fairly productive one, considering I was completely offline for four days of it. Since I started with this project I've had endless distractions from the various other items on my plate; happily, I've still managed to keep pace with my milestone goals. I'm looking forward to putting in a lot more solid time now that most of that is behind me.
Next Week:
The main goal for next week is to develop something analogous to OrderManager for commands, although it probably doesn't need to be so complex. This object will centrally store the command set and descriptions, and provide functions for replying to request frames. At present, I'm thinking the same object will also be used to process incoming command frames, check validity, execute the commands, and form the command result frames.
Along with this, I'll keep expanding on my test client module to prod server-side functionality as it develops, and eventually some of it may end up in the tpclient-pywx single-player wizard and other Python-based stuff.
The administration protocol extension is now specified in the XML format using the protocol DTD. It uses some of the existing basic frames and most of the new frames are closely related to the Order family from the main protocol. This may not be the "final" specification, but at this point I think the only likely changes are additions.
Logging to administration clients is now fully working in tpserver-cpp. To resolve my previous conundrum, I ended up passing a reference to the AdminConnection object to AdminLogger via a setConnection function, similar to the relationship between PlayerConnection and PlayerAgent. Logging now uses an asynchronous message type similar to AsyncTimeRemaining.
Awaiting updates to libtpproto-cpp before starting the C++ CLI administration client, I've been evolving a little test client module based on libtpproto-py in order to send and receive administration frames and make sure everything is in order on the server side. So far, I've succesfully used it to test, as previously mentioned, everything in the connection up to "logged in" status, and more recently, remote logging.
There is now basic functionality for processing all the administration frame types after logging in on the server side, although at present none of it actually does anything other than some sanity checking.
All told, I'd consider this first official week a fairly productive one, considering I was completely offline for four days of it. Since I started with this project I've had endless distractions from the various other items on my plate; happily, I've still managed to keep pace with my milestone goals. I'm looking forward to putting in a lot more solid time now that most of that is behind me.
Next Week:
The main goal for next week is to develop something analogous to OrderManager for commands, although it probably doesn't need to be so complex. This object will centrally store the command set and descriptions, and provide functions for replying to request frames. At present, I'm thinking the same object will also be used to process incoming command frames, check validity, execute the commands, and form the command result frames.
Along with this, I'll keep expanding on my test client module to prod server-side functionality as it develops, and eventually some of it may end up in the tpclient-pywx single-player wizard and other Python-based stuff.
Profile
![[info]](http://l-stat.livejournal.com/img/userinfo.gif)
ezod- Aaron Mavrinac
- mavrinac.com