Sockets - Client to Client...?

[Johnathon]

Hello everyone we are just trying to complete a grade 12 computer science program that will involve the use of sockets. It will be a chess game playable over a LAN connection. We are a bit confused as to how we are going to go about the connection though, any thoughts?

We currently found an example on the Sun Java website, which is related to a Server to Client Knock Knock jokes. However, when we ran it, the computer acting as the server did not actively participate in the enteries. We were hoping to have a chess game between 2 people, and not a person verses the computer.

You can find the examples on this page: http://java.sun.com/docs/books/tutorial/networking/sockets/readingWriting.html
There is 3 parts to the example, Client, Server and the Protocol.

Would a simple change to the code for the server solve our problem? What would be the best way for us to go about doing this?
Thanks in advance!

[DemonWasp]

The best way to go about this is to keep the server-client model that Sun shows you. There's one little thing you might be missing:

You can have more than one client per server!

In fact, for your Chess game, you should have two clients (one for each player), and one server. The server can, incidentally, be run by one of the clients' computers, and need not have its own window.

So to play the game, your players would do the following:

1. One of the players decides to host the game. They click on "host game" or similar, and a server starts; they are automatically connected to their own server, awaiting an opponent to play.
2. The other player clicks on "join game" and enters the IP address or the computer name of the other game, and his client connects to the other player's server.
3. The two play their game.

Now you only have to write two things:
1. A client program. The client program draws the board, interprets user input, and determines the move the player is trying to make, then sends that to the server.
2. A server program. The server program receives the movement instructions from each player (ignoring those given when it's not that player's turn), and evaluates the move before relaying the results to both clients and setting up the next move.

[OneOffDriveByPoster]

One side can be the server and the other side can be the client. There is nothing preventing you from having the move-checking logic on the "client" side of the connection. In fact, each side can check its own moves and prevent the user from making moves on the wrong turn. Each side can also determine what the result of a move is. There does not need to be any separate server code (except to establish a connection).

[DemonWasp]

Well, if you assume your players are all honest, there's no reason to have the server do the move-checking. If this is a school project or similar, that's definitely good enough.

But people are not honest, and often run a hacked or otherwise modified client. If you check everything on the server side, you can easily prevent hacked clients from getting away with that kind of nonsense.

Of course, validating movements can be done on either the client-side, the server-side, or both. Really, the best solution is to do it on both - particularly because you can just write the movement-validation code/class/library and just reference it from both server and client, since they're both just different collections of code from the same project.

I should clarify my suggestion. Player A, who will host the game, runs the exact same program as Player B. However, when he clicks on "Host Game", the application spawns a separate GameServer thread that acts independently of the GameClient that the player ends up seeing. When Player B clicks on "Join Game", the game just continues into GameClient without spawning the new thread. This prevents code duplication between the server and the client.

[OneOffDriveByPoster]

I still see no point in having an extra server to validate moves. It sounds like the Player A server and client validates moves (redundantly) in your suggestion. Player B is at a disadvantage. If servers and clients are equivalent (except for the initial connection): each side can check their own moves and the moves that it gets from the other side. If the local user makes a wrong move--tell them. If the remote system sends a wrong move--abort.

[DemonWasp]

I don't see how Player B would be at a disadvantage. The server, despite (possibly) running on Player A's machine, should be treating the two the same.

The server really doesn't have to do so much, but it does have to do it in parallel to the client, which is why I suggest doing it separately. Then it's just spawning a thread, not implementing your own kind of parallel-processing "solution".