Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Re-architect Peer protocol #22

Open
mkrupczak3 opened this issue Apr 2, 2023 · 2 comments
Open

Re-architect Peer protocol #22

mkrupczak3 opened this issue Apr 2, 2023 · 2 comments
Assignees
Labels
enhancement New feature or request

Comments

@mkrupczak3
Copy link
Owner

Currently Peers adhere to a strict call-response protocol where every "call" must be echoed by a "response" from the counter-party (and vice versa). 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 @mkrupczak3 @octapi345

@mkrupczak3 mkrupczak3 added the enhancement New feature or request label Apr 2, 2023
@mkrupczak3
Copy link
Owner Author

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

@trobe137
Copy link
Collaborator

trobe137 commented Apr 2, 2023

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...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants