You're thinking backwards. "Long polling" is something done at the *client* side: this is where you send a HTTP request, but the reply intentionally doesn't come back for a long time - generally until the server detects some event that needs reporting.
At a web *server*, you simply read the request from the socket(*), process it, reply, and go straight back to reading the next request. Read will block until the next request comes in (or the connection is closed). In other words, the goroutine handling that TCP connection just has a loop. There's no need to "wake" this goroutine from anywhere. (*) You need to read until the end of the request (request headers + body, if any). Again, RFC2616 tells you how the request is delimited - see section 5. On Saturday 10 February 2024 at 19:12:42 UTC Rohit Roy Chowdhury wrote: > Thanks, that makes so much sense. So should I long-poll until next request > line comes or keep-alive times out? Is there a better way to detect > incoming requests and then maybe awake the goroutine using channels? > On Saturday, February 10, 2024 at 1:52:23 AM UTC-8 Brian Candler wrote: > >> Handling keep-alives on the *server* side doesn't require any sort of >> connection pool. Just create one goroutine for each incoming TCP >> connection, and once you've handled one request, loop around, waiting for >> another request on the same connection. >> >> (That's assuming the client does request use of keep-alives of course; if >> they don't, you should close the connection. This depends on which HTTP >> version they requested and the Connection: header if present. Full details >> in RFC 2616) >> >> On Saturday 10 February 2024 at 06:08:10 UTC Rohit Roy Chowdhury wrote: >> >>> Hello fellow gophers, I am currently building an experimental HTTP/1.1 >>> framework based on TCP sockets as part of my course project. In project >>> requirements, I have been asked to make a web server which can handle >>> keep-alive properly without using the net/http library. The project link >>> can be found below: >>> https://github.com/roychowdhuryrohit-dev/slug >>> I have recently found out that if I *SetKeepAlive(true)* and >>> *SetKeepAlivePeriod(time.Second >>> * time.Duration(timeout))*, it is not enough to hold the connection. >>> Additionally, any subsequent requests are freezing. >>> [image: Screenshot 2024-02-09 at 9.39.08 PM.png] >>> >>> Then I found out that net/http's Transport manages a pool for idle >>> connections. I want to go for a similar approach for my project. But I am >>> not able to figure out how to detect income requests for my idle >>> connections that I will be storing in the pool. Specifically, I want to >>> know how listener.Accept() can give me an idle connection if it exists in >>> the pool. >>> >> -- 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/40fbf74d-81a4-43e2-b439-0b4afa9bb29an%40googlegroups.com.
