Yes I did implement. You can check it here.
https://github.com/roychowdhuryrohit-dev/slug
On Sunday, February 11, 2024 at 5:00:02 PM UTC-8 Robert Engels wrote:
> If it is a web server that supports http clients you still have to
> implement the protocol correctly. At the lowest level that is what all web
> server implementations do - they read from the socket directly.
>
> On Feb 11, 2024, at 7:54 PM, 'Rohit Roy Chowdhury' via golang-nuts <
> golan...@googlegroups.com> wrote:
>
> 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...@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
>
> <https://groups.google.com/d/msgid/golang-nuts/e0af0663-765a-4cc9-b8e4-4cd509a81a5en%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/311a0316-cfee-4952-a290-0be126d619d8n%40googlegroups.com.
