There is no such thing as a pool of idle connections at the tcp level. As each side of the connection is bound to a specific port on both ends and can’t be unbound.
You may be referring to http over tcp where the client and server do not close the connection after each request - they keep it open for the next request from that client. Http2 complicates this a bit as it has multiple connections over a single tcp connection. On Feb 11, 2024, at 4:22 PM, 'Rohit Roy Chowdhury' via golang-nuts <golang-nuts@googlegroups.com> wrote:
I got your point. But reader.ReadString('\n') does not block like you said. After a request gets parsed, from the next iteration it keeps on emitting io.EOF until next request arrives. On Sunday, February 11, 2024 at 9:37:43 AM UTC-8 Brian Candler wrote:
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: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.
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/919a5a2d-bd99-4f9c-b9fd-cfa2bd0a3862n%40googlegroups.com.
--
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/0033731F-373E-43B2-9348-11506C797D11%40ix.netcom.com.
|
