🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: borland.public.cppbuilder.internet.socket
Article #1213

Re: send and recv questions with HTTP protocol

#1213
From: Remy Lebeau (TeamB)
Date: Sat, 03 Mar 2007 03:39
96 lines
5418 bytes
"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
Technical Details
Message-ID: <45e8f0a7$1@newsgroups.borland.com>
Path: arc1-ca.pugleaf.net!g2news2.google.com!news3.google.com!news4.google.com!news.glorb.com!newsfeeds.ihug.co.nz!ihug.co.nz!newsgroups.borland.com!not-for-mail
References: <45e8e17a@newsgroups.borland.com>

Show Full Headers
Complete Article Headers
X-Google-Thread: 11508e,c4318c7cf342ce5a
X-Google-Attributes: gid11508e,public
X-Google-Language: ENGLISH,ASCII-7-bit
From: "Remy Lebeau \(TeamB\)" <no.spam@no.spam.com>
Newsgroups: borland.public.cppbuilder.internet.socket
References: <45e8e17a@newsgroups.borland.com>
Subject: Re: send and recv questions with HTTP protocol
Date: Fri, 2 Mar 2007 19:39:14 -0800
Lines: 98
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2800.1409
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409
NNTP-Posting-Host: 75.83.34.171
Message-ID: <45e8f0a7$1@newsgroups.borland.com>
X-Trace: newsgroups.borland.com 1172893863 75.83.34.171 (2 Mar 2007 19:51:03 -0800)
Path: arc1-ca.pugleaf.net!g2news2.google.com!news3.google.com!news4.google.com!news.glorb.com!newsfeeds.ihug.co.nz!ihug.co.nz!newsgroups.borland.com!not-for-mail