10 — This is it!

Due Thursday, 03 December 2020 Sunday, 6 Deccember 2020 , 11:59.59pm

Delivery Place the product of this week’s project steps into your repo as follows:

• for the Programming Task, place all code in the Remote/ directory, a new folder in Fish/;

  Add a separate README file to the folder. This file should explain the file organization of the folder. At this point you have seen how the code for this project is organized according to concepts (not artificial language constraints), and you should be able to match this kind of organization.

  Also, if you modify other pieces of code, describe these modifications in a separate section in this README file.

• for the Runnables Task, place all code in a repo-level directory named 10

Design It is time to complete phase 3 of our Fish.Com, a Plan. A complete distributed prototype will allow our angel investors to observe the site in action. They can then provide feedback on how we can make this enterprise even more profitable.

Your software architect has specified the Logical Interactions for Fish.com and has derived the Remote Interactions from it, including the remote-connection step.

Your task is to implement this server-and-client architecture. At this moment, your code base contains almost all the components needed for completing this task, though your building blocks may not use the same logical methods and protocol on top of them. This is a common problem. In response the OOD patterns community has developed the bridge and adapter patterns. Furthermore, your building blocks connect through regular function or method calls, not JSON-message exchanges. Once again, the OOD patterns community teaches us that remote proxies allow us to leave the logical parts of a software system undisturbed and to inject a separate remote-communication layer instead.When you touch software, you enbug it.

Programming Task You will implement a client and a server component.

The client TCP-connects a player to a server according to Remote Interactions.

The server awaits TCP connections according to Remote Interactions. It waits for some time (here, 30s) for at least a minimum number (here, five) of remote clients to connect and be represented as remote players. As long as there isn’t this minimum number of clients connected at the end of a waiting period, the server re-enters the waiting state (here, exactly once). The waiting period ends if the server has accepted a maximal number (here, ten) of client connections; this keeps the overall duration of a tournament to a reasonable amount of time.

When a sufficient number of clients are connected, the server signs them up with the manager and asks the latter to run a complete tournament; when the manager’s work is done, your server shuts down. If there aren’t a sufficient number of clients signed up at the end of the waiting period, the server shuts down without running a tournament.

Here are the specifics. First, xserver p connects with clients on the specified port. For our test run, xserver will ask the tournament manager to run all games on a full-sized 5 x 5 board (no holes) with each tile populated by 2 fish. When the tournament is over, the server prints a JSON array with two natural numbers to STDOUT: [w, cf] where w is the number of tournament winners and cf is the number of players that were caught cheating or that failed during the tournament run.

To make a test fest feasible, impose a one second limit on each call from the server side to the client side. This suffices for local-host TCP transactions. Our test harness will limit each tournament to about three minutes, which means a maximum of .4s 1s per interaction between referee and player.

Second, xclients n p ip launches n clients, which all connect to the server on port p at ip address. If ip is ommitted, the client connects to "local host" (127.0.0.1). Each client employs a standard player, that is, a player that uses the zig-zag strategy for placing avatars and the best-score-at-depth-2 strategy for moving them. If your chosen programming language supports threads, use those to run the players; otherwise spawn OS-level processes.