C#代写 | COMPSCI 711 Assignment 1

这次作业是设计和开发可靠的Echo仿真算法
COMPSCI 711
Assignment 1
Design and develop a faithful emulation of the Echo algorithm, extended to determine
the size of the network.
Discarding comments, the actual contents are unsigned integer numbers, separated by
whitespaces. Lines in each paragraph do not need to be sorted in any order.
Node IDs are non-zero numbers, but not necessarily in a closed range. Here they are 1,
2, 4, 3; but could as well be 10, 20, 40, 30. The first listed node is the source (initiator).
The neighbours order indicates a preference order, significant for choosing the parent
among several forward tokens arriving at the same logical time (see FAQ at the end).
Note that each edge has two arc transit times, one for each direction. Arc transit times
are fixed, but this resulting asynchronicity is enough for the purpose of this assignment.
As mentioned, the configuration transit time are not normalised. After normalisation, 10
becomes 1, and 1 becomes 0.1 (this could be the ε used in the lecture sample).
Hopefully, this commented example is enough to infer the underlying grammar of our
configuration files.

The output must be written to stdout, in two paragraphs, separated by one single
empty line. In the first paragraph, each output line indicates a message sent or received
(delivered), containing the following items (in order):
o Time: logical time (time units from start)
o Code: 1=received, 2=sent
o From: sender node
o To: receiving node (destination)
o Token: 1=forward, 2=return (one token is enough, but using two distinct tokens
improves the readability)
o Payload: for forward tokens 0, for return tokens the subtree size
The second paragraph consist of one single line, containing (in order): the total logical
time unnormalised, the total logical time normalised (integer division), the total number
of messages, the network size.
For readability, each number should be formatted on three positions, with one extra
space at the start. Additionally, the set codes should be followed by four spaces, and the
received code should be preceded by four spaces.
The output should appear sorted – sufficient on the first four columns, in order.
This is the output expected for our lecture sample, assuming the preceding
configuration:
time code from to tok pay
0 2 1 2 1 0
0 2 1 3 1 0
0 2 1 4 1 0
1 1 1 2 1 0
1 2 2 3 1 0
2 1 2 3 1 0
2 2 3 1 1 0
2 2 3 4 1 0
3 1 3 1 1 0
3 1 3 4 1 0
3 2 4 1 1 0
4 1 4 1 1 0

time code from to tok pay
10 1 1 3 1 0
10 1 1 4 1 0
10 2 4 3 2 1
20 1 4 3 2 1
20 2 3 2 2 2
30 1 3 2 2 2
30 2 2 1 2 3
40 1 2 1 2 3
40 4 10 4
The output format is very important, as the program will be automatically assessed by
the automarker, where each space and comma counts. Stdout output must not contain
anything else.
Suggestion to use stderr for any additional output that you may temporarily need, e.g.
for debugging/tracing, as stderr is ignored by automarker.
Development language and platform
C#, for .NET Core 3.1.X (which is free, open source, cross-platform, and LTS).
Your program is a command-line program and must be entirely contained in one single
C# source file.
Submission
For this assignment, we use the automarker:
https://www.automarker.cs.auckland.ac.nz/student.php
Submit just your C# source file, after changing its extension from .cs to .dcs.
The standard C# extension is .cs. However, the current automarker requires nonstandard extensions for .NET Core programs, e.g. .dcs for C#, to differentiate
these from files that require the old .NET Framework.
The required project file, .csproj, will be automatically provided by automarker, so do
not worry about this.

Program design
Our program must follow the following conventions, which encourage a faithful design,
able to run on an actual distributed system with minor transformations – mainly,
replacing function calls by HTTP/REST request.
Each node must be instantiated from a top-level class call Node, and the main program
must be in another top-level class called Arcs.
All communications must solely occur by way of method Process (), which implements
one macro-step (using a state machine design). There must be no other data flow or
sharing.
All nodes are instantiated by Arcs. Nodes know the numbers (ids) of their neighbours,
but do not have pointers to them. Consequently, there is no direct messaging between
nodes. All messaging is relayed via Arc, and Arcs is in the best position to output traces.
The actual distributed algorithm starts by Arcs calling the Process () method of the
source node indicated in the configuration, which learns this way that it is the initiator.
Ad-hoc example Left: direct messages; right: relayed messages (via Arcs)

Arcs output traces
0 2 x y a a
0 2 x z b b
1 1 x y a a
1 2 y w c c
2 1 x z b b
2 2 z w d d
3 1 y w c c
3 1 z w d d

// public struct Message {
public class Message {
public int time; public int code;
public int from; public int to;
public int tok; public int pay;
public Message (…) { … } // optional constructor
public readonly int ForwardTok = 1; // optional immutable literals
// …
}
public class Node {
public Node (int self, int[] neigh) { …}
public Message[] Process (Message [] msgs) {
receive inbound messages
process
returns outbound messages
}
}
public class Arcs {
logical time clock
. priority queue for organising messages
public static void Main () {
read and store configuration from stdin
initialise nodes
sends and receives messages on behalf of nodes,
adding required delays, and tracing
stop
}
}

Q. How to ensure a completely predictable/deterministic execution and output trace?
What happens if node receives more than one message at the same logical time, in
which order are these processed? This is critical, if a previously unexplored node
receives two forward tokens at the same logical time, i.e. from two potential parents –
which one is chosen as parent?
A. To make this deterministic, the messages are conceptually processed according to the
sender’s position in the receiving node’s neighbourhood list (not according to their IDs).
Consider the following configuration line, where node 4 has neighbours 3 and 2:
4 3 1
Because of the indicated preference order, node 4 will conceptually give priority to the
messages coming from node 3, over messages coming from node 1.
Q. When and how to start the emulation?
A. The emulation should start as soon as Arcs has read and parsed the configuration,
and instantiated all nodes. We do not prescribe any specific way. Arcs could: send a null;
send an empty array of messages, send a forward token from itself, conventionally
assuming number 0 (not available to other nodes).