Memcached 1.6.0 UDP removal: testing integration without production credentials

Answer the Question First

Yes – a UDP‑to‑TCP shim such as socat can let legacy clients that still default to UDP talk to a Memcached 1.6.0 server. The shim listens on a UDP port and forwards each datagram to the server’s TCP port, preserving the client’s expectations while keeping production credentials out of the sandbox.

Latency Impact

Because UDP packets are forwarded over a new TCP connection for each request, the round‑trip time typically increases by 1–5 ms under light load. Under bursty traffic the overhead can grow to 10–20 ms due to TCP handshake and socket creation per packet, but remains far below the 100 ms latency seen with a real UDP listener. For most integration tests this added latency is acceptable.

SASL/TLS Considerations

Memcached’s SASL authentication requires a stateful TCP session; the shim merely transports the packets and does not interfere with the SASL handshake. However, TLS is impossible over UDP, so if your test client is configured to use TLS it will fail against the shim. In that case you must switch the client to plain TCP or use a separate TLS‑enabled Memcached instance for those tests.

Recommended Test Setup

1. Run Memcached 1.6.0 on TCP port 11211 (or 11212 for TLS). Example:
   memcached -p 11211 -l 127.0.0.1

2. Launch socat to translate UDP to TCP:
   socat UDP4-LISTEN:11211,fork TCP4:127.0.0.1:11211

3. Configure the legacy client to connect to 127.0.0.1:11211 using the -U flag (UDP). It will now hit the socat shim, which forwards the traffic to Memcached.

4. For TLS‑enabled tests, run Memcached with -S and use a TCP client configured with --tls. Do not rely on the UDP shim for TLS.

5. Verify connectivity and SASL handshake using a small benchmark tool or the client’s built‑in diagnostics.

What to Verify in Your Sandbox

• Connection from the legacy client succeeds and returns expected data.
• SASL authentication completes if enabled.
• Latency measurements stay within acceptable bounds (e.g., ping or custom script).

Unresolved Detail

Does your application use SASL authentication in the test environment, and if so, which mechanism (PLAIN, SCRAM‑SHA1, etc.)? This will determine whether the shim’s TCP session can carry the authentication state correctly.