Article View: borland.public.cppbuilder.internet.socket
Article #1213Re: send and recv questions with HTTP protocol
From: Remy Lebeau (TeamB)
Date: Sat, 03 Mar 2007 03:39
Date: Sat, 03 Mar 2007 03:39
96 lines
5418 bytes
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-mailReferences:
<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