SOLDIERX.COM Nobody Can Stop Information Insemination

here is my successor of my previous paper I had wrote with the topic of IRC. This one in general is better written and is focused on a more broader spectrum then the previous paper.

        As I promised, I am here writing my 2 paper on client sided programming.
In this paper we will discuss more general things besides focusing on just IRC.
Some things we will focus on will be general topics such as, what to expect of
the server, what users expect of the client, and what to expect of the client.

-What to expect from the server-

	Some questions may arise such as, “how do we know what kind of
information the server sends”, or, “what kind of commands can we send to the
server”. One thing that we will automatically need to know would be the port that
the server is running on. The reason for this is simple, telnet. The reason is
that we are going to telnet to the server on the port that it runs on, and read
the information that it sends us, so that we can have a general idea on what
kind of commands that the client will need to feed it. Another good resource on
learning about what kind of commands can be sent to the server would be google.
Lets say that you are wanting to connect to some game server with your client to
send the server remote administrator commands because for argument sake, you are
a moderator for the server. You will need to search the name of the server in
google similar to “name of server full list commands” or something along thoughs
lines. With all of the commands written down, or saved to a text file, it is
time to begin looking into what the user expects of the client.


-What user expects from client-

	The typical user is going to want a a client that will be simple to use.
They are also going to want it to accomplish the task given to it as fast as
possible. Some good practices would be to make the code work quick as possible
but be as secure as possible from exploits. Lets say that you have your commands
that you can give to the server. Some of these commands are user specific, and
some of them are moderator or administrator specific. If most of these commands
are extremely long, the user will most likely hate using the client due to the
fact that they will have to type more then they want into it. One good way to
combat this, would be to create some commands of your own. Make them simple and
short, so that the user will not be as frustrated with them as the original
commands. It would also be a good idea to link them short commands to the longer
ones. For an example I'm going to create an imaginary function to demonstrate.
Search for UserPID based on UsrName;

automaticly fill in UsrPID for user;

let user select KickWarn, 1 if warning, 2 if instant kick;

KickUser(char UsrName, int UsrPID, int KickWarn)

{

-w =KickWarn;

kick user;

}
	Now all the user will have to do would be to enter this command,
“kickuser Bob -w 2” for an instant kick instead of using “kickuser Bob -p218 -w
2”. See? There is more they would have to write so they will typically shy away
from that.


-What to expect from the client as a coder-

	Some things to espect from the client as a coder are simple. Mobility,
simplicity, and security are some things I myself keep in mind while I code.
Most people these days have either windows xp or windows vista. Or they would
like to throw the client on a flash drive and be able to use it where ever they
go. Being able to diversely program a client to work with both windows and *nix
and to have it work on any computer by either flash drive or disk drive Is what
a lot of people look for in the clients they use.

	Simplicity is something that all users of your client will want. You
will want to make it as user friendly and as simple to use as you can. The
reason for this is that if there is lets say for argument sake that there is
another client that does the same thing as yours but is more user friendly,
people will tend to go towards that client more then they will go for yours. You
have to always keep the user in mind depending on if you want this client to be
private or public. But even you yourself will want it to be easy to use once you
code it.

	Security will be something that is extremely important that you have in
your client. You or the users of the client will not want someone to exploit it
and take over the system. Maybe the exploit will not take the system, but it
could also alow administrative access to the server which is something you or
the admin will not want. One thing that any programmer should keep in mind while
coding a client, would be to double check the syntax of every little thing
possible, and to test each line in the code to make sure that it is non
exploitable. Then during run-time it would be best to throw other variables at it
that the client wouldn't normally expect to have thrown at it. Maybe it will
crash, maybe it will lead to an exploit. So a good idea would be to do this and
if you find that it crashes using one variable then add some code to counter act
that variable.

In General, try to design your client to your standards which will most likely
be everyone else's standards as well, quick and simple.