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.

Nvidia vGPUs are time-sliced; MIG isn't. Neither work in arbitrary hypervised VMs.

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.

Yeah, I was extremely confused at not finding a way to sign up with just email, and was about to leave when I saw this comment.

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.

It might be a good idea to make that post or something like it way more prominent.

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.

the certificate at https://loopholelabs.io/ has been invalid for almost a month

You allow the user's machine to obtain a valid certificate for a subdomain of lynk.sh? (This would seem to me the only way to accomplish E2EE, given the example of connecting over TLS to a lynk.sh host, and it also seems very unlikely.)

why does that seem unlikely?

Thank you, this is helpful.

You could use this "for dev" and "for prod" as a marketing/business opportunity. Distinct bullets points of use cases in "For Dev" and "For Prod" sections. For prod there are also add-on options that would not make sense for dev, and could provide additional value (custom support, pre-built packages for distros, analytics on traffic/usage analytics about the tunneled services, etc)

Good Luck

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.