Open mkrupczak3 opened 1 year ago
It may not be necessary to have a separate port listening for Command-and-Control messages.
Instead, there can simply be a TCP port that is always listening for incoming connections. If I'm a Peer for example, I can assume that the counter-party Peer and Router will work out how to contact me by themselves without my intervention. The initiator peer can then connect to me directly using my address it obtained from the lookup
TRob commented:
Building on that, when a peer makes a successful connection, do we want it to stop listening and continue with the process? or do we want peers to sustain multiple connections? If we them to sustain multiple connections, we may want to build a PeerThread class. This class would handle the data processing and print the data we need regarding send-times...
I agree. It makes more sense to have PeerThread. Use the files ./Peer/Peer.java and ./Peer/PeerThread.java
Given that in Part 2 we are significantly changing the operation of the Peers, we will need to think carefully and implement a new protocol which may perform uni-directional messages.
Another consideration will be if the Peers are always listening for incoming connections from any IP, or if they will have a separate port for listening for Command-and-Control messages from the ServerRouter(s) detailing from which IP to expect an incoming connection from.
@trobe137 @octapi345