Isolate host-side TCP forwarding before attributing a speedup to public tunnel ingress
The direct answer is qualified: eBPF SOCKMAP can reduce host-side forwarding work for eligible mapped TCP sockets, but no end-to-end Localtonet performance gain is established without measurements. SK_MSG acceleration applies only when the selected socket types, program attachments, map membership, traffic direction, kernel configuration, and implementation architecture support it. This guide is a benchmarking methodology and architecture guide, not a universal SOCKMAP implementation tutorial. It shows how to compare direct, conventional proxy, accelerated, and public Localtonet paths without inventing a speedup or confusing local forwarding cost with tunnel latency.
📋 What's in this guide
The short answer: possibly locally, but not yet proven end to end
SOCKMAP can improve an eligible local TCP forwarding path by allowing socket-layer eBPF programs to operate on sockets stored in a SOCKMAP or SOCKHASH. An SK_MSG program can return pass or drop verdicts and can redirect supported messages to another socket. That can remove work performed by a conventional user-space byte-forwarding loop in a compatible architecture.
This does not establish that a Localtonet endpoint will have lower latency, greater throughput, or lower CPU consumption. The public measurement also includes the remote client, internet route, Localtonet relay path, Localtonet client, application behavior, and any forwarding layers that remain on the host. A small local improvement can be hidden by wider end-to-end variation. Conversely, an optimization might reduce host CPU while having no detectable effect on remote latency.
The accurate conclusion before testing is therefore:
SOCKMAP may reduce host-side forwarding work for eligible mapped TCP sockets. It does not accelerate the external network or Localtonet relay path, and this article reports no benchmark result proving a Localtonet performance gain. Any claimed improvement must be measured against equivalent direct, proxy, accelerated, and public workloads.
Eligibility is narrower than simply running Linux and loading an eBPF object. The test needs compatible sockets, the required kernel capabilities, successful program attachment, correct socket insertion into the map, supported traffic direction, an implementation that associates each connection with the correct peer, and a workload that actually spends meaningful time in the forwarding layer. If one of those conditions is absent, the accelerated path may not be used at all.
Start with the complete ingress data path
A public TCP request reaching a Linux application can cross several independently measurable stages. With Localtonet, our client application on the Linux device establishes an outbound connection to a Localtonet relay server. This provides a public host and port for the configured TCP service without requiring inbound router port forwarding, firewall changes, VPN setup, or a public IP address.
The relay path delivers traffic through the connected client to the configured local IP address and port. What happens after that depends on the host architecture. The target might be the application listener itself, a user-space reverse proxy, a sidecar, or another forwarding component.
A conventional proxy commonly accepts one connection, chooses an upstream, opens or reuses another connection, and moves data between the two sides. It may also authenticate clients, inspect an application protocol, normalize requests, apply timeouts, route by metadata, log transactions, limit traffic, or manage upstream health. Only part of that work is simple byte forwarding.
An end-to-end benchmark reports the combined cost of all participating stages. It can include remote network delay, relay transit, Localtonet client processing, local proxy work, Linux scheduling, application processing, storage or dependency access, and the benchmark client itself. One remote latency number cannot identify which stage changed.
Use multiple measurement boundaries. A direct local application test establishes the host-side reference for the selected workload. A conventional proxy test measures the deployed user-space path. A verified SOCKMAP test measures the eligible accelerated path. A remote test through Localtonet measures the complete public workflow. These results answer related but different questions.
A response measured from a remote client includes every stage between that client and the application. Record local baselines alongside public results. Avoid estimating tunnel overhead by subtracting unrelated medians because queueing, connection reuse, CPU contention, and internet conditions can differ between runs.
What SOCKMAP, SOCKHASH, and SK_MSG actually do
SOCKMAP and SOCKHASH are eBPF map types that hold references to sockets. SOCKMAP uses array-style indexing, while SOCKHASH supports hash-based keys. The Linux kernel documentation describes their supported socket use, program attachment model, redirection behavior, and limitations in the kernel SOCKMAP and SOCKHASH documentation.
A control plane is still required. It discovers or creates eligible sockets, associates each source socket with the correct destination, inserts socket references into the map, removes them at the appropriate lifecycle point, and responds to failures. The map is not a listener, connection acceptor, service discovery system, or upstream selection policy by itself.
An eBPF program of type SK_MSG can run on the message path associated with sockets participating in the map. The Linux kernel SK_MSG program documentation defines the program type and its context. Depending on the program and supported helpers, it can pass, drop, or redirect eligible messages. A redirect can target another socket stored in a SOCKMAP or SOCKHASH.
The kernel helper interface includes message redirect helpers for maps and hashes. Their precise arguments, flags, return semantics, and availability must be checked against the running kernel and selected implementation. The canonical descriptions are in the Linux eBPF helper documentation.
Attachment alone is not proof that the desired flow is accelerated. The relevant program must be attached at the expected hook, the source socket must be under the expected map behavior, the destination lookup must succeed, and the traffic must traverse the direction evaluated by that program. Bidirectional protocols can require explicit handling for both directions. Socket creation, connection establishment, closure, and errors still need lifecycle management.
| Component | What it provides | What it does not provide |
|---|---|---|
| SOCKMAP | Array-indexed references to eligible sockets | A public listener, automatic pairing, or proxy policy |
| SOCKHASH | Hash-keyed references to eligible sockets | Automatic discovery or lifecycle cleanup |
| SK_MSG program | A message-path verdict and supported redirection logic | Application-aware routing unless explicitly implemented and safe |
| Control plane | Socket pairing, map updates, attachment, cleanup, and error handling | Guaranteed correctness merely because the eBPF program loaded |
| Localtonet TCP tunnel | Public TCP reachability to a configured local IP address and port | Automatic optimization of the host forwarding architecture |
Verifier acceptance is necessary but not sufficient
Before an eBPF program can run, the kernel verifier checks properties such as control flow, register and pointer use, helper calls, and bounded execution according to the kernel's verification model. The Linux eBPF verifier documentation explains this analysis and its constraints.
A successful verifier result means that the program satisfied the verifier for that kernel. It does not prove that the program pairs the correct tenants, selects the intended upstream, preserves application policy, removes stale sockets, or handles all concurrency and failure cases. Logical correctness still requires code review and workload-specific testing.
SOCKMAP cannot transparently reproduce application-layer proxy behavior
Socket redirection is not a transparent replacement for every reverse proxy. A proxy can own protocol parsing, authentication, authorization, rate controls, request logging, header modification, routing, retries, health checks, timeout policy, connection pooling, and traffic accounting. An SK_MSG fast path does not automatically preserve those features.
If an accelerated comparison disables required behavior, it is not production-equivalent. Either retain the proxy as the policy and control point, use an implementation explicitly designed to preserve the required semantics, or accept that the accelerated path is only a laboratory reference.
Pass, drop, and redirect behavior exists within a larger socket architecture. Safe fallback depends on connection ownership, map state, proxy behavior, and policy placement. Test missing map entries, failed updates, stale sockets, control-plane restarts, and rejected redirects explicitly.
Scope: a reproducible methodology, not a universal loader recipe
There is no implementation-independent sequence of build, load, attach, populate, and inspect commands. Those commands depend on the source tree, loader, map names, object format, socket-discovery design, control plane, privileges, kernel, and namespace layout. Presenting placeholder loader commands as universal instructions would be misleading and potentially unsafe.
This article therefore defines a reproducible benchmarking contract rather than selecting an unreviewed third-party implementation. Before executing the accelerated variant, choose a reviewed SOCKMAP implementation and create an implementation record containing:
- The repository URL and immutable source revision.
- The implementation's license and review status.
- The supported kernel range and required kernel configuration.
- Compiler, linker, libbpf or loader, bpftool, and build-system versions.
- The exact documented build commands used for that revision.
- The exact loader and control-plane startup commands.
- The map names, key format, socket eligibility rules, and pairing behavior.
- The SK_MSG attachment mechanism and supported traffic directions.
- The documented inspection commands for programs, links, maps, and counters.
- The expected shutdown sequence and map cleanup behavior.
If the selected project does not document how sockets enter and leave its map, how attachment is verified, how redirects are counted, or what happens on failure, it is not suitable for a defensible benchmark. A successful request is insufficient because the request may have followed a conventional path.
Pin the source revision instead of benchmarking a moving branch name. Save the build log, compiler identity, generated object hash, loader output, verifier output, configuration, and startup command with the results. This makes the implementation-specific part reproducible without pretending that all SOCKMAP projects share one interface.
Prepare a controlled Linux benchmarking lab
Use a disposable or non-production Linux machine for initial testing. Loading eBPF programs and controlling socket maps can require elevated privileges and can alter the behavior of traffic handled by the tested processes. The exact privilege model depends on the kernel, security policy, loader, namespaces, and container runtime. Do not grant unrestricted production privileges simply to make an experiment start.
Kernel and tool capability checks
A kernel version string alone is not enough. Distributions can enable, disable, or backport BPF capabilities. Inspect the running host and preserve the output:
uname -a
bpftool version
bpftool feature probe kernelThe feature probe may need additional privilege to provide complete results. Its output is host-specific. Use it to identify reported program types, map types, helpers, and kernel configuration rather than assuming support from a version number. The accepted syntax and output fields for the installed tool are described in the kernel bpftool feature documentation.
Also preserve general BPF inventory before and after loading the selected implementation:
bpftool prog show
bpftool map show
bpftool link showNot every implementation uses a persistent BPF link for every attachment, so an empty or unchanged link listing does not prove that no program is attached. Follow the selected implementation's documented inspection method and correlate it with program and map state.
Required lab roles
Install ordinary benchmark prerequisites
The exact packages depend on the distribution and selected implementation. At minimum, prepare the implementation's compiler and loader prerequisites, bpftool compatible with the host, standard socket inspection tools, a workload generator appropriate for the application protocol, and CPU or process accounting tools already approved for the machine.
For an unstructured TCP throughput check, iperf3 is useful if every path can forward its protocol unchanged. For application requests, use a client that speaks the real protocol. Do not substitute an HTTP benchmark for a raw TCP service or compare two generators with different connection behavior.
Define addresses as environment variables to reduce accidental drift:
export DIRECT_HOST=127.0.0.1
export DIRECT_PORT=9000
export PROXY_HOST=127.0.0.1
export PROXY_PORT=9001
export ACCEL_HOST=127.0.0.1
export ACCEL_PORT=9002
export TEST_SECONDS=30
export PARALLEL_STREAMS=4These are illustrative lab values, not Localtonet settings. Replace them with ports owned by the selected backend and forwarding implementations. Record the final values in the benchmark manifest.
Define the workload before seeing results
Record request and response sizes, payload contents, connection reuse, concurrent connections, run duration, warm-up duration, trial count, application behavior, CPU policy, proxy settings, kernel identity, eBPF object identity, and the Localtonet target. Define success and failure criteria before comparing numbers.
Include at least three workload shapes: small bidirectional exchanges, sustained streams, and connection-heavy traffic. Established-message redirection may affect these differently. A workload dominated by connection setup can spend much of its time outside the steady-state SK_MSG data path.
Build and execute the local comparison
Begin with correctness. Every variant must return equivalent application-level results. Verify both directions where the protocol is bidirectional, clean close behavior, half-close if used, timeouts, parallel connections, and response identity.
Freeze the environment
Record the host, kernel, CPU policy, application build, proxy build, selected SOCKMAP source revision, object hash, payloads, concurrency, connection behavior, warm-up, duration, and trial count.
Validate the backend directly
Connect directly to the backend listener, verify the expected response, and inspect the listening socket. Do not continue until the application is stable without either forwarding layer.
Measure direct local TCP
Run the predefined workloads against the application and collect latency, throughput, CPU, context switches, errors, resets, and response-integrity results.
Measure the conventional proxy
Send the identical workloads to the normal proxy listener. Confirm that it uses the same backend and retains all required security, routing, timeout, and protocol behavior.
Build and start the pinned implementation
Follow the selected revision's reviewed build and startup documentation exactly. Save the commands, build output, object hash, loader output, and verifier diagnostics. Do not substitute generic commands from another project.
Prove map population and attachment
Use the implementation's supported inspection method to confirm the intended SK_MSG attachment and socket entries. Document how each socket pair enters the map, how keys identify peers, and when entries leave.
Measure the accelerated path
Repeat the same workloads, trial count, warm-up, duration, payloads, and concurrency. Confirm that redirect counters increase and that completed responses remain correct.
Inject failures and clean up
Test missing entries, control-plane restart, socket close, stale-state handling, and rejected setup. Then stop the implementation using its documented procedure, detach programs where required, and confirm that temporary map state is gone.
Executable local checks
Confirm listeners and established TCP state:
ss -ltn
ss -tinIf iperf3 is an appropriate protocol for the lab, run the same stream workload against each listener:
iperf3 -c "$DIRECT_HOST" -p "$DIRECT_PORT" -t "$TEST_SECONDS" -P "$PARALLEL_STREAMS"
iperf3 -c "$PROXY_HOST" -p "$PROXY_PORT" -t "$TEST_SECONDS" -P "$PARALLEL_STREAMS"
iperf3 -c "$ACCEL_HOST" -p "$ACCEL_PORT" -t "$TEST_SECONDS" -P "$PARALLEL_STREAMS"Expected output includes interval-level transfer and bitrate data, followed by sender and receiver summaries. A successful result proves only that data completed through that listener. It does not prove that SOCKMAP redirection occurred. Save the complete output and correlate the accelerated run with map and implementation counters.
For a connection-heavy variant, use the application-specific generator's option for new connections per operation. Avoid inventing a generic command because protocol correctness, payload framing, and expected responses differ between applications.
What attachment and counter evidence should show
Before the accelerated run, capture the program and map inventory. During traffic, the selected implementation should show the expected map entries and increasing redirect or verdict counters if it exposes them. After connections close, entries should be removed according to its documented lifecycle. After cleanup, temporary programs, attachments, or pinned maps should no longer affect the test path.
Expected verification is behavioral rather than a universal text string:
- The intended program identity is visible through the implementation's inspection method.
- The expected sockets appear under the documented map keys.
- Redirect counters increase only while the accelerated workload runs.
- Drop, error, and miss counters remain within the predefined acceptance criteria.
- Application responses match the direct and proxy variants.
- Socket entries disappear when the implementation says they should.
If attachment, socket membership, traffic direction, and redirect counters cannot be demonstrated, label the run inconclusive. Working traffic may have used a normal TCP route or an implementation fallback.
Measure performance, correctness, and operational cost
| Metric | Why it matters | Interpretation rule |
|---|---|---|
| Median latency | Describes a typical completed operation | Use it with tails and raw trial distributions |
| High-percentile latency | Reveals queueing, scheduling stalls, and outliers | Compare repeated trials, not one favorable run |
| Throughput | Shows completed useful work per unit of time | Verify that the generator is not saturated |
| User and system CPU | Tests whether forwarding work moved or decreased | Measure relevant processes and host-wide effects consistently |
| Context switches | Characterizes scheduling and user-space forwarding activity | Treat a change as supporting evidence, not proof of redirection |
| Errors and resets | Prevents trading correctness for speed | Investigate every unexpected failure or response mismatch |
| Redirect and miss counters | Shows whether the intended path handled traffic | Correlate deltas with completed operations |
| Fallback behavior | Establishes operational safety when acceleration is unavailable | Record whether traffic follows policy, fails closed, or resets |
Run multiple trials and retain each raw result. Alternate or randomize variant order so that thermal state, caches, and background activity do not consistently favor one path. Define warm-up before collecting data. Do not discard unfavorable runs unless a documented invalidation condition occurred.
Keep instrumentation symmetric. Heavy tracing on the accelerated path and minimal observation on the baseline can distort the comparison. Record tool versions, collection intervals, and whether counters are per process, per CPU, per cgroup, or system-wide.
Connection reuse matters. SK_MSG operates on the message path for participating sockets, while connection-heavy workloads include setup and teardown costs. Report persistent and short-lived connection results separately. Payload size also matters because small exchanges emphasize fixed overhead while large streams can become limited by flow control, memory movement, application reads and writes, or the generator.
Add Localtonet as the public ingress stage
Add public access only after all local variants are correct and repeatable. For this experiment, use a Localtonet TCP tunnel because the target is a raw TCP listener. Our standard lifecycle is to run the client on the device that can reach the service, select that device by its token, choose an available relay server, configure the local IP address and port, start the tunnel, verify the assigned public host and port, and stop or delete the tunnel when testing ends.
Consult the current Localtonet documentation while preparing the client and dashboard. Product labels, available relay choices, client installation packages, and plan-dependent options can change. The evidence available for this revision does not provide a verified Linux package command or every current dashboard label, so this article does not invent them.
Validate the target before creating public exposure
The Localtonet client must run on a device that can reach the configured target. From that device, confirm the listener and test the real protocol against the exact IP address and port you intend to enter:
ss -ltn
ss -tin
A listener bound only to 127.0.0.1 can be appropriate when the Localtonet client runs on the same host. If the client runs elsewhere, the target must be reachable from that device through the surrounding network architecture. Do not broaden the application's bind address without considering the security effect.
Install and run the current Localtonet client
Obtain the current Linux client through the official Localtonet workflow and run it on the device that can reach the selected benchmark listener. Follow the current installation instructions shown for that client rather than copying an unverified package command.
Authenticate or select the benchmark device
Use the device-specific authentication token through the supported product workflow. Never place the token in source control, benchmark output, screenshots, shell transcripts, or shared result archives.
Select an available relay server
Choose from the relay servers or regions currently offered in the dashboard. Record the choice privately with the run metadata. Do not hardcode an assumed server code into a reusable script or article.
Create the TCP tunnel configuration
Configure a TCP tunnel whose local IP address and port match the validated listener for the current variant. Keep the application and workload unchanged when switching among direct, proxy, and accelerated targets.
Start the tunnel
Creating a tunnel does not make it active. Use Start and confirm that the selected device remains connected and the tunnel is running. The endpoint is available only while those conditions remain true.
Verify the assigned public endpoint
From a remote machine on a different network, connect the protocol-aware test client to the assigned public host and port. Verify the expected response before starting a timed run, then correlate it with server logs and local socket state.
Run paired remote trials
Keep the remote generator location, relay choice, payload, concurrency, connection behavior, duration, and application constant. Run direct-target and forwarded-target trials close together in time.
Stop or delete the tunnel
Stop the tunnel when the benchmark window ends. Delete configurations that are no longer required, stop temporary listeners, and confirm that diagnostic services are no longer publicly reachable.
Two public comparisons are especially useful. First, target the application directly when doing so preserves required security controls. This supplies an end-to-end public reference without the evaluated forwarding hop. Second, target the conventional proxy or accelerated listener. The difference between repeated distributions shows whether the local forwarding layer remains visible in the complete public workflow.
The local test is more sensitive to small host-side differences. The remote Localtonet test shows whether those differences remain meaningful across the complete public path. A local improvement can be real even when internet variation makes it difficult to detect remotely.
Preserve application authentication and authorization, apply least privilege, and expose only the intended listener. Do not tunnel an administrative or unauthenticated service merely for convenience. SOCKMAP adds no authentication, and Localtonet must not be used to bypass organizational policy or required controls.
Interpret the results without overstating them
If the conventional proxy is materially slower locally and the verified accelerated path approaches the direct reference while preserving correctness, policy, and fallback behavior, the host forwarding layer is a credible optimization target. The conclusion still applies only to the tested kernel, implementation revision, workload, socket topology, and application.
If local latency improves but the remote distributions overlap, do not claim that Localtonet erased or caused the result. The public path simply contains additional components and variability. Check whether host CPU, throughput, or capacity improved even when remote latency did not.
If direct, proxy, and accelerated local results are similar, optimize elsewhere. Application logic, storage, dependencies, serialization, locking, connection management, or client saturation may dominate. Kernel complexity is difficult to justify when local forwarding is not a meaningful contributor.
If the accelerated route wins only after authentication, routing, validation, logging, or timeout controls are removed, the comparison is not equivalent. Restore required behavior and test again. A faster path is not acceptable if it changes the service's security or operational contract.
| Observed result | Defensible conclusion | What not to claim |
|---|---|---|
| Verified local latency and CPU improvement | The tested host forwarding path benefited under this workload | All Linux services or public tunnels will improve |
| Local gain, no remote latency separation | The host optimization was not distinguishable in end-to-end latency | The optimization failed or the tunnel is slow |
| No local difference | Forwarding was not a meaningful bottleneck in this test | SOCKMAP can never help another architecture |
| Higher throughput but more errors | The accelerated result failed correctness criteria | A production performance win |
| Traffic works without redirect evidence | The result is inconclusive | SOCKMAP caused the measured behavior |
Account for security and observability boundaries
A changed socket path can alter what existing monitoring tools observe. Packet capture on a physical interface is not a complete observation point for same-host socket redirection. Depending on the path, even loopback captures may not describe the accelerated message flow. Build visibility at the decision layer with map state, attachment state, redirect verdicts, misses, drops, control-plane events, socket lifecycle, and application-level completion.
Treat the loader and control plane as privileged components. Restrict who can replace eBPF objects, update maps, or alter attachment state. Preserve object hashes and configuration in the benchmark record, but do not publish credentials, private endpoints, or authentication tokens.
Namespace placement also matters. Containers can place processes and sockets in different network or process namespaces, while inspection from the host may expose a different view. Record where the backend, proxy, control plane, Localtonet client, and benchmark tools run.
| Risk | Failure mode | Required validation |
|---|---|---|
| Incorrect socket association | Messages reach the wrong connection or tenant | Use concurrent distinct payloads and verify end-to-end identity |
| Silent acceleration miss | Traffic works without using the intended path | Correlate map state and redirect counters with each run |
| Unsafe fallback | Failure bypasses policy or causes unexplained resets | Inject failures and verify explicit behavior |
| Reduced packet visibility | Packet-based monitoring misses redirected data | Add socket-layer and application telemetry |
| Stale map state | A closed or reused connection is associated incorrectly | Test close, restart, cleanup, and key-reuse behavior |
| Unnecessary public exposure | A diagnostic listener remains reachable | Stop the tunnel and remove temporary services after testing |
Troubleshoot incorrect or inconclusive results
The eBPF program will not load
Preserve the complete verifier output. Compare required map types, program types, helpers, and attachment mechanisms with the host's bpftool feature probe. Confirm that the object was built for the expected architecture and loader. Do not grant unrestricted privileges without identifying the blocked capability or security policy.
The program loads, but no sockets appear in the map
Review the implementation's socket-discovery and insertion conditions. Confirm that the control plane observes the correct process and namespace, the socket type and state are supported, and the documented event that triggers insertion actually occurred. Inspect control-plane errors rather than manually inserting arbitrary file descriptors into a production map.
Traffic works, but redirect counters do not change
Treat the run as unverified. Confirm the SK_MSG attachment, map membership, direction of traffic, destination-key lookup, and counter scope. The traffic may be using ordinary TCP or a fallback path. Do not report an accelerated result until independent evidence identifies the active path.
Only one direction works
Verify whether the chosen implementation supports and configures both directions. A request path and response path can require separate socket associations or redirect decisions. Check half-close and teardown behavior before continuing performance tests.
Local results vary between trials
Check CPU frequency changes, thermal throttling, background jobs, interrupt placement, competing containers, memory pressure, and inconsistent warm-up. Alternate variants rather than running every baseline first. Report the distribution across trials instead of selecting the best result.
Remote results are noisy
Keep the remote generator and selected Localtonet relay consistent, run paired trials close together, and collect enough observations to characterize variation without overwhelming the service. Compare local measurements from the same time window. Do not infer host forwarding cost from one remote round trip.
The local target works, but the public endpoint does not
Confirm that the selected Localtonet device is connected, the TCP tunnel has been started, and its configured IP address and port match the validated listener. Creating a tunnel is not the same as starting it. Verify that the application is still listening and that its own access controls accept the remote protocol.
Fallback causes resets or mixed responses
Stop performance testing and correct the architecture. Review how socket pairs are inserted, removed, replaced, and recovered. Test control-plane restart, stale entries, concurrent closes, key reuse, and application shutdown. A fast path that cannot preserve connection identity and policy is not ready for public ingress.
Frequently asked questions
Does this article prove that SOCKMAP speeds up Localtonet?
No. It defines a method for testing that question. SOCKMAP may reduce work in an eligible local TCP forwarding path, but no Localtonet latency or throughput improvement is established without verified measurements from the complete path.
Does SOCKMAP replace a Localtonet TCP tunnel?
No. Our TCP tunnel provides public reachability through an outbound Localtonet client connection and an assigned public host and port. SOCKMAP operates on eligible sockets within the Linux host. It does not provide a relay endpoint or internet reachability.
Can SK_MSG acceleration be applied to every TCP socket?
No. Support depends on socket eligibility, kernel capabilities, program attachment, map membership, traffic direction, and implementation design. Check the selected implementation against the running kernel and prove that the intended sockets and messages use the path.
Can this SOCKMAP method accelerate UDP?
This methodology concerns compatible TCP socket paths and must not be generalized to UDP. Localtonet has separate TCP, UDP, and combined UDP/TCP tunnel families, but a TCP SOCKMAP experiment establishes no UDP optimization result.
Why does the guide not provide one universal loader command?
Build, load, attach, map-population, inspection, and cleanup commands are implementation-specific. They depend on the source revision, loader, map layout, control plane, kernel, and namespaces. Use a reviewed implementation, pin its revision, and preserve its exact documented commands.
Does verifier acceptance prove the forwarding policy is correct?
No. The verifier checks program safety properties under its kernel model. It does not prove that socket pairing, tenant isolation, routing, cleanup, fallback, or application policy is logically correct.
Can SOCKMAP transparently replace a reverse proxy?
Not generally. Reverse proxies can provide authentication, application-aware routing, validation, logging, timeouts, rate controls, health management, and connection policy. Socket redirection does not automatically reproduce those features.
How do I prove that the accelerated path handled traffic?
Verify the expected program attachment, map membership, socket pairing, traffic direction, and redirect-counter changes. Correlate those signals with correct application responses. Successful traffic by itself is not proof because a conventional or fallback path may also work.
Should the Localtonet tunnel target the application or the proxy?
Test both when the security architecture permits it. The direct application target is an end-to-end reference without the evaluated proxy hop. The proxy or accelerated listener represents the intended deployment path. Never expose the application directly if that removes required authentication or policy controls.
Measure the complete Linux ingress path with Localtonet
Establish direct, conventional proxy, and verified SOCKMAP baselines locally. Then use a Localtonet TCP tunnel to test the same service from an external network without configuring inbound router port forwarding. Keep the public tunnel active only for the benchmark window and preserve every application-level security control.
Get Started Free →
