Re: Does CFWriteStream coalesce writes?
Re: Does CFWriteStream coalesce writes?
- Subject: Re: Does CFWriteStream coalesce writes?
- From: Mark Pauley <email@hidden>
- Date: Thu, 29 May 2008 11:36:39 -0700
Nope, we don't buffer in CFSocketStreamWrite. You might want to take
a look at a tcp dump to see just how many bytes per packet you're
sending... I would imagine this is a place where we could improve,
(signalling canAcceptBytes is probably expensive, as is sending short
packets).
I think the issue is that we aren't giving you a high-watermark
property nor a maximum latency property for writes, correct? You know
how much coalescing you desire and what your acceptable latency is.
You can perform said coalescing yourself in a much more efficient
manner (if we were to coalesce for you, your stream client would just
waste time sending runloop signals that don't need to be sent).
You've got a tradeoff of latency versus transport optimization
here... We currently let you do the coalescing and we push the bits
onto the wire in the most predictable way possible.
_Mark
On May 29, 2008, at 11:06 AM, Jens Alfke wrote:
My BLIP[1] protocol uses asynchronous NSStreams for TCP I/O. I'm a
bit unsure about the efficiency of the recommended[2] technique for
writing to the stream. Specifically, the examples suggest making
_one_ write call per NSStreamEventHasSpaceAvailable notification.
This works, since if there's more space available, the notification
will be sent again, resulting in another write.
My worry: Will this result in CFNetwork making multiple small write
syscalls? If so, if the writes are smaller than the network packet
size (the example uses only 1kbyte) will this result in TCP
inefficiently sending multiple small packets?
Or do my consecutive writes get buffered together by CFNetwork or
the kernel and stuffed into full-size packets? (I'm sure this has
something to do with the TCP Nagle algorithm, but my understanding
of that is fuzzy at best.)
(Some of my writes are as small as 12 bytes, the size of a message
header in my protocol. At first I was calling the stream's write
method multiple times in my event handler, but I found that if the
stream ran out of room the second write could block, even though the
stream is ostensibly in non-blocking mode. So I went back to issuing
only a single write per event.)
—Jens
[1] http://mooseyard.com/projects/MYNetwork/
[2] file:///Developer/Documentation/DocSets/com.apple.ADC_Reference_Library.CoreReference.docset/Contents/Resources/Documents/documentation/Cocoa/Conceptual/Streams/Articles/WritingOutputStreams.html
_______________________________________________
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
_______________________________________________
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