🚀 go-pugleaf

"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