If you implemented it and it works - I guess I don’t understand your question. You must know how tcp/http works. On Feb 11, 2024, at 8:25 PM, 'Rohit Roy Chowdhury' via golang-nuts wrote:Yes I did implement. You can check it here.https://github.com/roychowdhuryrohit-dev/slugOn Sunday, February
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
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 wrote:As stated
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
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
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
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
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
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
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
10 matches
Mail list logo
