loopholelabs

XDP (eXpress Data Path) is the fastest packet processing framework in linux - but it only works for incoming (ingress) traffic. We discovered how to use it for outgoing (egress) traffic by exploiting a loophole in how the linux kernel determines packet direction. Our technique delivers 10x better performance than current solutions, works with existing Docker/Kubernetes containers, and requires zero kernel modifications.

This post not only expands on the overall implementation but also outlines how existing container and VM workloads can immediately take advantage with minimal effort and zero infrastructure changes.

I think time-slicing for GPUs is likely the solution here.

If you could checkpoint a GPU quickly enough it would be possible to run multiple isolated workloads on the same GPUs without any issues.

Hey everyone,

Founder of Loophole Labs here!

The team and I are happy to answer any questions you might have about fRPC, Frisbee, or Loophole in general!

We wrote fRPC because we really liked the DevX and tooling around the proto3 syntax, but we needed the generated code to be significantly more performant than what gRPC provides.

We also needed the ability to extend the RPC framework with other messaging patterns (like pub/sub) and we needed to be able to reuse the underlying TCP connections as required.

Today, fRPC can outperform gRPC by more than 4x, doing more than 2 million RPCs/second on a single node.

You can check out our docs site at https://frpc.io, or check out the repo at https://github.com/loopholelabs/frpc-go

Hi!

Author of this library here, I'm happy to answer any questions about this.

We'll be releasing an update soon that will enable both custom domains (so you can bring your own) and reservable subdomains. Furthermore we plan on releasing a self-hosted version and open-sourcing the client.

I've written up an in-depth analysis here: https://medium.com/@shivanshvij/building-a-better-ngrok-dbc1...

That makes a lot of sense, thanks for pointing this out! I assumed that asking people to verify their emails would be enough but it never hurts to make things clear.

I'll make those changes as soon as possible.

HTTP will compress traffic from the lynk endpoint but we also compress the traffic from the client to that endpoint which helps save bandwidth and keeps things snappy even in slow network conditions

Would you be able to discuss this bug with us? We're in Beta right now and are looking to document and squash as many bugs as possible.

Please email us at [email protected]

Yes, it was and this has since been removed.

Hi!

I've written an analysis of Lynk's performance vs. Ngrok here: https://medium.com/@shivanshvij/building-a-better-ngrok-dbc1... and our documentation stating "SHA-256 Encryption" has been since removed as a mistake.

The client side will absolutely be open sourced probably by the end of next week once I've cleaned up some spaghetti code.

This was a mistake on our website, which as since been removed.

1. We'll be open sourcing our client in the coming weeks so you can check out our code yourselves.

2. We will be offering a self-hosted version which will decouple you entirely from our infrastructure and you can provide you own SSL certificates.

3. Lynk can forward traffic to your encrypted services - which of course would mean losing out on compression benefits, but Lynk is designed primarily for quick development work like testing out a Stripe or Github webhook on your local machine, or demoing your webapp to a remote client. For production use we recommend a reverse proxy or self-hosting Lynk.

I should have been more clear.

The client compresses responses from your local services before they're encrypted and sent to the Lynk infrastructure. This application is designed primarily for development work and takes the hassle out of setting up a reverse proxy or dealing with port-forwarding.

If your local application provides its own encryption (ie, it's running over HTTPS), then your traffic won't be exposed to Lynk. In this scenario, you're right - there would be very little compression gain.

That's in the works as well, we're just looking into how we can properly tie these tunnels to your Lynk account

We'll be releasing a self-hosted server and client soon that will allow you to decouple completely from our infrastructure and bring your own SSL certificates.

However, to be clear, this is intended primarily for local development use, for traffic that isn't necessarily sensitive.

Yes, we are doing E2E encryption and compression between the Lynk Infrastructure and Lynk Clients. As with Ngrok, for a quick hosted tunnel our encryption will be more than suitable, and we are working to release a self-hosted version soon that will allow you to bring your own certificates (for both ingress traffic and the traffic between the Lynk Client and the Lynk Infrastructure).

Hi Hackernews,

We're excited to announce that the Lynk Beta is now live!

We've been hard at work building out Lynk's tunnelling protocols to make them faster, more stable, and all around better. We're happy to announce that vs. Ngrok our tunnels perform up to 6 times faster (source: https://medium.com/@shivanshvij/building-a-better-ngrok-dbc1...) and support technologies such as HTTP/2 (with HTTP1 fallback) and Websockets.

Check out our open beta and documentation here: https://lynk.sh

We completely agree, and a big focus for us has been improving the UX compared to Ngrok.

Our docs are being overhauled this week and will include examples on hosting common apps, troubleshooting common issues, and using the various features in lynk like HTTP authentication.

You can check them out here at https://lynk.sh