Forum > Networking and Web Programming
In need of a class/component that implements a peer in a P2P network
Gustavo 'Gus' Carreno:
Hey Remy,
First of all, let me thank you for your time spent answering my not so well formulated question. I could've made a better job in defining my needs, that's for sure.
--- Quote from: Remy Lebeau on September 07, 2024, 11:46:38 pm ---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.
--- End quote ---
You're absolutely correct in this.
My naive idea is to have the connect to, or what I call DOWN connections be handled by the usual Server methods of Listen+Accept.
Those would be added to a list that will contain both the UP(initiated) and DOWN(received) connections, with a flag attached to the connection so we know if it's an UP or DOWN one.
Then add some methods to allow for the programmer to feed the component, either a single or multiple addresses for the component to initiate connections, and add them to the common list properly flagged.
One thing I forgot to mention is that in a P2P model in the context of crypto, all connections are forever. These are the type of always on, as long as nothing goes wrong, or until the node quits.
Not sure if this influences anything. In a way, we could kinda compare them to websockets, kinda.
--- Quote from: Remy Lebeau on September 07, 2024, 11:46:38 pm ---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 (outbound) transfers, and TIdSimpleServer for Active mode (inbound) transfers. It chooses which component to use for a 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.
--- End quote ---
Hummm... Non-threaded is probably not the best solution since a lot of parallel tasks must be performed while the P2P peer code is also doing it's thing.
Nonetheless those are good hints on trying to investigate a solution for my dilemma.
Now, let's say I would take upon myself the task to create such a thing:
* Can you please point me at the best LEGO pieces I could use, mainly in terms of the connection list and the connection data classes?
* Can you please point me at the best implementation of the Listen+Accept code in any of the current Server implementations?
* Can you suggest some bullet points on how I could then apply some thoughtful glue to all this?
Again, so many thanks in advance for any answer you may provide.
Cheers,
Gus
Gustavo 'Gus' Carreno:
Hey Mark,
--- Quote from: MarkMLl on September 08, 2024, 12:07:30 am ---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.
--- End quote ---
From the little that I know, the P2P thang, doesn't need to have this type of node management.
If I'm not mistaken, the assessment of a node's behaviour is made outside the P2P thang.
A lot of this behaviour management is tied to shenanigans that could be considered illegal or attacks to the integrity of the blockchain.
But I do see the possibility of managing the fact that if a node is spamming the network, DDoS like, then some throttling may be done by the P2P thang itself.
These are details that I would probably need to implement once I do have a solid implementation, that works, but then needs the bells and whistles to be added.
Cheers,
Gus
Remy Lebeau:
--- Quote from: Gustavo 'Gus' Carreno on September 08, 2024, 12:24:59 am ---Hummm... Non-threaded is probably not the best solution since a lot of parallel tasks must be performed while the P2P peer code is also doing it's thing.
--- End quote ---
TIdSimpleServer is not threaded because it doesn't need to be threaded. Just as TIdTCPClient is not threaded. They both service a single connection. YOU decide what to do with that connection once it has been established. If you want to thread it yourself, you can do so.
That being said, since TIdSimpleServer is just a single connection, that means if you want multiple peers to be able to connect to you concurrently, then you would have to create multiple TIdSimpleServer instances on separate ports, or else use TIdTCPServer instead on a single port.
--- Quote from: Gustavo 'Gus' Carreno on September 08, 2024, 12:24:59 am ---Now, let's say I would take upon myself the task to create such a thing:
* Can you please point me at the best LEGO pieces I could use, mainly in terms of the connection list and the connection data classes?
* Can you please point me at the best implementation of the Listen+Accept code in any of the current Server implementations?
* Can you suggest some bullet points on how I could then apply some thoughtful glue to all this?
--- End quote ---
I'm not really sure what you are asking for. But I think most of that is likely going to be your responsibility to implement to meet your specific needs.
Gustavo 'Gus' Carreno:
Hey Remy,
--- Quote from: Remy Lebeau on September 08, 2024, 04:46:36 am ---That being said, since TIdSimpleServer is just a single connection, that means if you want multiple peers to be able to connect to you concurrently, then you would have to create multiple TIdSimpleServer instances on separate ports, or else use TIdTCPServer instead on a single port.
--- End quote ---
Okidokes, this is a good starting point, thanks.
--- Quote from: Remy Lebeau on September 08, 2024, 04:46:36 am ---
--- Quote from: Gustavo 'Gus' Carreno on September 08, 2024, 12:24:59 am ---Now, let's say I would take upon myself the task to create such a thing:
* Can you please point me at the best LEGO pieces I could use, mainly in terms of the connection list and the connection data classes?
* Can you please point me at the best implementation of the Listen+Accept code in any of the current Server implementations?
* Can you suggest some bullet points on how I could then apply some thoughtful glue to all this?
--- End quote ---
I'm not really sure what you are asking for. But I think most of that is likely going to be your responsibility to implement to meet your specific needs.
--- End quote ---
My idea was to create a class/component that would fit nicely in the current list of components that Indy currently offers.
I would prefer that all this came from a more experience developer with enough knowledge of the internals of Indy, someone like you, but I'm also aware that this is a big ask and maybe I should take it upon myself.
This is why I'm asking for your guidance in order to use the available LEGO pieces that Indy has in terms of thread safe lists, connection data classes and any other element that would make this an official Indy component.
In the end I would probably do a PR to have it added to the official repository on GitHub.
Hope this clarifies this.
Cheers,
Gus
Navigation
[0] Message Index
[*] Previous page