On FreeBSD, some invalid input causes a core dump.

In order to accomodate different architectures, we must have a way to cater to both little and big-endian machines. This means using htons and htoni functions in a GIPS unpack function.

Be cool to have some tabs which have some interesting history and useful information about the game.

IE: "How to Play", "About", etc

Create threaded subservers.

We probably won't have time for any more clients than that.

Not sure whether to put this in part 2 or 3,

I still have the suspicion that sending ctrl-C in the client when the server is up (in a terminal) send the ctrl-C signal TO the server, and the server ends.

Need to read up on Beej's signal handling guide a bit more.

The FIRST PLAYER TO CONNECT should be the first player to move. Currently, no matter which player you are it tells you that the other player selected the middle piece. We could also just make it so that the board is smart enough to keep track of what color it's client is playing as.

Build the CLI with both a command processor and a translator from text to GIPS

It's a lot easier to build the game if you understand the rules.

right now one player will not know the other players move

maybe need two display boards

Ok, so, every programmer has their own style. But for the purposes of this project we should decide on one in order to maintain some kind of fluency throughout.

I feel like we have some of it down :
2space indents
Brackets don't have their own lines

Things we should figure out:
I feel like we should use camelCase but we have both been like, alternative between doing_something_like_this and camelCase
We should probably make that all camelCase as per most standards

Can't think of anything else that's different, but there probs is

PS - il fix where I made the brackets with their own lines :P

Client side, a waiting client should wait for a flag which means that the client has connected
the flag will be an integer.
should be set to:
isOtherPlayerConnected = FALSE.
at first
it should be blocking, IE
printf('Waiting for other player to connect...");
recv(sockfd, &isOtherPlayerConnected, sizeof(int), 0);
//\
Client Logic
////////
(recv is blocking by description)

For multiple games.

If the player has a uniquePID that's registered and wants to see it's wins/losses then they should be able to go

? info

or something like that and get a message back from the server with a player struct.

right now it just accepts two digits

Alright, in the server_v2 branch I broke something drastically. I sent a move from player 2 and neither player thinks it's their turn now.

The way it stands in this version, the last client to connect to the server perpetually receives the signal that it's the other player's turn. The other player can then send packets as long as he wants.

The server has to be restarted between every game or player 1 segfaults.

I tried to get the combination server/client to talk, and tested a few inputs. On "8 9" both the client and server segfault, leaving the other client running waiting for a response.

A lobby where Players can talk to each other, and share each others Unique PID's to play Gomoku against each other.

Create a Makefile that can handle producing built versions of all files.

Game Logic should be server-side, so that the client remains as lightweight as possible

Gomoku Rules:
Black always goes first, starting in the middle
first to hit five-in-a-row wins
once someone hits five in a row, server can send a message displaying who one, and close connection

Are we building one-player mode or two-player mode? B/C if one-player that means we have to build an AI to go with the game, too.

Build the communication protocol between client and server.

Rules for a truly dynamic server (I'm making this stuff up):

1. If a client disconnects, at any time, the server should remain persistant and be able to accept other incoming connections, setting up games.
   I've made strides with implementing a Linked List that keeps track of socket descriptors. I may need to go one step further and dedicate a thread which all it does is:
   1. check if a socket connection is no longer valid
   2. check if sockets are still up
   3. if a connection is no longer valid, delete the corresponding entry in the linked list
2. NEVER segfault, under any circumstance (duh)
3. Be as responsive as possible

I'll probably add more rules as I discover more bugs. The server is maaaybbeee 40% of the way there already.

This is of high priority, because it's basically the uptime of the server. I never want this thing to crash, ever.

Error: Socket operation on item that is not a socket descriptor or something like that.

If a client disconnects mid-game, the server should gracefully inform the client which is still connected that the player has disconnected, and disconnect this client as well.

In the future, when a lobby exists, this client which is still connected should be given the option of being thrown back into the lobby or to disconnect

It either lets both clients take turns at once or lets one continue indiscriminately.

Server-side issue needed to implement multiple games.

Make the first part into initGameLoop and the while loop into one function that either returns true or false

I re-read through his project description and it seems like our structure should be like this:

Instead of sending the name to the server, the client can send their Unique Player ID (Of their choosing) up to 15 characters. Server will parse it and check if it's actually unique. Once this is done, the player will get back a structure with their player data (wins losses etc etc whatever Bi wants)

N'd dats it

serverside I'll keep a LinkedList and write to it, seperate from GIPS and the shared variable data. IT will read from and write to a file on start and finish