In this task, you will solve a concurrency problem using the key concepts: Processes, inter-process communication, client-server model, network programming, sockets, managing asynchronous i/o

The problem

You are to write a server and the client processed to act as a dealer and players for the card game, Black Jack. For the purposes of this assignment we will be using a simplified version of the rules for the game. These rules are to be realized in the server (and dealer) with a specific protocol which will allow ANY client process that also implements the protocol to connect to your server and play the game.

* Criteria that your server should satisfy include:

The server should be accessible from both local and remote sites. This means that the dealer and the player processes may reside on different machines, provided that these machines are connected by the Internet.

The master socket to which clients will connect should use port number 2000 + the last three digits of your student ID. For example, if your student ID is 223456, you should be using port number 2456. This port number should appear in the header of the document that will accompany your solution.

Busy-waiting must be avoided.

The server must support the protocol outlined below.

The protocol

The game is played in "rounds". At the start of each round a number of player connections are accepted by the server, and a hand of blackjack played with each in accordance with the rules provided.

The server initiates a round by accepting the first available connection from its master socket. Player processes connect to the server to express their willingness to participate in the current round.

When a player first connects, it sends the server the magic word PLAYER. This word indicates to the server that this is an actual player that knows the rules of the game (and uses the correct protocol). A player that doesn't send this word within 5 seconds should be disconnected (its socket is closed) and ignored. Once the first player is authenticated, the server should proceed to accept additional players in the same fashion until:

  • a total of 4 players have been accepted (initial + 3 more) OR
  • 30 seconds have elapsed since the first player requested a game, at which point the "table is closed". The round then commences with the available player connections.

Once a set of players have been accepted as outlined above, the server should fork off a child process to execute the dealer process that will play the game with the connected players. The server should wait for the dealer to finish the round (child process terminates), at which point it should begin collecting players for a new round, and the process repeats itself. Note that the master socket is never closed.

The dealer begins by sending each player their cards, followed by the single visible dealer card (see format below). Note that the dealer will have up to 4 hands of its own (one for each player it is playing against). As soon as a player receives this information, it may begin playing its hand in accordance with the rules. Specifically, a player may send the message "HIT", to which the dealer will respond with another card (same format). Alternatively the player may send the message "STAND" to indicate that they are satisfied with their hand. If a "hit" results in the player going bust, the dealer disconnects the appropriate player connection after "dealing" (sending) the card---the dealer automatically wins that hand. Note that the dealer is aware of this since it can keep track of the player's hand,

Important: The dealer must process players' requests as soon as they are received; the dealer will have to monitor all connections for data simultaneously, rather than process them in round robin fashion.

Once all players have either chosen to stand or gone bust, the dealer plays the hand it is holding for each remaining connected player according to the criteria specified in the rules. Each card the dealer draws is sent to the player in turn (as noted above). Once the dealer either stands or goes bust, the respective player connection is terminated and the dealer moves on to the next player (if any). Note: since the player knows all cards played, it is capable of determining the outcome of the game for itself.

Once the dealer has completed a hand with all players, or all connections have been terminated, it exits tt round is finished.

Players keep track of their own bets and do their own book-keeping with regard to wins and losses.

Format of cards and messages: Cards are represented by a sequence of two char's. The first char is the ASCII value of the card: { 2, 3, 4, 5, 6, 7, 8, 9, T, J, Q, K, A } (note that we define "10" to be "T" to allow every card to be represented by a single character), the second is the ASCII value of the suit: { S, H, D, C } (for example, player's cards: 7 of Hearts, 3 of Clubs, together with the dealer's visible card the Ace of Diamonds ,would appear as the stream of characters: 7H3CAD.

Messages are passed as ASCII text, terminated by a null byte ('').

Caveat

The dealer should operate correctly in the face of possibly misbehaving players. In particular, if a player terminates unexpectedly or sends a message that doesn't conform to protocol rules, it should be disconnected. You may assume that a player is terminating if it doesn't respond with its "STAND" or "HIT" message within 5 seconds (except after the player "STAND"s of course). This 5 second limit should be applied to each connected player individually.

Example

An example of an exchange between a player and the server/dealer for a single hand (from the player's perspective) might go something like this:

connect to server - send "PLAYER"
receive: 7H4DAH

my hand: 7-hearts & 4-diamonds (value of hand = 11, dealer has Ace-hearts showing)
send: "HIT"
receive: 9S

now have: 7-hearts, 4-diamonds, 9-spades (value of hand = 20)
send: "STAND"
receive: 3C4H, further reads indicate EOF (i.e. connection was terminated)

dealer had A-hearts, 3-clubs, 4-hearts, and (as per the rules) stood on 18 - I win!!!
Academic Honesty!
It is not our intention to break the school's academic policy. Posted solutions are meant to be used as a reference and should not be submitted as is. We are not held liable for any misuse of the solutions. Please see the frequently asked questions page for further questions and inquiries.
Kindly complete the form. Please provide a valid email address and we will get back to you within 24 hours. Payment is through PayPal, Buy me a Coffee or Cryptocurrency. We are a nonprofit organization however we need funds to keep this organization operating and to be able to complete our research and development projects.