Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

NWSSLConnection fails to read and write #45

Open
MaximilianBrunner opened this issue Feb 14, 2017 · 1 comment
Open

NWSSLConnection fails to read and write #45

MaximilianBrunner opened this issue Feb 14, 2017 · 1 comment

Comments

@MaximilianBrunner
Copy link

MaximilianBrunner commented Feb 14, 2017

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).

@leovandriel
Copy link
Contributor

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants