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:
>>>> 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/919a5a2d-bd99-4f9c-b9fd-cfa2bd0a3862n%40googlegroups.com.
