COMP90015 Distributed Systems
Project 2 - Decentralized Chat
2021 Semester II
Synopsis
• In this assignment you will transform. your existing chat program into a
decentralized chat application.
• You may reuse as much of your project 1 code as you wish. You may rewrite
everything if you wish as well. Feedback from project 1 assessment can be used
to help improve your project 2 code and report.
• The basic operation and protocol from project 1 will be the same in project 2,
however instead of a client and server there will be only one process which we
will call a peer. The peer will act as both a client and a server in the
decentralized system.
• The intended operation of the chat peer is described in this slide set.
• You are required to also implement one extended feature as described next.
Extended Feature I
As well as the base protocol that everyone must implement, each group
must choose one extended feature from the list of three choices below,
design the protocol as an extension to the base protocol and implement in
their peer:
• Room Migration – Rooms can be moved from one peer to another. E.g. before
a peer quits it can send its rooms to other peers. All peers that are currently in
those rooms should automatically disconnect and reconnect to the room when
it has been relocated. The peer that receives a room becomes the owner of that
room. Selection of which peers to send rooms to should be based on ensuring
that all existing peers in those rooms can connect to the new peer where their
room is migrated to. Rooms should not become “lost”, e.g. if the peer that is
receiving a room also quits in the middle of receiving it and therefore does not
migrate it further. Of course, if there are no neighboring peers to migrate a
room to then the room is lost if the peer quits. The user of a peer should also
be able to issue a command to migrate a room on a room-by-room basis.
Extended Feature II
• Shout – A Shout command can be used by any user currently joined in a
room. The command causes a provided message to be delivered to all rooms
on all peers of the network. All peers in the network includes all peers for
which there is a path of connections from the shouting peer, not just those
peers that are directly reachable by the shouting peer. The order of delivery at
all rooms on all peers of the network must be FIFO, i.e. that the order of the
messages shouted by a given user matches the order of those messages
delivered at each room at each peer, regardeless of whether some peers have
connected and/or disconnected in between. When the shouted message is
delivered to a room, the identity of the shouter should be listed as “IP:port
shouted”, where IP and port are the values as seen by the peer hosting the
room that the shouting peer is currently in.
Extended Feature III
• File Attachment – Attach a file or files to the message. Users should have the
option to download specific attachments or download all attachments for a
given received message. The download should happen by one of two
mechanisms: (i) directly connecting to the peer that sent the message, if the
peer indicates (as metadata in the message) this is allowed (e.g. the peer
would typically have a public IP address for this to work), or else the peer that
sent the message uploads the attachments to the peer maintaining the room
and peers receiving the message download it from that peer. When a peer is
uploading or downloading files it should not block the user from issuing further
commands. Note: be carefull when implementing functionality that access the
local file system - this creates a strong potential vulnerability.
Chat Peer
The base functionality that all groups must implement is briefly:
• Each peer is started by a user who interacts with the peer on the command line
in the same way as interacting with the client in project 1.
• Each peer will maintain the chat rooms that are created by its user. Users can
only create rooms on their own peer. As explained shortly, the create and
delete room commands don’t require message passing because they are only
executed locally.
• There is no “main hall” room in project 2. A peer that connects to another
peer must first obtain a list of rooms and then join one. The exact session
protocol is discussed further in.
• Peers will provide a list of neihboring peers with IP address and port number,
that allows other peers to search the network of peers for chat rooms, using an
iterative search mechanism.
• Peers will allow other peers to connect to them, to search for chat rooms and to
join chat rooms and chat in them. If a peer does not have a public IP address
then only peers on the same private network as the peer can connect to it.
Overview of peer protocol I
• Protocol aspects taken from Project 1:
• List – (same as proj1) respond with a list of rooms that the peer is maintaining
• Join – (same as proj1) allow a peer to join a room
• Who – (same as proj1) provide a list of who is in the room
• Kick – (similar to proj1) the kicked user is forcibly disconnected from the peer, and
blocked from reconnecting. This is effectively a local command that does not require
message passing, as explained below, since only the owner of a room can kick others and
rooms created on a peer can only be created by the user of that peer.
• Quit – (same as proj1) disconnect from the peer
• Message – (same as proj1) the message is sent to all peers in the room
• Protocol aspects that are very different to Project 1:
• The identity protocol and associated messages from project 1 will not be used. Rather a
peer’s IP and port number combination, e.g. 192.168.1.10:3000, as seen by the peer
hosting the room, will be used and shown as the peer’s identity. The peer cannot change
its identity unless it disconnects and reconnects from a different IP address and/or a
different port number.
• The CreateRoom functionality will exist but will only be accepted if the command was
given by the user of the peer, which means that effectively no actual messages are
required since this command will never be accepted by any other peers. It can therefore
be directly implemented in the peer without message passing.
• The Delete functionality will exist but similar to CreateRoom, the delete command is a
local command only that does not require message passing.
• Additional protocol aspects:
Overview of peer protocol II
• ListNeighbors – a peer can ask a peer for a list of peers’ network addresss that are
connected to it (of course, connected peers that are joined in a room also have their
network address exposed however not all connected peers must be joined in a room)
• SearchNetwork – a local command that causes the peer to do a breadth first search of all
peers available to it (using a combination of ListNeighbors and RoomList messages, to
gather a list of chat rooms over all accessible peers and show that to the user
• Connect – a local command that causes the peer to make a TCP connection to the peer
as given by the user, i.e. the user gives the IP and port number
• Help – a local command that lists all of the commands available to the user with their
syntax that shows how to use them
Initial connection to a peer
From this point on, for the purposes of discussion a peer that is
connecting to another peer will be called the client and the other peer will
be called the server.
• When a peer process is started by the user, it does not connect to any other
peer initially.
• The user must use the Connect command (local command) to cause the peer
to make a TCP connection to another peer. The user must know the IP and
port number of the peer to be connected to.
• When the connection is established from client to server, the server simply
waits for the client to send a command.
• While connected:
• The user can use the List and other commands to find rooms, join a room and start
chatting, very much the same way as project 1. The biggest differences are that the user’s
identity is its IP and port number (as seen by the server) and that there is no “main hall”.
• The user can use the ListNeighbors and SearchNetwork command (the operation of
these commands is explained further in) to search the broader network of peers.
• The user must use the Quit command to disconnect from the peer. The user can then
connect to another peer.
• When not connected to another peer, all of the commands issued are with
respect to the local peer’s room list, including the local commands
CreateRoom, Delete and Kick.
• The peer process quits (disconnecting any connections first) when the standard
input is closed, using Ctrl-D on the terminal.
Client Command Line Interface
• The client must accept input from standard input. Each line of input
(terminated by a newline) is interpreted by the client as either a command or a
message. If the line of input starts with a hash character “#” then it is
interpreted as a command, otherwise it is interpreted as a message.
• The client must write all output to standard output. Since chat is
asynchronous, messages may arrive at any time and will be written to standard
output when they arrive. For an extended feature the command line interface
should provide ways to interact with the extended feature.
• If some data such as streaming video needs to be displayed, a GUI window can
be opened to display that. It should be controllable from the command line
and may also be controllable from the GUI window itself.
JSON Format
• All protocol messages, i.e. sent between client and server, will be in the form
of newline terminated JSON objects.
• A JSON library must be used to marshal JSON output and to unmarshal JSON
objects. Do not implement JSON (un)marshalling yourself.
• All data written to the TCP connection must be UTF8 encoded.
• When implementing an extended feature you may dynamically change to
another data format other than JSON for that feature if you wish, but the base
protocol must be implemented in JSON and the base protocol must continue
to work regardless of whether the feature is used or not. E.g. you may even use
a separate TCP connection to transmit binary data when required and have
additional default ports for those aspects. You may add some fields to the base
protocol messages if you need to support your extended feature, but you
cannot change any of the existing fields.
Connect command
The peer to connect to is not given on the command line. Rather to make
a connection to another peer:
>#connect 142.250.70.238:4444
[] 192.168.1.10:38283>
• The room is empty [] (no room) and the identity is the IP and port number as
seen by the remote peer.
• Note this example is a little contrived: the peer with the public IP address
142.250.70.238 would not see the private IP address 192.168.1.10, but rather
would see the public IP address of the router that the privately connected peer
is getting access through to the public network. Your actual output will differ
according to the specific networks that you test on. The examples in this
project specification continue with these contrived IP addresses.
• If the port number is not provided then the default port number is used. As
well, the connect command should allow the user to optionally specify which
port they would like the TCP connection to use locally when making the
connection:
>#connect 142.250.70.238:4444 5000
[] 192.168.1.10:5000>
Help command
The help command should just list the available commands and their
syntax, e.g. like:
>#help
#help - list this information
#connect IP[:port] [local port] - connect to another peer
#quit - disconnect from a peer
...
You can simply provide a short description of all the commands like above.
Join Room Protocol
The client may at any time send a Join message to the server to indicate
that the client wishes to change their current room to the indicated room.
{
"type":"join",
"roomid":"comp90015"
}
E.g.:
[] 192.168.1.10:38283>#join comp90015
Note the format above shows [] to indicate that the client having identity
192.168.1.10:38283 as seen by the server is not in a room. We can use
the empty string "" to represent not in a room. Text messages sent when
not in a room are ignored.
Join Room Protocol
When receiving a Join message the server must follow exactly this
protocol:
• If roomid is invalid or non existent then client’s current room will not change.
The special room given by "" indicates that the client wants to leave the room
but not join another room. I.e. stay connected but not be in any room.
• Otherwise the client’s current room will change to the requested room.
• If the room did not change then the server will send a RoomChange message
only to the client that requested the room change.
• If the room did change, then the server will send a RoomChange message to all
clients currently in the requesting client’s current room and the requesting
client’s requested room.
E.g.:
{
"type":"roomchange",
"identity":"192.168.1.10:38283",
"former":"",
"roomid":"comp90015"
}
Join Room Protocol
The client will determine from the message whether the request was
successful or not and will output relevant information:
• If the request was not successful: “The requested room is invalid or
non existent.”
• If the request was successful then either “192.168.1.10:4444 moved to
comp90015” if the client was not already in a room or “192.168.1.10:4444
moved from roomid to comp90015” if the client was already in a room
called roomid in this example.
And on the command line:
[] 192.168.1.10:38283>#join comp90015
[] 192.168.1.10:38283>
192.168.1.10:38283 moved to comp90015
[comp90015] 192.168.1.10:38283>
Room Contents Message I
The RoomContents message lists all client identities currently in the room:
{
"type":"roomcontents",
"roomid":"comp90015",
"identities":["192.168.1.10:38283","192.168.1.10:5000","142.250.70.238:4444"],
}
There is no need to indicate an owner since the owner of the room is
always the peer that is sending the message.
The client may at any time send a Who message to request a
RoomContents message from the server for a given room:
{
"type":"who",
"roomid":"comp90015"
}
Room Contents Message II
e.g.
[comp90025] 192.168.1.10:38283>#who comp90015
Note that obviously the server knows the identity of every client
connection, so the identity of the sender is not required.
Room List Message
The RoomList message lists all room ids and the count of identities in
each room:
{
"type":"roomlist",
"rooms":[{"roomid":"comp90025","count":5},
{"roomid":"comp90015","count":7},
{"roomid":"CovidWillComeToAnEnd","count":4}]
}
The client may at any time send a List message to request a RoomList
message from the server:
{
"type":"list"
}
Room Information at the Client
The client displays information regarding rooms and room lists whenever
they arrive. Examples have been given on previous slides.
Create Room
Only the user of the peer can create a room on that peer, using the
CreateRoom command. There is no message associated with this
command. Rather the logic is implemented locally and is the same as in
project 1:
• If the requested name of the room is valid and does not already exist then it is
created – the room name must contain alphanumeric characters only, start
with an upper or lower case letter, have at least 3 characters and at most 32
characters.
• The peer outputs either e.g. “Room jokes created.” or “Room jokes is
invalid or already in use.” depending on whether the local command
worked or not, for the example “jokes” room.
Room Ownership
The owner of a room is always the peer that created it. It can only be
created by the user of that peer. Therefore there is no metadata required
to maintain the owner of each room. For the purposes of discussion, the
“owner” of a room always refers to the peer that created it.