I’ve seen a number of issues around EASession inputStream hasAvailableBytes (this is a serial BT connection) and none totally match this odd behavior and wondering if this has been seen by others and if there’s been a resolution/issue found.
In this case the amount of data to be read will be > 1MB, however after ~28000 bytes the NSStreamEventHasBytesAvailable event type isn’t sent anymore. The basis for the code is from the EADemo, and have tried a number of variations, but with the same result. I’ve also tried variations that start polling the NSInputStream after the NSStreamEventOpenCompleted event, but end up getting the same results.
I also have seen issues regarding iOS 11 and accessory issues that have been filed as bugs with Apple... however I also am testing with 10.2 and get the same behavior (so assuming can rule iOS issues out)
The setup for the stream is (note this is setup in the main queue, though I’ve also tried it with a background queue):
// open a session with the accessory and set up the input and output stream on the default run loop
- (BOOL)openDataSession
{
[_accessory setDelegate:self];
self.dataSession = [[EASession alloc] initWithAccessory:self.accessory
forProtocol:dataProtocolString];
if (self.dataSession) {
NSInputStream* inputStream = self.dataSession.inputStream;
[inputStream setDelegate:self];
[inputStream scheduleInRunLoop:[NSRunLoop currentRunLoop] forMode:NSDefaultRunLoopMode];
[inputStream open];
[[self.dataSession outputStream] setDelegate:self];
[[self.dataSession outputStream] scheduleInRunLoop:[NSRunLoop currentRunLoop] forMode:NSDefaultRunLoopMode];
[[self.dataSession outputStream] open];
} else {
NSLog(@"creating file transfer session failed");
}
return (self.dataSession != nil);
}
the event handler is:
- (void)stream:(NSStream *)aStream handleEvent:(NSStreamEvent)eventCode
{
NSError* error;
NSLog(@"Received stream handle event code: %x - stream: %@", eventCode, aStream);
switch (eventCode) {
case NSStreamEventNone:
break;
case NSStreamEventOpenCompleted:
/
break;
case NSStreamEventHasBytesAvailable:
if ([aStream isEqual:self.dataSession.inputStream]) {
[self doDataTransfer];
}
break;
case NSStreamEventHasSpaceAvailable:
[self _writeData];
break;
case NSStreamEventErrorOccurred:
error = self.dataSession.inputStream.streamError;
NSLog(@"Stream error: %@", error.debugDescription);
break;
case NSStreamEventEndEncountered:
break;
default:
break;
}
}
and the code to read the stream is (note also tried variations of this with no effect)
- (void)doDataTransfer
{
#define EAD_INPUT_BUFFER_SIZE 4096
uint8_t buf[EAD_INPUT_BUFFER_SIZE];
while ([[self.dataSession inputStream] hasBytesAvailable])
{
NSInteger bytesRead = [[self.dataSession inputStream] read:buf maxLength:EAD_INPUT_BUFFER_SIZE];
if (_readData == nil) {
_readData = [[NSMutableData alloc] init];
}
/
if (bytesRead == 0) {
[[NSRunLoop currentRunLoop] runMode:NSDefaultRunLoopMode
beforeDate:[NSDate dateWithTimeIntervalSinceNow:0.25]];
continue;
}
[_readData appendBytes:(void *)buf length:bytesRead];
NSLog(@"_readData %d bytes from input stream", bytesRead);
}
NSLog(@"Done with doDataTransfer");
}
And what is seen in the log is:
[607:124939] Received stream handle event code: 1 - stream: <EAInputStream: 0x15e4e210>
[607:124939] Received stream handle event code: 2 - stream: <EAInputStream: 0x15e4e210>
[607:124939] _readData 2036 bytes from input stream
[607:124939] Done with doDataTransfer
[607:124939] Received stream handle event code: 2 - stream: <EAInputStream: 0x15e4e210>
[607:124939] _readData 2036 bytes from input stream
[607:124939] Done with doDataTransfer
[607:124939] Received stream handle event code: 2 - stream: <EAInputStream: 0x15e4e210>
[607:124939] _readData 2036 bytes from input stream
[607:124939] Done with doDataTransfer
[607:124939] Received stream handle event code: 2 - stream: <EAInputStream: 0x15e4e210>
[607:124939] _readData 2036 bytes from input stream
[607:124939] Done with doDataTransfer
...
The Received event code, read data, Done message triplets go for 13~14 times (~28000 bytes) then the events just stop coming in.