TCP Tunnelled Endpoints

[XAMPPRocky]

When trying to use Quilkin with real world applications, it's come up surprisingly frequently that I also need to proxy TCP traffic in addition to UDP. for example the iperf3 use TCP to do some initial synchronisation between the server and client. I've also run into games that are sending mixed traffic to the same server, such as using TCP for content delivery, and UDP for gameplay/physics.

To make using Quilkin out of the box with these applications I think it would good to add some sort of basic TCP tunnelling functionality, that forwards TCP traffic to an endpoint, obviously the focus of the project is on UDP, so this wouldn't have any filter functionality or anything beyond forwarding traffic. For configuration I was initially thinking of having it just be a boolean on the endpoints that you can enable.

version: v1alpha1
proxy: 
    id: my-proxy
    port: 7001
static:
    endpoints: 
        - address: 127.0.0.1:26000
          tcp_tunnel: true

[markmandel]

🤔 Interesting idea. Just thinking through this from a use case point of view...

Sidecar

Having a tcp tunnel does makes life easier, as you don't need to do like iperf3 and use socat - that being said, you can always socat things, and it works just fine, without us having to take on the maintenance burden.

Array of Proxy instances, load balanced

This doesn't help here 😭 because you can no longer rely on the persistent connection. Might be better to find an alternate route? TCP LB maybe?

@luna-duclos I'm sure you have some interesting thoughts here?

[XAMPPRocky]

Having a tcp tunnel does makes life easier, as you don't need to do like iperf3 and use socat - that being said, you can always socat things, and it works just fine, without us having to take on the maintenance burden.

To clarify, I would be happy with a solution where quilkin spawns a socat thread/process with the configuration, and lets it handle all the actual tunnelling. I think the benefit here is not having to manually spawn and manage a separate process yourself, and having just one configuration.

Array of Proxy instances, load balanced

This doesn't help here 😭 because you can no longer rely on the persistent connection. Might be better to find an alternate route? TCP LB maybe?

Hmm to simplify, I think it would be fine if this feature isn't suitable or incompatible if you're managing a group of Quilkin (a herd? A quill of Quilkin?). Because you can probably also route the TCP traffic using the same thing you're using to manage the group, or at least more easily spawn your own socat instances. Where as I think this is primarily for when you want to use Quilkin as just a single instance opaque proxy which is more useful while in development, or dropping it into existing networks.

[markmandel]

Meta note: A group of hedgehogs is called an "array" or a "prickle" - but an array of Quilkins seems somehow appropriate to me 😄 But I would also happily accept a prickle as well.

(I actually didn't mean to reference it as an array in my previous comment on purpose!)

[iffyio]

Meta note: A group of hedgehogs is called an "array" or a "prickle" - but an array of Quilkins seems somehow appropriate to me smile But I would also happily accept a prickle as well.

an array sounds extremely convenient in this case :laughing:

I haven't used iperf3 yet so I don't think I get the full issue, it sounds like its mostly a boilerplate problem during development atm? (and can we always script around it?). Thinking if we would introduce something like this, I'd rather its based some user's setup where they really need it so that we can come up with a more general solution if possible - the current proposal sounds to me like it might not fit as well in production or at least in limited/rare deployments?

[XAMPPRocky]

but an array of Quilkins

[🦔, 🦔, 🦔, 🦔]

the current proposal sounds to me like it might not fit as well in production or at least in limited/rare deployments?

Well I think that depends on perspective. While for us this will be mostly useful for development and testing, there are still broader use-cases where you're not ever going to want to have multiple Quilkins.

For example if you're writing a peer-to-peer game and you wanted to use Quilkin infront of your game client servers so that you can get compression and logging for free. You're not going to benefit from multiple proxies, you just want to use it as layer between your game and the outside world.