Custom Query (2195 matches)

This patch changes the BSD sockets implementation of QoS to use IPV6_TCLASS for IPv6 sockets instead of IP_TOS.

Summary of changes:

• new constant PJ_IPV6_TCLASS, wrapper of IPV6_TCLASS (if defined) or 0xFFFF, because there is no sane default - all operating systems that implement the IPV6_TCLASS option assign a different value to it, and no RFC standardizes it
• pj_IPV6_TCLASS() wrapper for PJ_IPV6_TCLASS constant
• pj_sock_set_qos_params and pj_sock_get_qos_params now check for the socket address family before trying to set or get the socket's QoS: if the socket is IPv4, they will use pj_IP_TOS() as before, if the socket is IPv6 they will use pj_IPV6_TCLASS() instead. Before, using QoS on an IPv6 socket would unconditionally fail with PJ_STATUS_FROM_OS(EINVAL), now it will succeed if the OS supports IPV6_TCLASS (or fail with PJ_STATUS_FROM_OS(ENOPROTOOPT) if it doesn't)

Thanks to Michele Cicciotti for the patch.

The latest XNU kernel, shipped with iOS 10, Mac OS 10.11, AppleTV OS 10, etc. supports a new socket option, SO_NET_SERVICE_TYPE, a high level API for configuring a socket's QoS, which the OS will appropriately and transparently map to a DSCP or WMM priority depending on the network connection.

This patch introduces a new implementation of the socket QoS functions specifically for the Darwin platform, that makes use of SO_NET_SERVICE_TYPE when available, and falls back to IP_TOS/IPV6_TCLASS elsewhere.

Changes introduced by this patch:

• build system and configuration script changes, so that the BSD sockets implementation of QoS is no longer the default on all platforms, but only on non-Darwin platforms. On Darwin platforms, the new Darwin-specific QoS implementation is used instead
• new PJ_QOS_TYPE_SIGNALLING in pj_qos_type which corresponds to NET_SERVICE_TYPE_SIG
• new PJLIB constant OSERR_ENOPROTOOPT, that maps to ENOPROTOOPT (WSAENOPROTOOPT for Winsock)
• new configuration constant PJ_QOS_DARWIN, that can be used as the value of PJ_QOS_IMPLEMENTATION
• new, Darwin-specific implementations of pj_sock_set_qos_params, pj_sock_set_qos_type, pj_sock_get_qos_params and pj_sock_get_qos_type, based on SO_NET_SERVICE_TYPE, and falling back to IP_TOS/IPV6_TCLASS

Backwards/forwards compatibility considerations: on older Darwin platforms, the SDK doesn't define SO_NET_SERVICE_TYPE, and QoS functions always use IP_TOS/IPV6_TCLASS instead. Running code compiled with an old SDK on a new operating system has the same behavior as it had before, and like before with the caveat that, at some point in the future, the OS may start ignoring the value set with IP_TOS/IPV6_TCLASS on newer Darwin platforms, SO_NET_SERVICE_TYPE is always used.

Running code compiled with a new SDK on an old operating system makes attempts to get/set SO_NET_SERVICE_TYPE fail with ENOPROTOOPT, which the QoS function translate to PJ_ENOTSUP, which is handled with a runtime fallback on the old IP_TOS/IPV6_TCLASS code.

For future reference, mapping of pj_qos_type might be changed according to the new standard. Please have a look at the draft: ​https://tools.ietf.org/html/draft-ietf-tsvwg-ieee-802-11-00

Thanks to Michele Cicciotti for the patch.

Starting NDK r13, Android NDK has set NDK_TOOLCHAIN_VERSION default value to Clang. This will result the configure-android to fail with this error:

configure-android error: compiler not found, please check environment 
settings (TARGET_ABI, etc)

Furthermore, r13 release notes states that:

GCC is no longer supported. It will not be removed from the NDK just yet, 
but is no longer receiving backports. 
It cannot be removed until after libc++ has become stable enough to be the default, 
as some parts of gnustl are still incompatible with Clang. 
It will likely be removed after that point.

So, the same issue should be expected on r14 and later.

At the moment (on r13), you can force the ndk to use gcc by specifying the NDK_TOOLCHAIN_VERSION to 4.9.

e.g:

NDK_TOOLCHAIN_VERSION=4.9 TARGET_ABI=armeabi-v7a ./configure-android --use-ndk-cflags

Update:

Since r5620. configure-android have been modified to support clang, hence user wouldn't need to specify NDK_TOOLCHAIN_VERSION.

Known Issue when building with clang:

When building for older android device, it is needed to specify APP_PLATFORM.

e.g: APP_PLATFORM=android-17

The build might fail with these error:

In file included from ../../yuv/source/compare.cc:14:
/app/android-ndk-r13b//sources/cxx-stl/llvm-libc++/include/math.h:661:91: error: use of undeclared identifier 'acosl'
inline _LIBCPP_INLINE_VISIBILITY long double acos(long double __lcpp_x) _NOEXCEPT {return acosl(__lcpp_x);}
                                                                                          ^
/app/android-ndk-r13b//sources/cxx-stl/llvm-libc++/include/math.h:673:91: error: use of undeclared identifier 'asinl'
inline _LIBCPP_INLINE_VISIBILITY long double asin(long double __lcpp_x) _NOEXCEPT {return asinl(__lcpp_x);}

The error is described in detail in ​here.

To handle it user need to include $(NDKRoot)/sources/android/support/include in the CFLAGS (user.mak).