Forum > Networking and Web Programming

In need of a class/component that implements a peer in a P2P network

(1/2) > >>

Gustavo 'Gus' Carreno:
Hey Remy,

I'm in need of a class/component that would implement a peer in a P2P network. Something akin to TIdTPCPeer or the likes.

I think my need for help is in understanding if it would be a good idea to make a descendent of TIdTCPServer and then abuse it with methods for the client side of P2P, or would it be better to derive from some other class I'm unaware exists?

I say this because in the P2P context, the connections will have to have a flag that indicate if the connection is an UP one, or a DOWN one, something I'm guessing does not exist in the current implementation of the TCP Server.

I would love to read all the opinions you have on the possibility of the Indy package implementing and distributing a class that implements a peer in a P2P network.

Many thanks in advance!!

Cheers,
Gus

MarkMLl:
Could we step back from the language (i.e. class etc.) aspect for a moment and consider what you're actually trying to move around? Also what sort of peer discovery do you need, and is this strictly local or to work across subnetworks?

Historically, I've used UDP broadcasts to locate collaborating programs (e.g. to share clipboard contents); however this was strictly (and intentionally) local since UDP broadcasts aren't normally routed between subnetworks.

MarkMLl

Gustavo 'Gus' Carreno:
Hey Mark,


--- Quote from: MarkMLl on September 07, 2024, 10:56:46 pm ---Could we step back from the language (i.e. class etc.) aspect for a moment and consider what you're actually trying to move around? Also what sort of peer discovery do you need, and is this strictly local or to work across subnetworks?

--- End quote ---

Here's my situation:

* I'm in the middle of an evaluation of a complete re-write of a cryptocurrency core node.
* Any cryptocurrency is based in a P2P model with messages as the basis of all the contents flowing through the pipe.
* I've looked before and apart from the various server components/classes that Indy and Synapse have, there is no support for a peer in a P2P network, be it for file downloads or just messages.
What I'm trying to move around is messages. We're thinking that our best bet would be protobuf.

This has to work in the open internet and through NAT.


--- Quote from: MarkMLl on September 07, 2024, 10:56:46 pm ---Historically, I've used UDP broadcasts to locate collaborating programs (e.g. to share clipboard contents); however this was strictly (and intentionally) local since UDP broadcasts aren't normally routed between subnetworks.

--- End quote ---

The discovery of other nodes is usually not via network discovery, but via a list maintained by all the nodes that make the main network.
In other words: Think more like crypto, less like BitTorrent. This is not a scenario where we need to download files in chunks from various participating nodes.

I would absolutely love to also have the opportunity of having this same thing using UDP connections instead of TCP connections!!
But lets start with TCP first and then see if it can also be done using UDP.

Hope this answers your concerns.

Cheers,
Gus

Remy Lebeau:

--- Quote from: Gustavo 'Gus' Carreno on September 07, 2024, 08:24:55 pm ---I think my need for help is in understanding if it would be a good idea to make a descendent of TIdTCPServer and then abuse it with methods for the client side of P2P, or would it be better to derive from some other class I'm unaware exists?

--- End quote ---

TCP makes a clear distinction between client (connect) and server (listen+accept) socket connections. But P2P doesn't. A peer may need to connect out to another peer, or be connected to by another peer. So you have to be prepared to handle both cases.

You are probably looking for the TIdSimpleServer component, which is a simple non-threaded TCP server that accepts only 1 client connection at a time.

For example, TIdFTP uses TIdTCPClient for Passive mode transfers (outbound connect), and uses TIdSimpleServer for Active mode transfers (inbound accept). It chooses which component to use for any given transfer, but the bulk of the transfer logic is the same regardless of which component is used to create the connection.

You can use a similar approach in a P2P scenario.

MarkMLl:

--- Quote from: Remy Lebeau on September 07, 2024, 11:46:38 pm ---You can use a similar approach in a P2P scenario.

--- End quote ---

There's obviously also various possibilities using multicast etc., although that won't necessarily traverse a domestic router. There's also the central question of the extent to which nodes can be allowed to get out of step, and "whose" responsibility it is to get them back in sync.

MarkMLl

Navigation

[0] Message Index

[#] Next page

Go to full version