🚀 go-pugleaf

Remy Lebeau (TeamB) escreveu:
> 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.

Again. I'm learning to do this. :) And my English is not so good, what 
you can see for my type errors and bad chose of words ;), and so, 
sometimes I don't understand something that is write and begin to think 
that others things that I read were misunderstunding...

But I'm reading the RFC2616 for some time now, trying to understand 
completly the HTTP code. For the TCP and socket, I read the Help and 
find many answars to my questions here and other foruns, including 
foruns for unix and linux programing, because I'm starting to do a linux 
version with almost the same code here :)

Forgive me for not understand all you write ;) It's all my fault really.

> 
> 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.
> 

Because I know the pages I'm accessing, I don't need to look to these 
parameters. The page that agendar_recv() access (look to my other post), 
always return a chunked page. So, I read the buffer until I get the 
final like this: "0\r\n\r\n" tnat indicates the end of the response 
(according with RFC2616)
And it works.
If I try to read anything after this, the recv stay many seconds waiting 
fod data and finaly return 0.

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

Then, I understand correct the bcb 6 help :)

> 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.

This look's interesting...
I'll try a version of the code using this aproach insted bloking. To 
know how my app react.

> 
> 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.
> 

ok. :) I 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.

At each 91 requests, the server close the connection... :)

> 
> 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.

Say that to the server. Look's like he don't know that ;)

> That is a possibility.

I tested this. No. The cookies are the same. Never change (see my other 
post)
> 
>> 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.

Actually I find that I forget to call a function that make a litle work 
on the page, after Login(), without is impossible to get the correct 
response, and was because this that I was needing kill the thread. Now 
is working.

Only that the connection is closed every 91 requests...

Any Idea?