CS4504 Project Solved

40.00 $

Category: Tags: ,

Description

Rate this product

Problem Statement

 

This is a group project. Each group will consist of three (3) students. Once your email addresses are determined, I will communicate with you the groups periodically. Alternatively, the Announcement and/or the Chat feature of D2L can be used to facilitate the communication within the group or use an online platform. Following is the specification of the problem.

Compile, install, and run the four (4) TCP program modules, which are in the Project Folder, to implement the following distributed system. In this system’s configuration, there is a wired sub-network of regular PCs and a wireless sub-network of laptops with wireless network cards. The nodes in the two sub-networks communicate through a CS- Router (within the CS Department) and a Server/Router, S. The Server/Router is any ordinary PC in the CS-Lab or a laptop. The Server/Router S code also implements a routing table which is built into the program as a part of the simulation.

To illustrate the idea, consider the following scenario. Suppose that a node M is to send a request or message to a node N (either in the same sub-network or in the other sub- network) and node N processes the request and sends a response back to M:

  1. First, node will M send a request to the CS-Router
  2. The CS-Router directs the request to the Server/Router, S
  3. Server/Router S’s routing table is looked-up to find the destination address of the

    node N. (A routing table may contain the IP addresses, port #s and interface-link numbers, or some combination of these, plus any other pertinent information.) In this solution given to you, a minimum number of information is contained in the routing table.

  4. Once N’s address and port number are found in the table, the request or message is forwarded to it through the CS-Router. A reply from N follows the reverse path. (You need not worry about the CS-Router and, for wireless nodes, the KSU-UITS Department wireless router which will relay the message through the intermediate stages.)

In this distributed system each computer node is perceived as a client as well as a server. To further aid your understanding of the problem, in the following diagram, Figure 1, the nodes have hypothetical port numbers xxxx (e.g., 9999) and the interfaces of the nodes are numbered to facilitate the mapping. You need to determine the corresponding IP-address using finger, nslookup, or ipconfig, or similar protocol for the clusters of PCs you select in the CS-Lab in order to generate the needed sockets in your program modules. In the given code for Part 1, these numbers and/or the symbolic names were either fixed (as strings) or hard-coded as IP-numbers or port numbers. For example, the S-Router (in the SThread code) has a fixed port number 5555. The accompanying User- Guide describes how, in this case, the addressing information is entered and used in the code. You can change these if you want.

CS-Router

Client/Server

Socket IP:1111

4

3 2

1

5

6

IP:5555

IP:2222

Access Point

IP:7777

IP:3333

8
7

9

10

IP:4444

Client/Server

IP:6666

IP:8888

Server/Router S

Socket IP:21212

Figure 1: A conceptual network of two subnets (a wired and a wireless)

What to Do and Turn In

Complete source code for the client-side, the server-side, the server-router side, and threading code are given to your group. Study these programs as a group using the inline comments and code walkthrough techniques. Compile, install, and run the four (4) TCP program modules. Select as many nodes as possible on both the Client and Server sides of the network to simulate a fairly good size solution to the problem. (See Figure 1) Having a large size network also makes the simulation results statistically significant.

Test your system with several strings/messages, audio and video files of your choice. Each text file must exist on any node which is designated as a Client. Make slight changes to the code segments, wherever necessary, to collect and analyze data for such parameters as average message sizes, average transmission time, average time for the routing-table lookup, and any other of interest, if not already built into the given code. Write a 5-10-page report of your findings including 1) tables of collected data from the simulation and statistics and 2) analysis and conclusions from the data. The servers (in either side) are coded to convert each lower case to uppercase in the case of strings/messages. Use several text files of varying sizes and content for variability. (See the sample Text-file in Latin.)

After testing your code with text-file, modify the code to verify successful transmission of audio and video files, by playing back transmitted audio or video (using the appropriate AV application) on the receiver/server side. Again, use several AV files of varying sizes and content for variability. This Part 1 is intended to be completed in two-to-three (2-3) weeks, working in teams of three. (See the sample User-Guide.) Follow the Rubric for submitting your final Report and a User-Guide – guidelines for running your simulator.

IP:9999

Wired sub-network

Wireless sub-network

What Next?

Having completed and understood an implementation of the Client-Server paradigm using TCP, we have demonstrated that any two clients can communicate using a server- router as a bridge. The threading capability allows as many nodes as possible to be spawned for dynamic configurability and scalability of the network. In Part 2, which is based on the Peer-to-Peer (P2P) paradigm, will be implemented for the next five-to-six (5-6) weeks thereafter. (See the Part2 specs file.) The goal of this mini-project is help reinforce your understanding of these distributed computing (programming) paradigms and protocols.

Problem Statement

PROJECT SPECIFICATION – Part 2 CS 4504 – Distributed Computing Due Date: See the Syllabus

Having completed and understood an implementation of the Client-Server paradigm using TCP, we have demonstrated that any two clients can communicate using a server- router as a bridge. The threading capability allows as many nodes as possible to be spawned for dynamic configurability and scalability of the network. This Part 2, which is based on the Peer-to-Peer (P2P) paradigm, will be explored for the next six (6) weeks.

Using the system from Part 1, the goal of Part 2 is to design and implement a P2P system based on the following architecture.

Client/Server

Client/Server

Sockets IP:1111

4

3 2

1

6

IP:2222

IP:7777

IP:5555

9

Access Point

IP:3333

5555

5556

10 8

IP:88 88

IP:6666

IP:8888

IP:4444

IP:9999

S-Router S1

S-Router S2

Wired sub-network

Socket IP:21212

Socket IP:21213

7

Wireless sub-network

P2P TCP – Links

Figure 1: A conceptual P2P Architecture

In the figure above, there are two clusters of user or client nodes. The desire is to have client-to-client or peer-to-peer TCP connections for direct communication, that is, without any intervening routers. However, this is not possible since the clients/peers have no knowledge of their respective IP addresses. This is where the Server-Routers (S- Routers, for short) come in. Each S-Router has in its routing tables ONLY the necessary routing information for all the clients/peers that are connected to it.

Now, suppose that a node N1 (in cluster/group N) desires to communicate directly with node M4 (in cluster/group M), then N1’s S-Router will be consulted with a message which contains sufficient information for this S-Router to use. The S-Router for group N will then consult (by way of messaging) the S-Router for group M about the wish of node

N1. Having node M4’s information in its routing table, the S-Router for group M has no trouble working with the S-Router for group N to assist in creating a newTCP link for the exclusive use by N1 and M4. How the two routers assist in creating the new link is a part of your design choice for this architecture. The two routers’ job is done, or become decoupled, once the IP addresses of both N1 and M4 have been passed on to ‘whoever’ creates the new link. From this point, N1 and M4 should be able to exchange messages or content information directly until they disconnect. This is the principle underlying most P2P systems such as Skype, Napster, Kazaa, and BitTorrent.

The IP numbers in Figure 1 are hypothetical. As before, use nslookup, ipconfig, or any tools on the PCs in the CSE Lab and/or your laptops you use in the configuration to determine the actual IP addresses. In the code from Part 1, these numbers and/or the symbolic names were either fixed (as strings) or hard-coded as IP-numbers.

What to Do and Turn In

Using this basic architecture, and the solutions from Part 1, design the P2P system described above to allow as many pairs of nodes (from both clusters/groups) as possible or at least 100 pairs to exchange messages or content data. As before, let a text message sent in lower-case be converted to uppercase and returned. You may replace the text-file with something more meaningful or practical such as videos and audio file. If so, then replace the ‘character-conversion’ logic inside the server-side code to reflect this new application.

Using the programs from Part 1, either in their original or modified forms, clone the S- Router code and modify the routing tables such that the nodes in each cluster have their IPs and other relevant information in the tables. Think of how a new pair of TCP sockets can be created between the pair of clients/peers. Think of this in the light of creating a new TCP socket for, e.g., N1, while it waits on its initial request to the S-Router for group N; and also how the S-Router for group M instructs node M1, for example, to connect to N1 using this new TCP link. Make use of the ‘threading’ code and be careful of creating several sockets and leaving them open (not ‘closed’) at the same time. You need to work this logic until it holds. Note that the S-Router-S1 and S-Router-S2 communicate using a pair of TCP sockets with port numbers 5555 and 5556 respectively.

Again, make sure your ‘test’ files exist on any node which is designated as a sender- Client/Peer. As before, collect and analyze data for such parameters as average message sizes, average transmission time, average time for the routing-table lookup, number of bytes/units of data transferred per unit time, average number of message drops (if any), and any other parameters of interest which is already built into the given code. Verify if the content type, text versus video versus audio, makes a difference in the system’s performance.

Write a 10-15 page report of your findings including 1) tables of data collected and statistics and 2) analysis and conclusions. Also, develop a User-Guide to describe how your system must be set up – compilation sequence, installation, and as a guide for somebody else to use/test your system apart from you; similar to the user-guide of Part 1 that was given to you.

The project is designed to be completed by the end of the term by working in teams.

  • ParallelProj-main-yaxw3r.zip