Introduction

Write an application using Java or C++ programming language for creating a peer-to-peer (P2P) system that attempts to provide secure instant messaging.

Each peer must support the following commands:

IDENTIFY: A request to retrieve the public key for the node

REGISTER: A request to register a new peer to this node

LIST: A request for the list of all peers known to the node

DELIVER: A request to deliver a message to the node

Command Details

When a node receives an IDENTIFY command, it must respond with its public key.

Any command except IDENTIFY must be encrypted with the public key of the recipient. Thus, if the command received is not IDENTIFY, the first job of the recipient is to decrypt the received message, using its private key, to obtain the decrypted command and any other data. Similarly, the recipient's responses to any command, other than IDENTIFY, must be encrypted with the recipient's private key (so the response can be decrypted by the sender using the recipient's public key).

If the decrypted command is a REGISTER command, the recipient must take the IP address and port specified by the command and add those details to its list of known peers.

If the decrypted command is a LIST command, the recipient must respond with a list containing details of all of the peers it knows about.

If the decrypted command is a DELIVER command, the recipient must display the message to the user and respond with an acknowledgement.

Any other message should be considered an error and be ignored (i.e. no response sent).

Details of the exact formatting of these messages (e.g. how the list of peers is delimited in a response to a LIST command, or how data such as the message to be delivered for the DELIVER command), and details such as timeout limits and public key encryption algorithm/parameters, are left up to you, though you should describe and justify your choices in your program's documentation.

Startup

When a node starts execution, it should present a menu to the user (either GUI or terminal-based), giving the user the option to register with a peer, send a message, or exit. Once a choice has been made, the action should be handled as described below and (unless the action was to exit) the menu should then be displayed again, allowing the user to choose a new action. This process should be repeated until the exit action is selected. If any action fails, the user should be presented with a message letting them know what went wrong before the menu is displayed again.

Register with a Peer

Firstly, the user should be asked for details of the peer (i.e. IP address and port). This information should be added to the list of known peers for this node.

The node will then send an IDENTIFY request to the peer entered by the user. The public key that is returned should be stored by the node for future communication with the new peer.

The node will then send a REGISTER request to the new peer (note: this message will need to be encrypted with the new peer's public key). This should result in the current node having the new peer as one of its known peers and the new peer having the current node as one of its known peers (i.e. both nodes will know the other as a peer).

Send a message

Firstly, the node will update its list of peers (as described in the section "Updating Peers" below). It will then display a list of its known peers to the user. The user will select a peer to send the message to. If the node does not already know the public key of the selected peer, it must send an IDENTIFY request to obtain this information. The user will then type in a message to be sent and the node will send a DELIVER request to the selected peer (encrypted with the receiving node's public key).

Exit

The program should finish handling any requests it has already started processing and then exit.

Updating Peers

To ensure a node's list of peers is current before a user is asked which peer a message should be sent to, the node must first update its list of peers. This is achieved by looping through all known peers and sending them a LIST request (this may first require an IDENTIFY request to get the public key required to encrypt the LIST request). Any new peers returned through these lists should be added to the node's list of known peers. These new peers should then be sent a LIST request, and the process should continue until no new peers are added. Note that each known peer should only be sent a single LIST request. For example, if node A sends a LIST request to nodes B and C, and both return D in their list of known peers, node A should only send a single LISTrequest to node D. In particular, avoid loops where nodes are continually sent LISTrequests.

Details

Create shell script, startNode.sh which takes a port as its only command-line parameter and starts the node listening on that port (or exits with an appropriate error message if that is not possible).