-1

I am using iOS but I am asking for networking in general. What does it mean to cancel a network request? Is there a message sent to the server or does the server acknowledge the socket being disconnected?

Michael Ozeryansky
  • 7,204
  • 4
  • 49
  • 61
  • depends on what phase the canceling is done and how the requesting object/class is constructed. – Ol Sen Jul 20 '20 at 02:04
  • So show an example how you cancel which request. – Ol Sen Jul 20 '20 at 02:07
  • @OlSen https://developer.apple.com/documentation/foundation/urlsessiontask/1411591-cancel – Michael Ozeryansky Jul 20 '20 at 02:28
  • 1
    then please change your question. `What does it mean to cancel a network request?`, `does the server acknowledge the socket being disconnected?` – Ol Sen Jul 20 '20 at 04:21
  • 1
    It's a complete different question if you want to know if there are protocols that make server sockets and client sockets talk in a way to know whats going on on the other side. Sockets, Tasks and Requests are completely different things. – Ol Sen Jul 20 '20 at 04:24
  • Your question was not down-voted because people don't understand how `URLSession` and TCP work. It was down-voted because your question is unclear and doesn't demonstrate research effort (especially in the context of the tags that you've now removed). Ol Sen and I were just trying to help you clarify your intent. You appear to have taken offense where none was intended. – Rob Jul 23 '20 at 20:35

1 Answers1

0

As you mention using NSURLSessionTask as your way to request, cancel() means a urlSession(_:task:didCompleteWithError:) will be send to the tasks delegate. But passing in a global error code NSURLErrorCancelled (-999) to the defined NSURLErrorDomain.

It is possible that cancelation is later called on the task as a complete processing of the request message is done. So it's up to you to act accordingly once your ErrorDomain is getting the error code NSURLErrorCancelled marking your intention to cancel, and therefore would want to throw away any data that is received since last request.

The Server gets possibly a complete request but your client is not receiving answers anymore. Or the request sequence is not complete so the Server recognises not correct what was intended but would work thru the request until it fails cause of incomplete or wrong formatted request data.

When your receiver callback is down do to canceling you just don't parse any answer of the Server and if you could still parse the Server data that would mean your task is still running. Any result after cancel() should be treated as possibly incomplete or misleading/wrong/invalid. This is why you set a NSURLErrorCancelled error to a NSURLErrorDomain, you want to know what the status is before you assume any received data is of value for you.

By the way NSURLErrorCancelled is also thrown when NSURLSessionAuthChallengeCancelAuthenticationChallenge is marking a server with no trust. So it's actually the same procedure, you decide if any received data is something you want to trust to.

If a socket is disconnected, there is no connection at all, no data passing thru, nothing to receive. nothing to request from. Any Error on both sides can't be exchanged. Server and Client are disconnected then.

Canceling a request does not imply a socket is stopped from working.

It just means the data since the last request is to be handled as invalid.

Why is this? Because you can construct your own sockets, ignoring ErrorDomain stuff with a complete different request pattern.

Also means in case of client error/crash/canceling nothing is send, you just do not accept any answer as valid even if it was delivered thru the sockets.

For this reasons there are Protocols that define how a message should look like and what should happen in case it was incomplete or would need any kind of validation in a given pattern that validates any data that was send. TCP, UDP, JS-Websocket with handshake and ongoing "dataflow", even OSC etc. and lots of other protocols.

Ol Sen
  • 3,163
  • 2
  • 21
  • 30