MSG_PEEK (was Re: Testing on BEOS?)
On Wed, 26 Nov 2003, Hrvoje Niksic wrote: Speaking of testing, please be sure to test the latest CVS on Windows as well, where MSG_PEEK is said to be flaky. HTTPS is another thing that might work strangely because SSL_peek is undocumented (!). Out of curiosity, why are you introducing this peeking? I mean, what's the gain? -- -=- Daniel Stenberg -=- http://daniel.haxx.se -=- ech`echo xiun|tr nu oc|sed 'sx\([sx]\)\([xoi]\)xo un\2\1 is xg'`ol
Re: MSG_PEEK
Daniel Stenberg [EMAIL PROTECTED] writes: Out of curiosity, why are you introducing this peeking? I mean, what's the gain? Simplifying the code. Getting rid of the unfinished and undocumented rbuf abstraction layer. Buffering is unnecessary when downloading the body, and is mostly unnecessary when downloading the headers or in line-oriented communication. I got the idea by tracing how fetchmail communicates with the server. Since fetchmail is fairly portable, I believe the idea works well in practice.
recv and the MSG_PEEK flag
Does anyone know whether the MSG_PEEK flag can be relied upon? I'd like to use peeking to get rid of the ad hoc rbuf layer used in Wget since time immemorial. Peeking would require additional work under SSL, but I think I know how to make it work. But I'm more worried about TCP/IP stacks that don't support MSG_PEEK, such as is allegedly the case on BEOS. Does anyone have more information about this? When did MSG_PEEK appear in the socket API, and how widely is it available? P.S. I know that peeking is inefficient in general, but I plan to use it only for reading HTTP headers and individual lines of output from FTP servers, not for request bodies.
