IPv6 auto-switching

[vincentneo]

According to #63:

Currently, no, because the library should automatically switch to IPv6 connection if it is better than IPv4 one. But we may add such option in a future, because it can slightly speed up connection creation time in case of unreliable IPv4.

Is that still the expected behaviour for TDLib? If so, I think I have another bug report to file, likely targeted for watchOS/HTTP connection only.

I realised that prefer_ipv6 must be explicitly set to true, in order to operate via IPv6.

My test was very simple (correct me if this way of testing is flawed):

1. Set Configure IPv4 to Off on Mac settings, leaving only the Configure IPv6 with Automatically.
2. Test that IPv6 connections are still possible by browsing http://ipv6.test-ipv6.com/index.html.en_US
3. Run a watchOS app on simulator with TDLib (latest master) and observe:

2023-06-15 23:51:45.945774+0800 Pigeon[82091:901856] PDTask <6B294476-7971-46B9-9274-719625D4BAA0>.<14> finished with error [-1009] Error Domain=NSURLErrorDomain Code=-1009 "The Internet connection appears to be offline." UserInfo={_kCFStreamErrorCodeKey=50, _NSURLErrorFailingURLSessionTaskErrorKey=LocalDataPDTask <6B294476-7971-46B9-9274-719625D4BAA0>.<14>, _NSURLErrorRelatedURLSessionTaskErrorKey=(
    "LocalDataPDTask <6B294476-7971-46B9-9274-719625D4BAA0>.<14>",
    "LocalDataTask <6B294476-7971-46B9-9274-719625D4BAA0>.<14>"
), NSLocalizedDescription=The Internet connection appears to be offline., _kCFStreamErrorDomainKey=1, NSErrorFailingURLStringKey=http://149.154.171.5:443/api, NSErrorFailingURLKey=http://149.154.171.5:443/api}
2023-06-15 23:51:45.946227+0800 Pigeon[82091:901856] Task <6B294476-7971-46B9-9274-719625D4BAA0>.<14> finished with error [-1009] Error Domain=NSURLErrorDomain Code=-1009 "The Internet connection appears to be offline." UserInfo={_kCFStreamErrorCodeKey=50, _NSURLErrorFailingURLSessionTaskErrorKey=LocalDataTask <6B294476-7971-46B9-9274-719625D4BAA0>.<14>, _NSURLErrorRelatedURLSessionTaskErrorKey=(
    "LocalDataTask <6B294476-7971-46B9-9274-719625D4BAA0>.<14>",
    "LocalDataPDTask <6B294476-7971-46B9-9274-719625D4BAA0>.<14>",
    "LocalDataTask <6B294476-7971-46B9-9274-719625D4BAA0>.<14>"
), NSLocalizedDescription=The Internet connection appears to be offline., _kCFStreamErrorDomainKey=1, NSErrorFailingURLStringKey=http://149.154.171.5:443/api, NSErrorFailingURLKey=http://149.154.171.5:443/api}

It is to be noted that the Simulator network stack is different from the actual Watch network stack, so again, correct me if I am testing it wrongly.

While the likelihood of users running on IPv6-only networks probably would be very low, I thought it would still be good to file this, as a 'just-in-case', since according to #63, this seems to be incorrect behaviour, though its a very outdated reference.

[levlam]

Check that the option "online" is set to true. Otherwise, TDLib may need much more time to start using IPv6 addresses.

[vincentneo]

Yes, for the build used to test the described issue, option “online” is set to true every time the app is active, and set to false every time right before app is exiting. (Can’t recall exact event that I used, will update again tomorrow)

That said, I did not test this for long. Probably about max 1 minute.

[levlam]

If the user is online, TDLib should automatically switch to IPv6 fast enough. definitely faster than in 1 minute.

[vincentneo]

(Can’t recall exact event that I used, will update again tomorrow)

WKApplication.didBecomeActiveNotification for setOption online true WKApplication.willResignActiveNotification for setOption online false

If the user is online, TDLib should automatically switch to IPv6 fast enough. definitely faster than in 1 minute.

I let it go for about 3 minutes today, still seeing the -1009 network errors shared earlier.

Here's the interesting thing that I observed today, even after re-enabling IPv4 (and at the point where IPv4 websites are already usable in Safari), the errors still keep streaming in, and attempting to open a chat (or do anything basically, that being an example), just didn't work.

[levlam]

This should be fixed now,