optimism-java / shisui

Ethereum Portal Network Client written in Go
https://www.ethportal.net/clients/shisui
GNU Lesser General Public License v3.0
5 stars 6 forks source link

Refactor shisui main to support graceful shutdown #156

Closed GrapeBaBa closed 1 week ago

GrapeBaBa commented 2 weeks ago

Currently, sub network objects don't be managed after it start, there is no place we could invoke Close function on them.

r4f4ss commented 2 weeks ago

@GrapeBaBa Can I get this issue?

GrapeBaBa commented 2 weeks ago

@GrapeBaBa Can I get this issue?

Of course.

Tchisom17 commented 1 week ago

I am applying to this issue via OnlyDust platform.

My background and how it can be leveraged

I’m a backend software engineer focusing strongly on Go, particularly in building decentralized systems and working with blockchain technology like Ethereum. Over the years, I have been involved in projects that require careful management of resources in distributed networks, ensuring efficient operations with minimal hardware and bandwidth requirements. In addition to working on decentralized solutions, I have optimized cloud services, automated complex pipelines, and integrated storage solutions. This background gives me a solid foundation to understand and tackle the challenges posed by peer-to-peer protocols like the Portal Network.

How I plan on tackling this issue

To address the issue of subnetwork objects not being managed after they start, I would begin by analyzing how these objects are created and why they persist without a clear shutdown process. Since the problem is the absence of a place to invoke the Close function, I’d explore introducing lifecycle management into these objects. One approach could be to utilize Go's context package to manage the lifecycle of subnetwork objects, allowing for proper shutdown signals when they’re no longer in use. Alternatively, I would look at implementing a cleanup process tied to the object’s creation or session duration, ensuring that resources are efficiently released without impacting the overall network performance. The goal would be to provide a way to manage these objects in a controlled and clean manner, avoiding unnecessary resource consumption while maintaining network stability.

GrapeBaBa commented 1 week ago

I am applying to this issue via OnlyDust platform.

My background and how it can be leveraged

I’m a backend software engineer focusing strongly on Go, particularly in building decentralized systems and working with blockchain technology like Ethereum. Over the years, I have been involved in projects that require careful management of resources in distributed networks, ensuring efficient operations with minimal hardware and bandwidth requirements. In addition to working on decentralized solutions, I have optimized cloud services, automated complex pipelines, and integrated storage solutions. This background gives me a solid foundation to understand and tackle the challenges posed by peer-to-peer protocols like the Portal Network.

How I plan on tackling this issue

To address the issue of subnetwork objects not being managed after they start, I would begin by analyzing how these objects are created and why they persist without a clear shutdown process. Since the problem is the absence of a place to invoke the Close function, I’d explore introducing lifecycle management into these objects. One approach could be to utilize Go's context package to manage the lifecycle of subnetwork objects, allowing for proper shutdown signals when they’re no longer in use. Alternatively, I would look at implementing a cleanup process tied to the object’s creation or session duration, ensuring that resources are efficiently released without impacting the overall network performance. The goal would be to provide a way to manage these objects in a controlled and clean manner, avoiding unnecessary resource consumption while maintaining network stability.

Thank you for your interest, this issue has been resolved by @r4f4ss , we will create more issues and look forward to your contributions👍

GrapeBaBa commented 1 week ago

fixed by #158