2023年11月25日

Java代写 | CSE 3461 Computer Networking and Internet Technologies

本次澳洲作业案例分享是一个使用Java开发聊天软件的Java代写assignment

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.