|
|
|
# Copyright (C) The c-ares project and its contributors
|
|
|
|
# SPDX-License-Identifier: MIT
|
|
|
|
name: Alpine (latest)
|
|
|
|
on:
|
|
|
|
push:
|
|
|
|
pull_request:
|
|
|
|
|
|
|
|
concurrency:
|
|
|
|
group: ${{ github.ref }}-alpine-latest
|
|
|
|
cancel-in-progress: true
|
|
|
|
|
|
|
|
env:
|
|
|
|
TEST_FILTER: "--gtest_filter=-*LiveSearchTXT*:*LiveSearchANY*"
|
|
|
|
CMAKE_FLAGS: "-DCMAKE_BUILD_TYPE=DEBUG -DCARES_STATIC=ON -DCARES_STATIC_PIC=ON -G Ninja"
|
|
|
|
MAKE: make
|
|
|
|
|
|
|
|
jobs:
|
|
|
|
build:
|
|
|
|
runs-on: ubuntu-latest
|
|
|
|
container:
|
|
|
|
image: alpine:latest
|
|
|
|
# Needed for TCP FastOpen
|
|
|
|
options: --privileged
|
|
|
|
name: "Alpine (latest)"
|
|
|
|
steps:
|
|
|
|
- name: Install packages
|
|
|
|
run: |
|
|
|
|
apk add bash cmake samurai gtest-dev autoconf autoconf-archive automake libtool pkgconf make clang17 clang17-analyzer compiler-rt lldb gcc g++ valgrind gdb sudo
|
|
|
|
- name: Checkout c-ares
|
|
|
|
uses: actions/checkout@v4
|
Implement TCP FastOpen (TFO) RFC7413 (#840)
TCP Fast Open (TFO) allows TCP connection establishment in 0-RTT when a
client and server have previously communicated. The SYN packet will also
contain the initial data packet from the client to the server. This
means there should be virtually no slowdown over UDP when both sides
support TCP FastOpen, which is unfortunately not always the case. For
instance, `1.1.1.1` appears to support TFO, however `8.8.8.8` does not.
This implementation supports Linux, Android, FreeBSD, MacOS, and iOS.
While Windows does have support for TCP FastOpen it does so via
completion APIs only, and that can't be used with polling APIs like used
by every other OS. We could implement it in the future if desired for
those using `ARES_OPT_EVENT_THREAD`, but it would probably require
adopting IOCP completely on Windows.
Sysctls are required to be set appropriately:
- Linux: `net.ipv4.tcp_fastopen`:
- `1` = client only (typically default)
- `2` = server only
- `3` = client and server
- MacOS: `net.inet.tcp.fastopen`
- `1` = client only
- `2` = server only
- `3` = client and server (typically default)
- FreeBSD: `net.inet.tcp.fastopen.server_enable` (boolean) and
`net.inet.tcp.fastopen.client_enable` (boolean)
This feature is always-on, when running on an OS with the capability
enabled. Though some middleboxes have impacted end-to-end TFO and caused
connectivity errors, all modern OSs perform automatic blackholing of IPs
that have issues with TFO. It is not expected this to cause any issues
in the modern day implementations.
This will also help with improving latency for future DoT and DoH
implementations.
Authored-By: Brad House (@bradh352)
4 months ago
|
|
|
- name: "Make sure TCP FastOpen is enabled"
|
|
|
|
run: |
|
|
|
|
sudo sysctl -w net.ipv4.tcp_fastopen=3
|
|
|
|
- name: "CMake: build and test c-ares"
|
|
|
|
env:
|
|
|
|
BUILD_TYPE: CMAKE
|
|
|
|
CMAKE_TEST_FLAGS: "-DCARES_BUILD_CONTAINER_TESTS=ON"
|
|
|
|
TEST_DEBUGGER: gdb
|
|
|
|
run: |
|
|
|
|
./ci/build.sh
|
|
|
|
./ci/test.sh
|
|
|
|
- name: "Autotools: build and test c-ares"
|
|
|
|
env:
|
|
|
|
BUILD_TYPE: autotools
|
|
|
|
TEST_DEBUGGER: gdb
|
|
|
|
run: |
|
|
|
|
./ci/build.sh
|
|
|
|
./ci/test.sh
|
|
|
|
- name: "CMake: UBSAN: build and test c-ares"
|
|
|
|
env:
|
|
|
|
BUILD_TYPE: "ubsan"
|
|
|
|
CC: "clang"
|
|
|
|
CXX: "clang++"
|
|
|
|
CMAKE_TEST_FLAGS: "-DCARES_BUILD_CONTAINER_TESTS=ON"
|
|
|
|
CFLAGS: "-fsanitize=undefined -fno-sanitize-recover"
|
|
|
|
CXXFLAGS: "-fsanitize=undefined -fno-sanitize-recover"
|
|
|
|
LDFLAGS: "-fsanitize=undefined"
|
|
|
|
TEST_DEBUGGER: "none"
|
|
|
|
run: |
|
|
|
|
./ci/build.sh
|
|
|
|
./ci/test.sh
|
|
|
|
- name: "CMake: ASAN: build and test c-ares"
|
|
|
|
env:
|
|
|
|
BUILD_TYPE: "asan"
|
|
|
|
CC: "clang"
|
|
|
|
CXX: "clang++"
|
|
|
|
CMAKE_TEST_FLAGS: "-DCARES_BUILD_CONTAINER_TESTS=ON"
|
|
|
|
CFLAGS: "-fsanitize=address"
|
|
|
|
CXXFLAGS: "-fsanitize=address"
|
|
|
|
LDFLAGS: "-fsanitize=address"
|
|
|
|
TEST_DEBUGGER: "none"
|
|
|
|
run: |
|
|
|
|
./ci/build.sh
|
|
|
|
./ci/test.sh
|
Implement TCP FastOpen (TFO) RFC7413 (#840)
TCP Fast Open (TFO) allows TCP connection establishment in 0-RTT when a
client and server have previously communicated. The SYN packet will also
contain the initial data packet from the client to the server. This
means there should be virtually no slowdown over UDP when both sides
support TCP FastOpen, which is unfortunately not always the case. For
instance, `1.1.1.1` appears to support TFO, however `8.8.8.8` does not.
This implementation supports Linux, Android, FreeBSD, MacOS, and iOS.
While Windows does have support for TCP FastOpen it does so via
completion APIs only, and that can't be used with polling APIs like used
by every other OS. We could implement it in the future if desired for
those using `ARES_OPT_EVENT_THREAD`, but it would probably require
adopting IOCP completely on Windows.
Sysctls are required to be set appropriately:
- Linux: `net.ipv4.tcp_fastopen`:
- `1` = client only (typically default)
- `2` = server only
- `3` = client and server
- MacOS: `net.inet.tcp.fastopen`
- `1` = client only
- `2` = server only
- `3` = client and server (typically default)
- FreeBSD: `net.inet.tcp.fastopen.server_enable` (boolean) and
`net.inet.tcp.fastopen.client_enable` (boolean)
This feature is always-on, when running on an OS with the capability
enabled. Though some middleboxes have impacted end-to-end TFO and caused
connectivity errors, all modern OSs perform automatic blackholing of IPs
that have issues with TFO. It is not expected this to cause any issues
in the modern day implementations.
This will also help with improving latency for future DoT and DoH
implementations.
Authored-By: Brad House (@bradh352)
4 months ago
|
|
|
- name: "CMake: Static Analyzer: build c-ares"
|
|
|
|
env:
|
|
|
|
BUILD_TYPE: "analyze"
|
|
|
|
CC: "clang"
|
|
|
|
CXX: "clang++"
|
Implement TCP FastOpen (TFO) RFC7413 (#840)
TCP Fast Open (TFO) allows TCP connection establishment in 0-RTT when a
client and server have previously communicated. The SYN packet will also
contain the initial data packet from the client to the server. This
means there should be virtually no slowdown over UDP when both sides
support TCP FastOpen, which is unfortunately not always the case. For
instance, `1.1.1.1` appears to support TFO, however `8.8.8.8` does not.
This implementation supports Linux, Android, FreeBSD, MacOS, and iOS.
While Windows does have support for TCP FastOpen it does so via
completion APIs only, and that can't be used with polling APIs like used
by every other OS. We could implement it in the future if desired for
those using `ARES_OPT_EVENT_THREAD`, but it would probably require
adopting IOCP completely on Windows.
Sysctls are required to be set appropriately:
- Linux: `net.ipv4.tcp_fastopen`:
- `1` = client only (typically default)
- `2` = server only
- `3` = client and server
- MacOS: `net.inet.tcp.fastopen`
- `1` = client only
- `2` = server only
- `3` = client and server (typically default)
- FreeBSD: `net.inet.tcp.fastopen.server_enable` (boolean) and
`net.inet.tcp.fastopen.client_enable` (boolean)
This feature is always-on, when running on an OS with the capability
enabled. Though some middleboxes have impacted end-to-end TFO and caused
connectivity errors, all modern OSs perform automatic blackholing of IPs
that have issues with TFO. It is not expected this to cause any issues
in the modern day implementations.
This will also help with improving latency for future DoT and DoH
implementations.
Authored-By: Brad House (@bradh352)
4 months ago
|
|
|
SCAN_WRAP: "scan-build -v --status-bugs"
|
|
|
|
CMAKE_TEST_FLAGS: "-DCARES_BUILD_TESTS=OFF"
|
|
|
|
TEST_DEBUGGER: "lldb"
|
|
|
|
run: |
|
|
|
|
./ci/build.sh
|
|
|
|
./ci/test.sh
|
|
|
|
- name: "Valgrind: build and test c-ares (no TCP FastOpen)"
|
|
|
|
env:
|
|
|
|
BUILD_TYPE: "valgrind"
|
|
|
|
TEST_WRAP: "valgrind --leak-check=full"
|
|
|
|
TEST_FILTER: "--gtest_filter=-*Container*:*LiveSearchANY*:*LiveSearchTXT*"
|
|
|
|
CMAKE_TEST_FLAGS: "-DCARES_BUILD_TESTS=ON"
|
|
|
|
TEST_DEBUGGER: none
|
|
|
|
run: |
|
Implement TCP FastOpen (TFO) RFC7413 (#840)
TCP Fast Open (TFO) allows TCP connection establishment in 0-RTT when a
client and server have previously communicated. The SYN packet will also
contain the initial data packet from the client to the server. This
means there should be virtually no slowdown over UDP when both sides
support TCP FastOpen, which is unfortunately not always the case. For
instance, `1.1.1.1` appears to support TFO, however `8.8.8.8` does not.
This implementation supports Linux, Android, FreeBSD, MacOS, and iOS.
While Windows does have support for TCP FastOpen it does so via
completion APIs only, and that can't be used with polling APIs like used
by every other OS. We could implement it in the future if desired for
those using `ARES_OPT_EVENT_THREAD`, but it would probably require
adopting IOCP completely on Windows.
Sysctls are required to be set appropriately:
- Linux: `net.ipv4.tcp_fastopen`:
- `1` = client only (typically default)
- `2` = server only
- `3` = client and server
- MacOS: `net.inet.tcp.fastopen`
- `1` = client only
- `2` = server only
- `3` = client and server (typically default)
- FreeBSD: `net.inet.tcp.fastopen.server_enable` (boolean) and
`net.inet.tcp.fastopen.client_enable` (boolean)
This feature is always-on, when running on an OS with the capability
enabled. Though some middleboxes have impacted end-to-end TFO and caused
connectivity errors, all modern OSs perform automatic blackholing of IPs
that have issues with TFO. It is not expected this to cause any issues
in the modern day implementations.
This will also help with improving latency for future DoT and DoH
implementations.
Authored-By: Brad House (@bradh352)
4 months ago
|
|
|
sudo sysctl -w net.ipv4.tcp_fastopen=0
|
|
|
|
./ci/build.sh
|
|
|
|
./ci/test.sh
|