hexafluoride / chordette Goto Github PK

To facilitate communication across Chordette peers running in different processes, there needs to be a networking layer. I see two practical approaches to this:

• making sure that all accesses to the Nodes[id] object communicate with the real peer identified by id, by creating a type (RemoteNode?) that inherits from Node (or perhaps an INode) and exposes remote properties/methods, therefore acting like a first-class Node
• replacing all instances of Nodes[id] with explicit networking code

^{I'm using the notation Nodes[id] to refer to how it is used in Node.cs (click for an example)}

The former approach would be more elegant, but would also introduce more complexity. The latter approach would be simpler, with less elegant code. I'm leaning heavily towards the former. I will collect data on how the code I've written makes use of Nodes[id], and I'll document my findings under this issue.

Hello,

I just started looking at your library and tried to compile it with my C# VS 2022 but got an error.

Severity	Code	Description	Project	File	Line	Suppression State

Error	CS1061	'Node' does not contain a definition for 'Peers' and no accessible extension method 'Peers' accepting a first argument of type 'Node' could be found (are you missing a using directive or an assembly reference?)	Chordette.Benchmark	C:\NET\P2P\Chord-p2p\Chordette\Chordette.Benchmark\Program.cs	200	Active

Warning	CS0168	The variable 'ex' is declared but never used	Chordette	C:\NET\P2P\Chord-p2p\Chordette\Chordette\Node.cs	167	Active

Warning	NETSDK1138	The target framework 'netcoreapp2.2' is out of support and will not receive security updates in the future. Please refer to https://aka.ms/dotnet-core-support for more information about the support policy.	Chordette	C:\Program Files\dotnet\sdk\6.0.202\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.EolTargetFrameworks.targets	28	

Warning	NETSDK1138	The target framework 'netcoreapp2.2' is out of support and will not receive security updates in the future. Please refer to https://aka.ms/dotnet-core-support for more information about the support policy.	Chordette.Benchmark	C:\Program Files\dotnet\sdk\6.0.202\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.EolTargetFrameworks.targets	28	

Warning	NETSDK1138	The target framework 'netcoreapp2.2' is out of support and will not receive security updates in the future. Please refer to https://aka.ms/dotnet-core-support for more information about the support policy.	Chordette.Tests	C:\Program Files\dotnet\sdk\6.0.202\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.EolTargetFrameworks.targets	28	

Can you please help?

As "joiner" nodes are picked randomly, this can be remedied by simply restarting Chordette until you get a "good" combination of nodes joining through other nodes.

If you get a "bad" combination, Chordette seems to hang with no error messages and 100% CPU usage. Breaking with a debugger shows that FindPredecessor never exits its while loop.

Hi hexafluoride,

great work! But wouldn't it be nice to deploy your peers as docker microservice containers? I've seen that your code already uses the localhost network interface, so communication between real nodes via ethernet should already be possible.

The solution is not too hard, as Microsoft offers official docker images with pre-installed dotnet core on DockerHub, so the Dockerfile for creating images is pretty simple by implementing following commands (see https://docs.docker.com/engine/examples/dotnetcore/):

1. copy the source code into the image
2. build the source code, do some unit tests and package the build output
3. copy the binary files to the runtime image
4. create an entrypoint that starts a daemon process serving a chord protocol endpoint

Starting real peer tests could be done by some kubernetes files, starting a load-balanced swarm of peers that can then be triggered from outside to perform some key lookups as test.

I don't know the focus of this project, but I could help you with the dockerization if you're interested.

Best wishes
Marco