As stated earlier, objective is to create a web server without using
net/http, instead directly reading from the socket connection.
On Sunday, February 11, 2024 at 4:49:09 PM UTC-8 Robert Engels wrote:
>
> If you have http keep alive on - either side should block when reading -
> it is a full duplex connection. You will only get eof if the tcp connection
> is closed.
>
> If http keep alive is off, then the connection is closed after the server
> sends the response - the tcp protocol allows the client to read this data
> even though the connection is shut down.
>
> On Feb 11, 2024, at 5:36 PM, 'Rohit Roy Chowdhury' via golang-nuts <
> golan...@googlegroups.com> wrote:
>
> 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...@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
>
> <https://groups.google.com/d/msgid/golang-nuts/8014b001-ef32-4937-b31e-1ce6b24baf48n%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/e0af0663-765a-4cc9-b8e4-4cd509a81a5en%40googlegroups.com.
