GSOC Day 2 – Fixing the Time Remaining Frame


Today was the second day of GSOC, and with the setup out of the way, I began to take stock of the code.

First, however, I had to push the merged branches, which went off without any major hitches. Feels good to have some official progress under Mithro’s “if it’s not in the repository, it doesn’t exist” rule.

The first thing I noticed when starting the client was an error on connecting to a server:

Traceback (most recent call last):
File “libtpclient-py/tp/client/threads.py”, line 192, in run
self.error(e)
File “<string>”, line 1, in <lambda>
File “libtpclient-py/tp/client/threadcheck.py”, line 7, in thread_check_callable
return func(self, *args, **kw)
File “libtpclient-py/tp/client/threads.py”, line 187, in run
method(*args, **kw)
File “<string>”, line 1, in <lambda>
File “libtpclient-py/tp/client/threadcheck.py”, line 7, in thread_check_callable
return func(self, *args, **kw)
File “./tpclient-pywx”, line 414, in ConnectTo
self.CacheUpdate()
File “<string>”, line 1, in <lambda>
File “libtpclient-py/tp/client/threadcheck.py”, line 7, in thread_check_callable
return func(self, *args, **kw)
File “./tpclient-pywx”, line 435, in CacheUpdate
self.EOTUpdate()
File “<string>”, line 1, in <lambda>
File “libtpclient-py/tp/client/threadcheck.py”, line 7, in thread_check_callable
return func(self, *args, **kw)
File “./tpclient-pywx”, line 442, in EOTUpdate
timeRemaining = self.connection.time(), time.time()
File “libtpproto-py/tp/netlib/client.py”, line 700, in time
return self._time(self.no)
File “libtpproto-py/tp/netlib/client.py”, line 708, in _time
p = self._recv(no)
File “libtpproto-py/tp/netlib/common.py”, line 464, in _recv
r = self._recvFrame(sequence)
File “libtpproto-py/tp/netlib/common.py”, line 295, in _recvFrame
return self._processFrame(sequences)
File “libtpproto-py/tp/netlib/common.py”, line 275, in _processFrame
self._error(p)
File “libtpproto-py/tp/netlib/common.py”, line 263, in _processFrame
p.__process__(p._data)
File “libtpproto-py/tp/netlib/objects/Header.py”, line 119, in __process__
raise ValueError(“Left over data found for %r: ‘%r'” % (self.__class__.__name__, leftover))
ValueError: Left over data found for ‘TimeRemaining’: ”\x00\x00\x00\x00\x00\x00\x00\x00”

I looked into the TimeRemaining.py file, and found that it was out of date. The tp04 protocol states that each TimeRemaining packet should include:

  • 32 bit unsigned integer, the Time to Next Turn, The time in seconds before the next end of turn starts
  • 32 bit unsigned enumeration, the The reason, Explains why this frame was sent.
  • 32 bit unsigned integer, the Current Turn, The current turn.
  • a string, the Turn Name, The name of the current turn. May be empty.

The code only looked for the first 32 bit integer, so, after learning how the specification worked, I expanded it to include the full packet data and the proper length.

It turns out that the frame objects have a “struct” member variable that holds a string representing their construction. It seems to be efficient, but a bit difficult to read or modify at first glance. The new string for TimeRemaining:

struct = “jIIS”

This means that there’s a semi-signed integer (positive or -1 only), followed by two unsigned integers and a string.

I spent the rest of my time today looking at another error, this one coming when the client attempts to get the game server list from the metaserver. The client receives a packet it doesn’t understand:

Exception in thread RemoteBrowser:
Traceback (most recent call last):
File “/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/threading.py”, line 460, in __bootstrap
self.run()
File “libtpproto-py/tp/netlib/discover/metaserver_browser.py”, line 45, in run
p, data = getpacket(data)
File “libtpproto-py/tp/netlib/discover/metaserver_browser.py”, line 10, in getpacket
p = objects.Header.fromstr(header)
File “libtpproto-py/tp/netlib/objects/Header.py”, line 90, in fromstr
return cls(*args)
File “libtpproto-py/tp/netlib/objects/Header.py”, line 53, in __init__
raise ValueError(“Unknown packet type %i.” % type)
ValueError: Unknown packet type 349.

Neither llnz nor mithro knew why a packet of type 349 (which doesn’t seem to be in the specification, so I suspect it’s a server-side error) would be sent. Unfortunately, the packet seems to be received before debug information begins to print, so switching debug printing on didn’t provide any more help.

I think I’ll let someone else look into this one, since it’s server-side. Tomorrow, I’ll be moving on to start looking at displaying the new DynamicObjects on the starmap.

The good news? With the merge of the branches complete, I’m now almost a week ahead of schedule.

Advertisements

~ by greywhind on May 24, 2009.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

 
%d bloggers like this: