Detect how many bytes can be written to NSOutputStream - ios

Question

Basic problem I'm try to implement:
I have two streams. NSInputStream and NSOutputStream.
Now I want to take some data from input process them (add some frames encode them and so on) and pass to output. So far so good.
Actual problem
Problem is that NSOutputStream API - write:maxLength: which can return actual number of bytes written. This value can be different from length passed. This is a problem since it requires creating extra logic to maintain some kind of buffer.
I want to avoid this. I'd like to now how many bytes output stream will accept without buffering so I could calculate how much data I should read from input stream (I will add some frames and encoding).
I don't want to maintain extra buffer.
Output stream is associated with a TCP socket, input stream can be associated with any kind of resource.

Answer 1

This is the apple implementation for the problem:
- (void)stream:(NSStream *)stream handleEvent:(NSStreamEvent)eventCode
{
switch(eventCode) {
case NSStreamEventHasSpaceAvailable:
{
uint8_t *readBytes = (uint8_t *)[_data mutableBytes];
readBytes += byteIndex; // instance variable to move pointer
int data_len = [_data length];
unsigned int len = ((data_len - byteIndex >= 1024) ?
1024 : (data_len-byteIndex));
uint8_t buf[len];
(void)memcpy(buf, readBytes, len);
len = [stream write:(const uint8_t *)buf maxLength:len];
byteIndex += len;
break;
}
// continued ...
}
}
In this implementation a chunck of 1024 bytes is written at a time.
And a note was provided:
There is no firm guideline on how many bytes to write at one time.
Although it may be possible to write all the data to the stream in one
event, this depends on external factors, such as the behavior of the
kernel and device and socket characteristics. The best approach is to
use some reasonable buffer size, such as 512 bytes, one kilobyte (as
in the example above), or a page size (four kilobytes).
As described it depends on the other side. don't know if that can be figured out by investigating the receiver. But, maybe the size suggested to write at a time may decrease the chance that some bytes will not be written. That logic should be implemented.

Answer 2

You'll have to buffer. The stream can't predict what the can be written until it makes the attempt. But you can keep the buffer as small as you like by (a) attempting to write less data at once, and (b) buffering only the data that wasn't written on the prior attempt.
The result of such an arrangement is to trade away speed for space. Consider the one byte buffer as the degenerate case.