Dualstack storage and client happy eyeballs support

• sites still "disable" IPv6 by not binding service to IPv6 while keeping AAAA records in DNS
• clients prefers IPv6 and waits for timeout before fallback to IPv4
  • this timeout can be too long so fallback mechanism doesn't work
  • addressed decade ago by happy eyeball fast fallback defined in RFC6555 / RFC8305
    • enabled by default in curl that comes with RHEL8 (curl 7.59.0)
    • used by XRootD HTTP-TPC on RHEL8
    • used by any DPM (can cause troubles LCGDM-2961 with by default enabled IP-based security)
• should our transfer clients deal better with these kind of connectivity issues?
  • davix (gfal2 / FTS) comes with alternative libcurl 7.69.0 backend
  • enabled by environment variable DAVIX_USE_LIBCURL=1

Status of non-adler32 checksum support in gfal2?

• Does gfal2 send Want-Digest during file upload?
  • no, this is not used
• e.g. transfer with MD5 checksum fails with dCache destination
  • truncate -s 1M /tmp/1M
  • gfal-copy -f --checksum-mode=both --checksum md5:b6d81b360a5672d80c27430f39153e2c file:///tmp/1M davs://se1.farm.particle.cz/dpm/farm.particle.cz/home/atlas/atlasscratchdisk/SAM/x
  • this transfer fails
• dCache store MD5 only if upload comes with corresponding Want-Digest, e.g.
  • curl -v --capath /etc/grid-security/certificates -X PUT -L -H 'Want-Digest: md5' -H 'Authorization: Bearer secret' --upload-file /tmp/1M https://se1.farm.particle.cz/dpm/farm.particle.cz/home/atlas/atlasscratchdisk/SAM/x
  • this transfer succeeds and MD5 is also stored with file metadata
• dCache doesn't generally support non-default checksum
  • default is configured per-pool (filesystem) using csm set checksumtype
  • only some protocols (e.g. WebDAV, GridFTP) support additional checksum type per transfer
  • impossible(?) to specify alternative checksum type for xroot protocol