🚀 go-pugleaf

Remy Lebeau (TeamB) escreveu:
> "Eduardo Jauch" <eduardo.jauch@gmail.com> wrote in message
> news:45e8e17a@newsgroups.borland.com...
> 
>> If I "send" another request "before" the server had time to
>> respond the first, it'll respond both, the first or the second?
> 
> The server will not read the new request until after it has finished
> sending its earlier response.  The data will remain in the socket's
> internal buffer.  If the server disconnects after sending the
> response, the new request will be lost.  Do not overlap requests!
> Wait for a full reply to arrive before then sending a new request, as
> you may need to establish a new connection for it.
> 

Ok. This is very important to know.

>> If I "send" another request "after" the server had time to respond,
>> but not do any "recv" between the requests. What will occour with
>> the data the sever first send to me?
> 
> If the server disconnects after sending a reply, the pending data may
> be lost, depending on when recv() indicates a closed socket.  It may
> allow you to read the pending data.  It may not.  Don't take any
> chances.  Always read the server's reply as soon as possible, even if
> you are going to throw it away.  That gets the data out of the socket
> buffers.
> 

Right. Actually, if the server sends a valid response with the pair 
Connection: closed, I "disconect" immediatly without continue reading 
the  socket buffer. This is necessary or by the fact that the server was 
  who disconect this is unecessary and I can reconnect again normally?

>> If after I "send" the first request I do a "recv", verify that the
> transfer
>> are chinked (so, the server will send more data), but ignore this
> and
>> "send" another request.
> 
> Always read the full response data, unless you are going to disconnect
> the socket immediately after processing just the received headers.  It
> is perfectly valid, and common, to terminate a connection if the
> headers are not to your liking.  If you are going to stay connected,
> however, then do not ignore the pending response data.  Always remove
> it from the socket before then sending the next request.
> 

Right.

>> The server will "ignore" the resting data, or will send it and after
>> terminate will send the response to my second request?
> 
> The server will continue to send the chunked data of the first request
> regardless of whether you read it or not.  If you do not read it,
> however, the data will remain in the socket.  Depending on the socket
> mode used, that may cause errors on the server.  It may wait for you
> to read the data, thus delaying the second request from being
> processed.  Or it may decide to close the socket and wait for you to
> make a new connection to start over fresh.
> 

Thi is very important... I was trying to "speedup" the receptions 
(sending more requests), but what you told show me that this seens 
impossible...

>> Thinking that the first response of the server contain 3 bloks of
> chunked
>> data. After I "send" the first request will the server send all the
> 3 bloks
> 
> Yes, it will send all 3 chunks on its end.  They may or may not arrive
> in 3 recvs's, though.  See below.
> 
>> or the first and the second after the first recv and the
>> third after the second recv?
> 
> You need to keep in mind that TCP is an arbitrary byte stream.  It has
> no concept of "chunks" at all.  In this situation, a "chunk" is a
> higher-level manner that HTTP can format the raw data.  All TCP cares
> about is the low-level bytes that constitute everything the
> higher-level code wants to send.  The contents of the bytes are
> irrelevant to TCP.
> 
> When you call recv() once, you are given whatever bytes are currently
> stored in the socket's receive buffer, up to (but may be less than)
> the number of bytes you told recv() to read.  You are NOT guaranteed
> to read 1 "chunk" per recv.  You may receive a single full chunk.  You
> may receive a smaller piece of a single chunk.  You may receive
> multiple full chunks.  You may receive a partial chunk, a full chunk,
> and a partial chunk all together.  You may receive any combination of
> the these situations.  You have to read from the socket as you would
> read from any other kind of stream.  I already told you earlier that
> you would need to call recv() in a loop, appending the received pieces
> together to piece back together the greater whole.  This is why.
> 

Right... Like you said early, it's necessary to read the chunk size 
information, because can exist more than one chunk on the socket 
buffer... But it's possible to exist only "part" of a chunk? This means 
that on next loop, recv could receive data that don't have the 
information about the size of chunk, because it was on the last loop?

>> What is the "lenght" of the buffer that recv have?
> 
> That is for WinSock to decide internally on its own accord.  You can
> use setsockopt() to suggest your own buffer sizes, but WinSock is not
> required to use them.  You can use getsockopt() to retreive the actual
> buffer sizes being used.  There is no guarantee that the inbound
> buffer will ever be completely full at any given moment.  That is why
> recv() will return the number of bytes actually read from the buffer.
> 

How winsock "chose" if it will get or not the new size for it's own 
buffer? What is the criteria?

>> Is possible "to clear" the buffer that recv use to fill my buffer
> 
> No.  You must read from the socket until there is no more data to
> read, or else close the socket.  There is no option to clear a socket
> and keep it open.
> 

Right.

I think on more questions:

If the recv buffer get full before I could read it (like a server too 
fast), what will happens if the server get more data to send? There some 
time of "control" on socket connection that sends a message to the 
server saying that the socket buffer is full? Or can exist lost of data?

If I know an reasonable "interval" for the amount of data that I will 
"get", it's possible to optimize the socket buffer through setsockopt 
some way?

And finally, there are other implementations for sockets than winsock?
If yes, there are any that work more "fast" than winsock?

Thanks :)