BaK's Rambling...

[★ Bak]

winnar

[★ Bak]

http://img.photobucket.com/albums/v622/bak2007/disc_tease_6_26_09.png

 

I'm pretty sure I just finished the client-side anti-cheat. It basically records all interesting events into a log that it can replay to make sure the reported state matches the calculated state. All that's left now is for the server to make sure that the reported state (position packets) in the log correspond to actual packets the server got/sent, as well as actually replaying the log (either on another machine or on the server, not sure yet). Here's the list of interesting events it records:

 

enum EventType
{
TYPE_SHIP_CHANGE, // player changed his ship
TYPE_NEW_KEY_STATE, // player pressed / released some keys
TYPE_TICK, // advance time
TYPE_SENT_POSITION_PACKET, // position packet sent
TYPE_TIMER_SYNC, // server <-> client timer synchronization
TYPE_SHIP_CHANGE_REQUEST, // player requested ship change
TYPE_OTHER_PLAYER_ENTERING,
TYPE_OTHER_PLAYER_LEAVING,
TYPE_OTHER_PLAYER_CHANGE_SHIP,
TYPE_OTHER_PLAYER_CHANGE_FREQ,
TYPE_OTHER_PLAYER_POSITION,
TYPE_OTHER_PLAYER_WEAPON,
TYPE_FREQ_CHANGE,
TYPE_SELF_DIED,
TYPE_OTHER_PLAYER_DIED,
};

[★ Bak]

if your dynamically loaded dll segfaults on initialization, attempting to load it through LoadLibrary will fail (as if it the .dll doesn't exist). It doesn't segfault and crash as expected, LoadLibrary just returns 0. The Error returned by GetLastError() corresponds to error code 6 = "The handle is invalid"

 

... and I thought my compiler gave up

[★ Bak]

when I start a project initially it's like 75% coding, 25% debugging...

 

with a project like Discretion it's like 20% planning, 50% reviewing code to make sure assumptions are correct, 10% coding, 10% debugging, and 10% undoing work that I thought was correct but turned out to be misunderstood assumptions about earlier code

 

I suspect this is not abnormal. Are there solutions?

[★ Bak]

n*10/10 != n

 

half a day...

 

fuck

[⛊ Drake7707]

n*10/10 != n

 

half a day...

 

fuck

 

integer division ?

[Dr Brain]

Uh, it should be, unless you're overflowing. The truncation won't come into play for that example.

[Kilo]

Unless he's still messing with non-integers

[L.C.]

n*10/10 != n

 

half a day...

 

fuck

I ran into one of those about a month ago and ranted about it on HardForum against Casio calculators and how I never have problems with those equations on TI's.

[★ Bak]

unless you're overflowing

 

it was the server time... which the server sends in centiseconds as a u32... I wanted to store things internally in milliseconds in Discretion, but then in the packet timestamps you need to reconvert back to centiseconds.

[JoWie]

Have you thought about client side scripting? I would think Mozilla SpiderMonkey (ECMAScript / JavaScript) is well suited for that purpose (used internally by firefox and flash). V8 seems like a good choice too (written by a guy named Lars Bak, hah)

 

It is perfect for making sure servers can not use nasty code.

[★ D1st0rt]

It's pretty easy to embed the mono interpreter as well

[Cheese]

i hear mono is good

[Yupa]

/me headdesks

[L.C.]

Doesn't Snrrrub use mono on his projects? Go for it.

[JoWie]

As long as it has good privilege separation

[Kilo]

I think there was talk of some sort of signing to run native code? Remember, even a scripting environment doesn't completely eliminate risk. Ideally, even client side scripts would be signed.

[★ D1st0rt]

they have a pretty good sandbox setup for moonlight (their silverlight implementation) so you could probably use that if you were worried

[JoWie]

this is why I suggest spidermonkey. it is used by firefox for web applications. finding an exploit is very hard (and if you do, you can get $3000 for reporting it). As long as the API does not expose anything dangerous i would say it is very secure. You could still add a sandbox to prevent any exploits going up to the OS (like chrome does).

 

Having to sign client side scripts seems incredible frustrating to me.

[★ Bak]

what sort of scripts were you thinking of writing that require a full-blown client-side scripting language?

[JoWie]

I was not thinking along the lines of a server delivered module that introduces entirely new functionality (for example joystick support). But intended it to offload all the hackery that is normally done on the server using lvz to the client.

A good example would be a graphical interface for a store such as in hyperspace (page flipping, page scrolling, resource cost, item descriptions, fancy pictures, etc). Using the current lvz system this is very inefficient and annoying to build. With simple scripting this works a lot better.

For such tasks, the signed module method seems horrible.

[Dr Brain]

I personally think that signing should be used throughout the protocol. Everything could benefit from this, the biller, the game server, the client. Even the directory server might have some minor benefits.

[★ doc flabby]

I recommend using LUA. Its a great scripting engine and can be sandboxed easily.

[★ Bak]

Worked on getting the new digital signing in. I figured I would work on the automatic updater first, so that's where I started. Apparently the people at zlib have got a few more newer versions of the library out, but they no longer release pre-built binaries, just the source code, which is bad for windows. They also decided to delete the .zip files of the old versions off their server, so I had to scramble before I found a version in the libpng sourceforge page.

 

Also, looking at the automatic updates, it was off a windows batch script and then a lot of hardcoded paths... not very well designed. I am redoing a lot of it now to have a much cleaner design (hopefully). It will use a regular bash script to do all the work, and then the main program shouldn't need so many hardcoded things.

[★ Bak]

Debugging for the last two days (not my intention, but I found a bug which needed to be fixed). Here are the symptoms: crashes (segfault) occur at random after some time. gdb indicates this happens usually in 3 different places, but sometimes happens elsewhere.

 

No much to go on. I tried the standard things, using debug symbols and seeing where it was crashing using gdb to infer the error. However, it would happen in the most innocent places, and behavior would be unbelievable.

 

After further investigation (meaning hours and hours of hitting my head against the desk), I realized it only happened after I fired bombs. Not guns, but bombs. The code is almost exactly the same, save for the different animation and different settings. Why did this matter?

 

 

 

I had added this feature recently (meaning a year ago), where particles (bombs had it enabled) could have 'targeters', essentially like a trial showing you where the bomb was going so that you could potentially dodge it. This was all well and nice and seemed to work well. It was implemented as basically whenever a bomb was fired it would create another particle from the same spot with an existing time of (fired time - 1000ms), so that it would appear 1000ms ahead of where the bomb was. This worked well. When the bomb hit something, though I needed a way to make sure the targeter particle also stopped being drawn, since if they were by themselves it would be strange. So I added a pointer to the targeter inside the particle struct. Then if the particle was hit I did:

 

 

 

if (p->targeter)

   p->targeter->millisecondsLeftAlive = 0; // will delete it almost immediately

 

 

What I didn't take into account was that the targeter might expire before the particle did, so that this had the effect of writing 0 to freed memory, which on occasion was already allocated elsewhere for some purpose. This explains random crashes in many places which make no sense.

 

anyways, I'm EXTREMELY frustrated at this, but glad to have found it. The lesson is when you debug memory corruption, you can't look backwards from the results (start with the crashing location and work your way back, which I spent many hours doing). You need to instead forwards: figure out how to reproduce the problem and start commenting out code until it goes away, then comment out less and less until you find the culprit lines.