0

I'm experiencing issues building a resilient connection from my iOS app to my API in case of spotty connections. Ideally, I would like to make the connection as resilient as possible through e.g. resending requests to the API.

More specifically:

  • Transport is using HTTPs
  • Response is JSON based, usually only a few kB
  • API is hosted on Heroku

What would be a suitable algorithmic approach to handle such a "spotty connectivity" problem? It seems that a lot of apps handle this well, e.g. voice channels on Discord or calls through WhatsApp.

I'm currently looking into:

  • Cancelling and resending requests
  • "Warming up" the HTTPs connection through keep-alive long polling as the initial crypto handshake seems quite heavy
  • Sending multiple requests in parallel

The goal is to eliminate RTTs as much as possible. The request is small but should go through quickly because the user should not have to wait for their response.

Happy to find out how other solved this.

Carl
  • 41
  • 3

1 Answers1

0

In very simple terms:

  • TCP/IP is connection orientated - its sets up end to end connections and enables reliable transport but the reliability comes at the expense of some more overhead
  • UDP/IP is connectionless - it does not set up end to end connections in advance or check receipt of sent data and hence can be less reliable but it is fast and has low overhead

VoIP apps generally favour UDP for the speech part - this is because speed/delay is important, and occasional packet loss is not that big an issue.

Where it is essential not to lose any packets, for example the signalling to set up VoIP calls, TCP or another protocol which checks for and retransmits lost packets is generally preferred.

Note that there are exceptions to the above - for example TCP generally traverses firewalls better than UDP, which may be blocked due to security to traffic policy reasons, so VoIP speech may sometimes be sent over TCP for part of its journey at least.

It sounds like TCP is probably a good candidate for your needs - there are other protocols such as SCTP (https://en.wikipedia.org/wiki/Stream_Control_Transmission_Protocol) but I'm not sure they can be generally shown to be any faster for the type of communication you describe.

Mick
  • 24,231
  • 1
  • 54
  • 120