You are correct; it is not necessary to read all available bytes. As
long as you read at least one byte, you will get another
HasBytesAvailable callback if there are still bytes remaining. In
fact, calling more than once can potentially introduce problems. In
particular, if you run the run loop from within your callback, or the
stream is scheduled on multiple run loops, you will have introduced a
race between when the stream signals any remaining (or newly arrived)
bytes and when you call CFReadStreamRead() for the second time. The
result is you may get a callback claiming bytes are available when in
fact there are none.
Best practices and best performance is to call CFReadStreamRead() only
once per kCFStreamEventHasBytesAvailable callback, and provide a
buffer large enough to be likely to drain all available bytes. That
size varies widely from application to application; you'll have to
experiment to find the best value for you. However, for busy TCP
sockets, the size of the socket's kernel buffer (32k by default) is a
good choice.
Hope that helps,
REW
On Apr 13, 2006, at 6:26 PM, James W. Walker wrote:
If you're using a CFReadStream in the non-blocking mode, and your
callback receives kCFStreamEventHasBytesAvailable, what happens if
you don't consume all the bytes that are available? In the best of
all possible worlds, you'd get another
kCFStreamEventHasBytesAvailable message. The sample code in the
CFNetwork Programming Guide seems to suggest that is so, because it
just reads what fits in one buffer on
kCFStreamEventHasBytesAvailable. In contrast, CFFTPSample takes
pains to keep reading until either CFReadStreamHasBytesAvailable
returns false or CFReadStreamRead reads 0 bytes.
--
James W. Walker, ScriptPerfection Enterprises, Inc.
<http://www.write-brain.com/>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Macnetworkprog mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/macnetworkprog/email@hidden
