You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The error code "errSSLWouldBlock" in the methods - (BOOL)write:(NSData *)data length:(NSUInteger *)length error:(NSError *__autoreleasing *)error;
and - (BOOL)read:(NSMutableData *)data length:(NSUInteger *)length error:(NSError *__autoreleasing *)error;
is handled as if the data was successfully written / read.
If this code is used for sending lots of notifications only the first few would make it into the socket send buffer until the kernel would report "EAGAIN" or "EWOULDBLOCK".
If the socket is marked as nonblocking the kernel is allowed to report "EAGAIN" or "EWOULDBLOCK" for any reason but most of the time it is because of a full buffer.
SecureTransport is reporting this by setting "errSSLWouldBlock" after the SSLWrite() attempt.
The same is true for reading.
A quick fix would be to just return NO on this error or to loop until all bytes are in the buffer.
A full solution would be to implement a write buffer:
When the user wants to send data, append it to buffer.
Delete the amount of bytes written by SSLWrite() from the beginning of the buffer.
When SSLWrite() dose not manage to write all the data or returns errSSLWouldBlock try again later by monitoring the socket for the next write event with GCD, kqueue, poll() or select().
There are great all in one solutions on git that could be used as a drop-in solution for NWSSLConnection (GCDAsyncSocket for example).
The text was updated successfully, but these errors were encountered:
Thanks for reporting this issue. This is a limitation of the approach I took to handling non-blocking I/O. It seems that your suggested quick fix is breaking the app, even for single pushes. Indeed, a proper solution would be to switch to a drop-in alternative. I have refrained from doing so to avoid any external dependencies. For now I'm marking this as enhancement.
The error code "errSSLWouldBlock" in the methods
- (BOOL)write:(NSData *)data length:(NSUInteger *)length error:(NSError *__autoreleasing *)error;
and
- (BOOL)read:(NSMutableData *)data length:(NSUInteger *)length error:(NSError *__autoreleasing *)error;
is handled as if the data was successfully written / read.
If this code is used for sending lots of notifications only the first few would make it into the socket send buffer until the kernel would report "EAGAIN" or "EWOULDBLOCK".
If the socket is marked as nonblocking the kernel is allowed to report "EAGAIN" or "EWOULDBLOCK" for any reason but most of the time it is because of a full buffer.
SecureTransport is reporting this by setting "errSSLWouldBlock" after the SSLWrite() attempt.
The same is true for reading.
A quick fix would be to just return NO on this error or to loop until all bytes are in the buffer.
A full solution would be to implement a write buffer:
There are great all in one solutions on git that could be used as a drop-in solution for NWSSLConnection (GCDAsyncSocket for example).
The text was updated successfully, but these errors were encountered: