Re: Non-blocking SSLWrite problems
Re: Non-blocking SSLWrite problems
- Subject: Re: Non-blocking SSLWrite problems
- From: Rich Siegel <email@hidden>
- Date: Wed, 12 Oct 2005 13:08:27 -0400
On 10/12/05 at 11:35 AM, Brian Webster <email@hidden> wrote:
> The problem I'm having occurs when I write a large enough chunk of
> data to SSLWrite such that it fills the socket's outgoing buffer.
> This causes it to give back an EAGAIN error code, which I then
> translate into returning errSSLWouldBlock from my write callback, as
> the documentation says you should do.
As far as I know, the SSLWriteProc should never return errSSLWouldBlock,
and in fact none of mine ever do. Your SSLWriteProc should push the data
at the socket, set *dataLength to the actual amount of data that was
actually transmitted, and only return an error if you want the whole
process to abort.
Thus, if your call to write to the socket returns EAGAIN, then try again
until a "hard" error occurs. Using CFSocketStream it looks something
like this:
const UInt8 *p = reinterpret_cast<const UInt8*>(data);
SInt32 bytesRemaining = length;
while (bytesRemaining > 0)
{
if (CFWriteStreamCanAcceptBytes(fWriteStream))
{
enum { kMaxXferSize = 32768L };
SInt32 actCount = 0;
actCount = CFWriteStreamWrite(fWriteStream, p, pin(bytesRemaining, kMaxXferSize));
FailTestWithWriteStreamError(actCount >= 0, fWriteStream);
bytesRemaining -= actCount;
p += actCount;
}
}
The test for CFWriteStreamCanAcceptBytes() is a substitute for handling
EAGAIN from the socket, but you get the idea.
Hope this helps,
R.
--
Rich Siegel Bare Bones Software, Inc.
<email@hidden> <http://www.barebones.com/>
Someday I'll look back on all this and laugh... until they sedate me.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Macnetworkprog mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden