I see, so let's take a step back, I want to pause/resume `net.Listen()`. Unlike a web server, my application doesn't need to always be on, in fact it only comes online once the user decides, responds to the requests, and would sleep again until needed - when given signal again by the user (and not the network).
Thus, I need to be able to show that no packet is transmitted in the hibernate stage, as it could *potentially* leak sensitive data. The flag approach makes sense, but it's not 100% secure, as the machine would still be sending SYN & ACK packets. Does that make sense? On Mon, Jul 24, 2023 at 9:10 AM Kurtis Rader <kra...@skepticism.us> wrote: > I think we are going to need more context. If you were able to pause > net.Listen().Accept() the kernel's listen queue would eventually fill and > the kernel would reject any new connection requests. And when you resumed > accepting connections if enough time had elapsed those old connection > requests would no longer be valid. I don't see why you need any of the > three solutions you proposed. Why not simply set a flag that indicates > whether new connections should be handled? If the flag is false simply > accept the connection request then close the connection (or do whatever > else makes sense). I read your StackOverflow question and am still > perplexed what problem you are trying to solve. > > On Sun, Jul 23, 2023 at 10:11 PM David N <danowz...@gmail.com> wrote: > >> I've posted this question on stackoverflow >> <https://stackoverflow.com/questions/76447195/how-to-suspend-and-resume-accepting-new-connections-in-net-listener>, >> discussed it with some members of the golang community, and I was >> encouraged to post here. >> >> Problem: I have a secure application and I want to pause/resume accepting >> network connections, calling `l.Accept()` blocks the thread, thus you can't >> pause in a single-thread program. You can use goroutines but that still >> isn't ideal, as the routine would still accept the connection first and >> only then can close it if you're in "pause" mode. >> >> This could be solved by: >> - having a non-blocking, async, `l.Accept()` >> - returning a handle to (accepting) goroutine and killing/re-creating it >> from main thread >> - accepting connections in a separate process and communicating over a >> socket >> >> The 1st one doesn't exist, the 2nd one is not accepted by the language >> designers, and the 3rd one is unnecessarily complex and prone to break. >> >> This looks like a shortcoming of golang, is it worth discussing further >> with lang designers? >> >> -- >> You received this message because you are subscribed to the Google Groups >> "golang-nuts" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to golang-nuts+unsubscr...@googlegroups.com. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/golang-nuts/CAN7%3DS7htWfYUQmd3H8GiWoWSaei1qU-FMcpqdyccFkXN1kmsWg%40mail.gmail.com >> <https://groups.google.com/d/msgid/golang-nuts/CAN7%3DS7htWfYUQmd3H8GiWoWSaei1qU-FMcpqdyccFkXN1kmsWg%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> > > > -- > Kurtis Rader > Caretaker of the exceptional canines Junior and Hank > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAN7%3DS7iG9by0GmXC-HZeRhHPn5quEbr8%3Dk54OmrYodi2%2BY5EoA%40mail.gmail.com.
