Feature Request: completion handler for writes

[headlessme]

We've hit a case where we need to know when a write to the underlying socket has been completed. We're sending quite a large amount of latency sensitive data, such that the network can sometimes not keep up. It would be really helpful to be able to monitor when a write actually completes so we can scale back writes when the network slows down. The underlying Starscream WebSokcet class already provides this functionality via a completion handler called on write completion. Ideally this would be exposed up through socket.io as well.

We've considered using the ack mechanism from the server that's already supported by this library, but the extra latency that the network call introduces is unacceptable for our use case.

Is there a way to achieve this with the current APIs? And if not would you accept a PR adding this functionality?

[nuclearace]

You're welcome to give it a shot at implementing this.

[TimothyTim]

When is this going to be released?

[AgentFeeble]

Are there any updates on this? I see it's been merged into the develop branch, is there any way we can get a release for it?

[nuclearace]

I hope to get a new version out this week.

[AgentFeeble]

Awesome, thank you 👍

[vonox7]

Note that this feature introduced major crashes. When reverting it (see https://github.com/vonox7/socket.io-client-swift/commits/v-revert-completion-handler ) the crashes are gone.

Crashed: NSOperationQueue 0x280ab42e0 (QOS: UNSPECIFIED)
EXC_BAD_ACCESS KERN_INVALID_ADDRESS 0x0000000a35918130

Stacktrace:

Crashed: NSOperationQueue 0x280ab42e0 (QOS: UNSPECIFIED)
0  libobjc.A.dylib                0x1d853cd70 objc_msgSend + 16
1  Starscream                     0x1050ff6a8 protocol witness for WSStream.write(data:) in conformance FoundationStream (WebSocket.swift:241)
2  Starscream                     0x105105c30 closure #1 in WebSocket.dequeueWrite(_:code:writeCompletion:) (WebSocket.swift:1268)
3  Starscream                     0x1050fd244 thunk for @escaping @callee_guaranteed () -> () (<compiler-generated>)
4  Foundation                     0x1d9de3b6c __NSBLOCKOPERATION_IS_CALLING_OUT_TO_A_BLOCK__ + 16
5  Foundation                     0x1d9cebcc8 -[NSBlockOperation main] + 72
6  Foundation                     0x1d9ceb19c -[__NSOperationInternal _start:] + 740
7  Foundation                     0x1d9de5a40 __NSOQSchedule_f + 272
8  libdispatch.dylib              0x1d8d8f6c8 _dispatch_call_block_and_release + 24
9  libdispatch.dylib              0x1d8d90484 _dispatch_client_callout + 16
10 libdispatch.dylib              0x1d8d66e14 _dispatch_continuation_pop$VARIANT$armv81 + 404
11 libdispatch.dylib              0x1d8d664f8 _dispatch_async_redirect_invoke + 592
12 libdispatch.dylib              0x1d8d72afc _dispatch_root_queue_drain + 344
13 libdispatch.dylib              0x1d8d7335c _dispatch_worker_thread2 + 116
14 libsystem_pthread.dylib        0x1d8f72190 _pthread_wqthread + 472
15 libsystem_pthread.dylib        0x1d8f74d00 start_wqthread + 4

I think, that the main cause of this issue is that @headlessme introduced for every single call a requestHandler-closure, even when it is empty ({}). Before this commits, it was nil. This a) introduces a major performance hit and b) apparently is somehow not 100% save which leads to a lot of crashes in production.

Related issue: #1118

[headlessme]

See comment on #1118 as I haven't been able to reproduce this.