• 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
• 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
• 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 ﬁle or ﬁles to the message. Users should have the
option to download speciﬁc 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 ﬁles it should not block the user from issuing further
commands. Note: be carefull when implementing functionality that access the
local ﬁle system – this creates a strong potential vulnerability.
本网站支持淘宝 支付宝 微信支付 paypal等等交易。如果不放心可以用淘宝交易！
E-mail: firstname.lastname@example.org 微信:itcsdx