C语言代写 | Distributed Tickertape UCL CS 0133


Individual Coursework 1: Distributed Tickertape


The City of London has hired you to prototype an alternative, more decentralized stock exchange. The City intends that each stock broker put a computer on the Internet that runs your ticker server. Whenever a broker buys or sells stock, the broker will submit a short description of that trade to the local ticker server. The ticker servers will exchange information about all trades, and each server will print out the description of every trade submitted to the system.

A key requirement is that all the servers must print out the trades in the same order. Any broker will be upset if it seems that he is not being given the same information as every other broker, because brokers make decisions about what to buy and sell based both on the latest prices and on price trends.

The larger purpose of this assignment is to learn about protocols for maintaining replicated data. If you have some data (a file system, for example) with identical replicas on a number of servers,  you might want to perform updates on that data in a way      that keeps the replicas identical. If you can arrange to perform the updates in the same order on all the replicas (and the updates are deterministic), then the data will remain identical. An important part of achieving this goal is making sure all the replicas process the updates in the same order. That’s what you’ll do for this assignment, though under an unrealistically optimistic set of assumptions about network and failure behavior that simplify the problem.



Your server will take command-line arguments telling it its own port number, and the host names and port numbers of all the other servers in the system.

We supply you with a client program that submits new trades to the local server, using RPC. Each trade has a text tag. When a server sees a new trade submitted by a local client, it should tell all the other servers in the system about the trade. How this happens is up to you. We supply you with a prototype server that uses RPC (over UDP) to talk to the other servers; we suggest you start by modifying this server.

A server will receive notifications about trades from time to time from other servers. It should print each trade’s tag on the standard output (i.e., using printf). All the servers should print the trade tags in the same order. The servers need not print the tags immediately when they arrive.

Here are some other rules you must follow:

Every live server must print out a trade within 13 seconds of when it was originally submitted by a client.

Your system must continue to operate even if some servers die (which you can sim- ulate with ˆC). Dead servers are not required to print trades. If a server originates a trade but dies less than 3 seconds later, other servers are not required to handle that trade correctly.

We will test your server with the client program we supply, so you should not change the submit RPC interface.

Your server must work when more than one server runs on the same machine (with different ports), and when servers run on different machines.

  • Except as noted above, all servers must print all trades in the same
  • Your server must pass the test-ticker tester program (see below).

Here are some slightly unusual things you are allowed to assume about the system:

If a computer or server fails, it will never come back toYou are allowed to assume that the network will deliver your RPCs within three seconds of when you make them, as long as the sending and receiving hosts are alive. The three seconds include the time required to retransmit lost RPCs, if required.

The computers running your servers may fail, but you are allowed to assume fail- stop behavior (i.e., no Byzantine failures).

These are optimistic assumptions, which you might not be able to make about a real system; they should make your task easier.


Getting Started

All programming for this coursework must be done under Linux. We provide a Linux virtual machine (VM) image that you can use if you’d like to do development on your own machine. You also have the option of logging into a set of CS lab Linux machines remotely via ssh. We have ensured that the code we give you works correctly on the Linux VM we provide.  It should also work correctly on the lab machines,  although  there may be corner cases where the lab machines may give different results than the VM we provide. The VM we provide is the same VM we use to test your code. Your grade will be the score you receive when we run your code in our own copy of the VM. If you consistently (i.e., for many runs) get different results on a lab machine than you do when your code is tested by our auto-grader (which we describe below), please contact the course staff via a Piazza private message. We are happy to answer student questions about difficulties encountered when doing the coursework in the VM we provide or on CS lab machines, but we cannot support any other Linux installation.


Getting and Running the VM

To run the Linux VM we provide on your own computer, you will need to first download and install VirtualBox. You can find links to installer packages for the latest version of VirtualBox for Windows, Mac OS X, Linux, and Solaris online at:


On that page, download and install the platform package for your computer’s in- stalled OS. Next, download the VM image by retrieving both files in the directory at:


Start VirtualBox (on Linux, with the shell command VirtualBox) and open the local copy of the VM image that you downloaded. A window will open, within which you will find running a complete Linux OS. The username and password to log in are user and user. The VM image we provide has all you need to do this coursework, including the C and XDR compilers, git, and popular editors (emacs, vim, and nano). Do your work within the VM: edit your code there, run tests there, and manage your code using git and GitHub there (more on git below).


Using the CS Lab Machines

You can also, if you choose, work on CW1 on the CS lab machines. Note that these ma- chines are accessible over the Internet, so you may work on the coursework either from home or in the labs.1 The Linux lab machines are those with the following hostnames:

niagara frontal parietal occipital sphenoid ethmoid maxilla palatine zygomatic lacrimal


Managing Your Code with git

You will manage the revisions of your code,  including submitting it to the instructors  for testing and grading, using the git source code control system and GitHub. git is useful for a great many things, from keeping the revision history of your code to making it easy to share your code on different machines (if you wind up wanting to use the     VM on your own box and also develop on the CS lab machines, for example, you can  keep your multiple working copies in sync via your “master” repository on GitHub). If you’ve not used git before, you can find a wealth of documentation online; we offer only a bare-bones introduction below.

git manages a set of source code files you are working on in a repository. You keep a local copy of the repository on a machine where you are editing your code and testing it, and use git to keep your local copy synchronized with a “master” copy of  the repository on a server.  In 0133,  you will use GitHub to host the master copy of   your repository. As you do your work (adding code, fixing bugs, etc.) it is good practice to update the master copy of your repository on GitHub with the changes you have made locally. There are two steps to doing so: first, you commit the changes to indicate1 To  log  into  a  lab  machine  remotely,   you  must  first  log  into  a  CS  departmental  gateway  such as

knuckles.cs.ucl.ac.uk using ssh, then from there log into one of the lab machines using ssh.

that they are ready for shipping to the master repository, and second, you push your committed changes to the master repository.

To start the coursework, though, you must first retrieve a copy of the files we provide for you to start from. You can set up your GitHub master repository for your CW1 code by visiting the following GitHub URL:


If you already have a GitHub account, visiting the above URL will create a new private repository for CW1 (i.e., visible only to you—no other GitHub user or the public will be able to read the contents of your repository). If you don’t yet have a GitHub account, you’ll be prompted to create one, after which GitHub will create a new private repository for CW1 in your new account. In both cases, the repository will be pre- populated with the code you need for CW1: a complete client, an XDR RPC interface definition file, a skeleton server, and a program that tests your code.

This new repository for your CW1 code is on GitHub’s servers. You need a local working copy in your work environment—either within your VM if you are working on your own machine, or in your home directory of your CS Linux account if working on a CS lab machine. To create a local working copy, you need to clone your private CW1 repository from GitHub to your work environment.  When you visit the above URL,   your browser should eventually display a page that shows the contents of your new GitHub CW1 repository. Click on the “Clone or download” button toward the right on  the page showing the contents of your new CW1 repository. Copy the link shown to the clipboard. To  clone the CW1 repository from GitHub to your work environment,  use  the command:

git clone [paste URL here]

You will be prompted for your GitHub username and password. After you enter them, you will have a local working copy of the CW1 repository in a subdirectory with the same name as the GitHub repository (of the form cw1-ticker-[GitHub user- name]).

As you write your code and improve it (e.g., by fixing bugs, adding functionality, etc.), you should get in the habit of syncing your changes to the master copy of your CW1 repository on GitHub.  Doing so keeps the history of changes to your code,  and     so allows you to revert to an older version if you find that a change causes a regression. It also serves to back up your code on GitHub’s servers, so you won’t lose work if your local working copy is corrupted or lost.  To  bring GitHub up to date with changes to  your local working copy, you must first use the git commit -a command (which will prompt you for a log message describing the reason for your commit, e.g., “fixed crash on rapid trade submissions”), and then the git push command to copy your changes to GitHub.


Building and Running the Code

Change directories into your local working copy and build the skeleton code:

% cd cw1-ticker-[Github username]% make

rpcgen -C -h -o ticker_prot.h ticker_prot.x cc -c -Wall -g client.c

gcc -Wall -g -o ticker-server server.o ticker_prot_xdr.o ticker_prot_svc.o ticker_prot_clnt.o minirpc.o -L/usr/local/lib


(Don’t worry if there are warnings from the C compiler about unused variables while compiling ticker prot *.c; rpcgen automatically generates those .c files, and some- times includes unused variables in the C functions it generates. Remember: you should never edit the C source code for the ticker prot *.c or ticker prot *.h files. When you change the ticker prot.x file, rpcgen will re-generate these automatically.) The server expects command-line arguments as follows: a unique numeric ID, a local port number on which to receive RPC/UDP packets, and (for each other server) a host

name and port number. To test the server, you might run the following on zygomatic:

zygomatic% ./ticker-server 1 2001 occipital 2002

And this on occipital:

occipital% ./ticker-server 2 2002 zygomatic 2001

You may have to modify the port numbers in case someone else is running this test at the same time. You can also run multiple copies on the same machine, using different UDP port numbers. (If you’re running in a VM, you only have one machine, so should open a separate window for each server you wish to run, use localhost—the one machine you’re on—as the name of the other machine to connect to, and be sure to use different UDP port numbers for each server process.) Now in a third window (on either machine), submit a few trades. For example:

zygomatic% ./ticker-client localhost 2001 IBM-90 zygomatic% ./ticker-client localhost 2001 DELL-16

Ideally, both servers would print either

Either is acceptable, unless 7 or more seconds passed between submitting the two trades, in which case they must appear in order of submission. Notice that the server we supply you with doesn’t work; only one of the servers prints each trade.



本网站支持淘宝 支付宝 微信支付  paypal等等交易。如果不放心可以用淘宝交易!

E-mail: [email protected]  微信:dmxyzl003



本网站支持淘宝 支付宝 微信支付  paypal等等交易。如果不放心可以用淘宝交易!

E-mail: [email protected]  微信:dmxyzl003