🚀 go-pugleaf

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

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

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

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

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

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

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


Gambit

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 :)

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

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

I guess you have not been reading the HTTP specs very carefully.  HTTP
is a command-response protocol.  There is no room for overlapping
requests on a single connection.  If you must send multiple requests
at a time, then they need to be on separate connections.

> Like you said early, it's necessary to read the chunk size
information

It is not just a matter of reading the chunk size.  What I described
about reading the byte stream in pieces is absolute core to socket
programming in general.  It applies to all application-level protocols
that are built on top of TCP.

> But it's possible to exist only "part" of a chunk?

Yes.  I explained that to you earlier.  That is why you have to keep
reading until all intended data is received.  That includes the bytes
for the chunk size itself, just just the chunk data.  The chunk size
value could fall on a buffer boundary and thus be read in multiple
pieces that you have to put back together in your own code.  Only then
would you be able to read the value, and then know many bytes to
expect for the next set of looping.

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

That is why it is your responsibility to call recv() in a loop for as
many times as it takes to receive all of the bytes for a given value.
I highly suggest you search through the newsgroup archives at
http://www.deja.com, as examples have been posted NUMEROUS times
before which demonstrate the proper way to read/write data from/to a
socket in general.  You do not seem to be grasping that concept very
well yet, but it is very important that you do so in order for any
protocol you implement on top of TCP (HTTP or otherwise) to function
reliably.

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

That is up to the WinSock implementation to decide internally.  That
is not documented.

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

That depends on whether the server is using a blocking or non-blocking
socket on its end.  If blocking, then it will wait until the buffer
clears.  If non-blocking, then it depends on whether the server code
is handling WSAEWOULDBLOCK properly or not.  Beginner socket
programmers tend to forget to do that.

> There some time of "control" on socket connection that sends a
> message to the server saying that the socket buffer is full?

All of that is handled at the lower level of the TCP layer, not at the
application level.  You don't have to worry about it in your code.
Just make sure that you are handling error codes properly that can be
returned from the socket API functions.

> Or can exist lost of data?

TCP guarantees that data is never lost or corrupted.  That is one of
its essential features.

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

99.999999999% of the time, you never need to mess with the socket
buffers.  The socket is already highly optimized internally.  Worry
about your own buffers instead.

> And finally, there are other implementations for sockets than
winsock?

Yes.

> If yes, there are any that work more "fast" than winsock?

Doubtful.  There is nothing wrong with WinSock's speed.  Any
performance issues are more likely to come from your own code.


Gambit

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

> Ok. This is very important to know.

I suggest you go to your local bookstore and pick up a book on socket
programming before you go any further with your project.


Gambit

Thanks for your answers gambit :)

Eduardo.

Remy Lebeau (TeamB) escreveu:
> I suggest you go to your local bookstore and pick up a book on socket
> programming before you go any further with your project.
> 
> 
I'll do that :)
Thanks for the tips :)

Eduardo.