Linux is in fact a very good thing. Although, it doesn't have very powerful tools, its simplicity complement any disadvantage it has. For example, making a system call is just one line of code. Its default packages are so developer friendly that, I can compile code in any way I like easily. Of course, the pre-requisite is I understand the working of the system.
So basically what I want to do for my FYP is to turn off wifi for certain duration when command is sent over. It's of course a line of code to do that in Linux.
system('rfkill block wifi)')But before that, in fact I have to do many things. Here are some I need to figure out:
- send command from server to client
- simulate client packets when his wifi is turned off
- store sleep information and time on both server and client
- switch on and off sleep state on both server and client side
The previous guy who were doing similar algorithm actually left some code I can refer to. But it seems to me that his code is not so reliable. This is because he didn't do off-line packets simulation and he put sleep information inside the client connection structure. Moreover, he didn't discover the PVS algorithm, so I assume he didn't really understand the Quake3 code before doing anything. Though his code is unreliable I still benefit from reading his code in some way.
For example, Quake3's makefile is huge, and I really have no idea where to add my scan file in. His makefile did help figure out this. And he's also use SV_SendServerCommand function, this conform with my observation. However, he receive command at the wrong place and didn't acknowledge the command thus, will cause overflow hence leading to disconnection. So I correct this by putting command reception inside CL_GetServerCommand. So I have fixed the 1st problem.
The 3rd, and 4th problem seems easy for me, I should solve those first. Then I should attempt the 2nd. Hopefully, Quake3 code has implemented some function to do off-line packets simulation, so I can make use of it. Otherwise, I would be troublesome to do playerState update on my own.
It seems that these stuff is pretty easy to do, but that's not true. It really takes me a while to fully understand the Quake3 architecture. Michael Abrash's 'The Big Picture' did help me a lot. And I like what he said, "There are a million ways not to finish a project, but there's only one way to finish: Put your head down and grind it out until it's done." It inspires me when I feel frustrated.
There still lies a long road to go for my FYP. The goal is to make my algorithm work perfectly without any glitch. By then, I should have fully understand the Quake3 code. One part of Quake3 that pose great interest to me is the renderer part. I am only able to spend a little time looking at the render. Though it uses OpenGl, very few native gl functions are actually exposed. Or maybe, I haven't found the correct place to look at. I will look at that after this project.