# How to Switch Between Different Transport Backends in OpenFlux: A Command-Line Guide

> Easily switch OpenFlux transport backends like Yandex Docs, Volga, or MAX using the command line. Learn how with our simple guide.

- Repository: [p1neappleXpress/OpenFlux](https://github.com/p1neappleXpress/OpenFlux)
- Tags: how-to-guide
- Published: 2026-09-13

---

**Use the `-transport` flag followed by `yandex`, `vyandex`, or `oneme` to switch between Yandex Docs, Yandex Volga, or MAX (OneMe) network backends without modifying any source code.**

OpenFlux is a flexible networking tool that abstracts its network layer behind a common interface, allowing users to switch between different transport backends at runtime. The repository `p1neappleXpress/OpenFlux` implements this abstraction in Go, enabling seamless transitions between WebSocket-based document access and peer-to-peer tunneling through simple command-line arguments.

## Understanding the Transport Interface Architecture

OpenFlux decouples the networking logic from the core application through the `transport.Transport` interface defined in [`transport/transport.go`](https://github.com/p1neappleXpress/OpenFlux/blob/main/transport/transport.go). This interface standardizes the lifecycle and data flow across all backend implementations.

Every concrete transport implements six essential methods: `Start`, `Stop`, `Send`, `Receive`, `IsConnected`, and `Stats`. The `BaseTransport` struct provides shared functionality that specific backends extend. This design means that switching between transport backends requires no code changes—only a different command-line flag value.

## Available Transport Backends in OpenFlux

The `p1neappleXpress/OpenFlux` repository ships with three distinct transport implementations, each optimized for specific network scenarios:

### Yandex Docs (`yandex`)

The default WebSocket-based transport located in [`transport/yandex/yandex.go`](https://github.com/p1neappleXpress/OpenFlux/blob/main/transport/yandex/yandex.go). This backend connects to Yandex Docs for fast, public-document access and serves as the primary transport for standard client operations.

### Yandex Volga (`vyandex`)

An alternative Yandex Docs client implemented in [`transport/yandex/vyandex.go`](https://github.com/p1neappleXpress/OpenFlux/blob/main/transport/yandex/vyandex.go). This backend provides compatibility with newer Yandex APIs and uses `yandex.NewYandexVolgaTransport` for instantiation.

### MAX/OneMe Network (`oneme`)

A peer-to-peer tunnel for MAX services implemented in [`transport/oneme/max_transport.go`](https://github.com/p1neappleXpress/OpenFlux/blob/main/transport/oneme/max_transport.go). This transport creates direct connections between nodes and requires additional authentication parameters via `oneme.NewOneMeTransport`.

## How to Switch Transport Backends at Runtime

Backend selection occurs in [`main.go`](https://github.com/p1neappleXpress/OpenFlux/blob/main/main.go) within a `switch` block (lines 71-81) that parses the `-transport` command-line flag. The application instantiates the appropriate concrete type based on the string value provided:

```go
switch *transportType {
case "vyandex":
    inner = yandex.NewYandexVolgaTransport(globalDocUrl, config)
case "yandex":
    inner = yandex.NewYandexDocsTransport(globalDocUrl, config)
case "oneme":
    uidint, _ := strconv.ParseInt(maxUid, 10, 64)
    inner = oneme.NewOneMeTransport(*exitNode, maxToken, uidint, config)
default:
    log.Fatalf("Unknown transport type: %s", *transportType)
}

```

If the flag specifies an unregistered transport type, OpenFlux terminates with a fatal error logging the unknown type. All valid transports share identical initialization patterns, ensuring consistent behavior regardless of which backend is active.

## Practical Examples for Each Backend

Switching between transport backends requires only changing the `-transport` argument. Below are the specific command patterns for each supported backend.

**Run with Yandex Docs transport (default):**

```bash
./OpenFlux -transport yandex -url "https://docs.yandex.ru/doc/example" -socks5 :1080 -client

```

**Run with the alternative Yandex Volga transport:**

```bash
./OpenFlux -transport vyandex -url "https://doc.yandex.ru/volga/example" -socks5 :1080 -client

```

**Run as a MAX (OneMe) exit node:**

```bash
./OpenFlux -transport oneme -maxToken "<MAX_TOKEN>" -maxUid "123456" -exit-node -socks5 :1080

```

Note that the `oneme` transport requires the `-maxToken` and `-maxUid` flags for authentication, plus the `-exit-node` flag when operating as a server node.

## Optional Encryption and Compression Wrappers

OpenFlux applies transport-agnostic wrappers after backend instantiation. The system optionally wraps any selected transport with **AES-256-GCM encryption** via `transport.NewEncryptedTransport` and **compression** via `transport.NewCompressedTransport`.

These wrappers remain transparent to the underlying transport implementation. Therefore, switching from `yandex` to `oneme` while maintaining encryption requires no additional code changes—simply combine the flags:

```bash
./OpenFlux -transport yandex -url "https://docs.yandex.ru/doc/example" \
  -encryption-key-file ./secret.key -socks5 :1080 -client

```

The encryption layer in [`transport/encrypted.go`](https://github.com/p1neappleXpress/OpenFlux/blob/main/transport/encrypted.go) and the compression layer in [`transport/compressor.go`](https://github.com/p1neappleXpress/OpenFlux/blob/main/transport/compressor.go) handle data transformation uniformly across all backend types.

## Summary

- **Interface abstraction**: All transports implement the `Transport` interface in [`transport/transport.go`](https://github.com/p1neappleXpress/OpenFlux/blob/main/transport/transport.go), enabling polymorphic backend switching.
- **Flag-based selection**: Use `-transport` with values `yandex`, `vyandex`, or `oneme` to select implementations in [`main.go`](https://github.com/p1neappleXpress/OpenFlux/blob/main/main.go).
- **Zero code changes**: Switching backends requires only command-line modifications; no recompilation is necessary.
- **Consistent wrapping**: Optional encryption ([`transport/encrypted.go`](https://github.com/p1neappleXpress/OpenFlux/blob/main/transport/encrypted.go)) and compression ([`transport/compressor.go`](https://github.com/p1neappleXpress/OpenFlux/blob/main/transport/compressor.go)) work uniformly across all transport types.
- **Authentication differences**: The `oneme` backend requires `-maxToken` and `-maxUid`, while Yandex variants require `-url`.

## Frequently Asked Questions

### What happens if I specify an invalid transport type?

OpenFlux validates the `-transport` flag against registered implementations in [`main.go`](https://github.com/p1neappleXpress/OpenFlux/blob/main/main.go). If you provide an unrecognized value, the application calls `log.Fatalf` with the message `"Unknown transport type: %s"` and exits immediately without establishing any network connections.

### Can I use encryption with any transport backend?

Yes. The `transport.NewEncryptedTransport` wrapper in [`transport/encrypted.go`](https://github.com/p1neappleXpress/OpenFlux/blob/main/transport/encrypted.go) accepts any type satisfying the `Transport` interface. Whether you select `yandex`, `vyandex`, or `oneme`, you can layer AES-256-GCM encryption by specifying `-encryption-key-file` without modifying the underlying transport logic.

### Do I need to recompile OpenFlux to change transports?

No. The architecture uses runtime polymorphism through the `Transport` interface. Simply restart the binary with a different `-transport` flag value. Recompilation is only necessary if you are adding a new transport implementation that does not exist in `p1neappleXpress/OpenFlux`.

### Which transport should I use for peer-to-peer connections?

Use the `oneme` transport implemented in [`transport/oneme/max_transport.go`](https://github.com/p1neappleXpress/OpenFlux/blob/main/transport/oneme/max_transport.go). Unlike the Yandex variants that connect to document servers, the OneMe transport creates direct peer-to-peer tunnels within the MAX network, making it suitable for decentralized communication scenarios.