On this page:
Remote Connection
Language Switch
8.11.1.5

C — TCP 🔗 ℹ

Due Sunday, 01 October 2023, 11:59pm

Motivation Your software architect has inform you of the overall idea—1 — The Plan, which makes it clear that the clients will connect over TCP to the server. Some TAHBPLs are better at TCP than others.

Purpose to explore the TCP libraries of the chosen programming language

also, to reflect on the language of your choice

Delivery You must deliver xtcp and Tests/ in a directory called C in your repository.

All auxiliary files must be put into a sub-directory called C/Other/.

Task Develop xtcp, a TCP server program. It permits a single client to connect. It then processes a series of JSON values on this TCP connection. The series can be arbitrarily long and there can be arbitrary delays between the arrival of the separate JSON values.

When a JSON value arrives on the input side, xtcp turns it into a string—according to the specification of A — JSONand writes this string out as a JSON string to the TCP output side. The next JSON value is guaranteed to arrive only after the result for the current one has been written. Once the client-in connection is closed, xtcp shuts down.

The program takes one command-line argument, an integer between 10000 and 60000 (inclusive). This argument specifies the port on which xtcp accepts connections. (There is no need to validate this number.)

Reuse Since the program’s functionality is the same as that of xjson from A — JSON, you are welcome and encouraged to reuse (parts of) your solution. The ideal reuse is a call to the relevant functions or methods of the original solution; copying the code is acceptable for an exploratory programming task.

Tests Create three tests for xtcp in the directory Tests/. You may re-use the validated test from your solution for A — JSON or create entirely new ones. All tests must be well-formed and valid JSON according to A — JSON.

Constraint No test file may exceed the size limit of 40Kb.

Remote Connection 🔗 ℹ

The netcat program—alternatively, ncis the best way to manually send JSON information from your shell to your server and retrieved it:

    [login-students] $ nc antarctia.ccs.neu.edu 45678

This command connects the computer it is running on (login-students) with the specified computer ((antarctia.ccs.neu.edu) on the latter’s port 45678. Once the connection is established, a user may enter text and send it across the “wire” with the press of return.

The following screen shot shows how you can launch xtcp on one machine (here antarctica) with port 45678 specified on the command line:

The screenshot is taken before a client connects. On a separate machine, you can then run nc to connect to the first machine:

Note how the two command lines specify the same port.

The nc command sends JSON arrays from login-students to antarctica.ccs.neu.edu, one at a time. To create the screen shot I copied and pasted the lines from above and pressed return. The server responds with the expected string. The inputs sent to the server and the outputs are interleaved, as specified above.

You can also run these commands on the same machine, using two terminals, which will mimic the workings of our test harness. Since many of your friends may try this at the same time on login-students, pick a random port number between 10000 and 60000 so you don’t interfere with each other. If all of you use the same port on the same computer, bad things will happen.

Netcat vs netcap

There exists a whole family of netcat programs.

The one on the Linux servers is nmap netcat and it satisifies all of our needs.

Macs may vary; mine had the nmap netcat preinstalled via the developer toolkit.

On Windows it is likely not pre-installed. Windows users may wish to visit the nmap site, download the ncat executable, and add it to their paths.

If your machine has the OpenBSD version installed, you may need to use the -N command-line option.

Language Switch 🔗 ℹ

Now that you have completed all exploratory programming tasks, you should reflect on your experience with your language and its tools. Here are some sample questions you may ponder, especially with respect to the (rather short and compact) solution that the instructors showed you in class. (1) What problems did you encounter with [the libraries of] your chosen language? (2) How easy was it to write unit tests? Run them? Check expression coverage? (3) Did the chosen IDE support the programming well? (4) In which way will the desired language fix the above problems? (5) How much time did it take to accomplish the exploratory tasks given how short the programs should be.

Once you have answered these questions for yourself, honestly ask yourself whether you still think the language is a good choice for a project that involves the explored aspects (and more).

If you wish to switch languages, write down a rationale: why you no longer like your TAHBPL (the above questions may be a guide); how you expect your alternative TAHBPL to remedy the diagnosed problems. Half a page per negative response suffices. Less is more. Address the memo to your section instructor, send it to him, and make an in-person appointment. CC the tech TA.