🚀 go-pugleaf

"Eduardo Jauch" <eduardo.jauch@gmail.com> wrote in message
news:45e34585$1@newsgroups.borland.com...

> I'm a litle confused now...
> I must use non-bloking or bloking to make the recv WAIT for the
response?

Obviously, you have not been reading up on how to use sockets properly
in the first place, or how the HTTP protocol actually works.  Which is
all the more reason that you should be using a pre-made HTTP library
to do all of the hard work for you.

It does not matter whether you use a blocking or non-blocking socket.
You must continue reading from the socket until you receive a complete
blank line.  Then you parse the headers that were received (in
particular the "Content-Length" and "Transfer-Encoding" headers) to
figure out how much of the remaining reply data, if any, you need to
finish reading.

If you use a blocking socket, than recv() will wait for any bytes to
arrive before exiting.

IF you use a non-blickong socket, then you have to use select() to
know when bytes are available before then calling recv().  If you do
not, then recv() will return immediately and WSAGetLastError() will
return WSAEWOULDBLOCK.

In either case, it is your responsibility to cache any data that does
get read, and then parse that data to know whether more data has to be
read again.  You keep doing that in a loop until all intended data has
been received, or until an error occurs.

> No. I'm not. But is because the server don't do this. Only after
> many iterations (requests) it do that.

You still need to parse the reply headers.  The server will tell you
whether it is keeping the socket open on its end or not.  You have to
then decide whether to keep the socket open on your end as well, or to
close it for the next request.  This is basic HTTP behavior that you
have to implement properly.  You are sending a v1.1 request, so the
default behavior is to keep the socket open, but the server will send
a "Connection" header to confirm or reject that.

> Because i'm not using HTTP 1.0 and the request (HEAD and GET)
> don't change every looping, I'm guessing that or the server is
programed
> to close connections that make too requests within a few time

Very unlikely.  The whole point of using keep-alives is to allow
clients to make more, and faster, requests to the same server because
there is no overhead of tearing down a connection and reconnecting for
each new request.

> or it is changing the session cookies at that time...

That is a possibility.

> Anyway, it don answer why I need to kill the thread to make
> things working again

Because you are likely managing the socket incorrectly in the first
place.  That is frequently the case for people who choose to program
at the socket API level without first understanding what they are
actually doing.  Socket programming is not trivial to understand, it
takes awhile to grasp it correctly.


Gambit