Yes I got it but I want to know if *reader.ReadString("\n")* is supposed to
throw *io.EOF* rather than blocking for next request in the connection.
On Sunday, February 11, 2024 at 2:30:44 PM UTC-8 Robert Engels wrote:
> 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 <
> golan...@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:
>>>>> 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...@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
>
> <https://groups.google.com/d/msgid/golang-nuts/919a5a2d-bd99-4f9c-b9fd-cfa2bd0a3862n%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
>
--
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/8014b001-ef32-4937-b31e-1ce6b24baf48n%40googlegroups.com.
