 |
BorlandTalk.com
Borland discussion newsgroups
|
| View previous topic :: View next topic |
| Author |
Message |
Eduardo Jauch
Guest
|
 Posted: Sat Mar 03, 2007 8:46 am Post subject: send and recv questions with HTTP protocol |
 |
|
Hello...
I have some few questions about send and recv... :)
Let's think that I "send" a correct request, there are no errors in it,
and the server are able to respond correctly
1. If I "send" another request "before" the server had time to respond
the first, it'll respond both, the first or the second?
2. 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?
3. 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. The server will "ignore" the resting
data, or will send it and after terminate will send the response to my
second request?
4. 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 or the first and the second after the first recv and the
third after the second recv?
5. What is the "lenght" of the buffer that recv have? I mean, on the
system? Is standard? Can be manipulated? Is hardware or software make?
6. Is possible "to clear" the buffer that recv use to fill my buffer
(where data was stored when arrives on the computer)?
Thanks! :)
Eduardo. |
|
| Back to top |
|
 |
Remy Lebeau (TeamB)
Guest
|
| Posted: Sat Mar 03, 2007 9:10 am Post subject: Re: send and recv questions with HTTP protocol |
|
|
"Eduardo Jauch" <eduardo.jauch (AT) gmail (DOT) com> wrote in message
news:45e90410$1 (AT) newsgroups (DOT) borland.com...
| Quote: | 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 |
|
| Back to top |
|
|
Remy Lebeau (TeamB)
Guest
|
| Posted: Sat Mar 03, 2007 9:10 am Post subject: Re: send and recv questions with HTTP protocol |
|
|
"Eduardo Jauch" <eduardo.jauch (AT) gmail (DOT) com> wrote in message
news:45e90410$1 (AT) newsgroups (DOT) borland.com...
| Quote: | 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.
| Quote: | 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.
| Quote: | 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.
| Quote: | 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.
| Quote: | 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.
| Quote: | 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.
| Quote: | 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.
| Quote: | Or can exist lost of data?
|
TCP guarantees that data is never lost or corrupted. That is one of
its essential features.
| Quote: | 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.
| Quote: | And finally, there are other implementations for sockets than
winsock? |
Yes.
| Quote: | 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 |
|
| Back to top |
|
|
Eduardo Jauch
Guest
|
| Posted: Sat Mar 03, 2007 9:10 am Post subject: Re: send and recv questions with HTTP protocol |
|
|
Remy Lebeau (TeamB) escreveu:
| Quote: | "Eduardo Jauch" <eduardo.jauch (AT) gmail (DOT) com> wrote in message
news:45e8e17a (AT) newsgroups (DOT) 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.
| Quote: | 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?
| Quote: | 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.
| Quote: | 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...
| Quote: | 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?
| Quote: | 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?
| Quote: | 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  |
|
| Back to top |
|
|
Remy Lebeau (TeamB)
Guest
|
| Posted: Sat Mar 03, 2007 9:10 am Post subject: Re: send and recv questions with HTTP protocol |
|
|
"Eduardo Jauch" <eduardo.jauch (AT) gmail (DOT) com> wrote in message
news:45e8e17a (AT) newsgroups (DOT) borland.com...
| Quote: | 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.
| Quote: | 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.
| Quote: | 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.
| Quote: | 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.
| Quote: | 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.
| Quote: | 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.
| Quote: | 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.
| Quote: | 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 |
|
| Back to top |
|
|
Eduardo Jauch
Guest
|
| Posted: Sat Mar 03, 2007 9:39 pm Post subject: Re: send and recv questions with HTTP protocol |
|
|
Thanks for your answers gambit :)
Eduardo. |
|
| Back to top |
|
|
Eduardo Jauch
Guest
|
| Posted: Sat Mar 03, 2007 9:40 pm Post subject: Re: send and recv questions with HTTP protocol |
|
|
Remy Lebeau (TeamB) escreveu:
| Quote: | 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. |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
