Interesting project - i do a lot of enterprise reverse proxy work and even just configuring them can be extremely complex at scale. So many crazy edge cases, and complex requirements especially around persistence, monitoring, ssl, rewriting etc
^^ it's always fun how simple, efficent and beautiful such code is, as long as you only care about good actors. Once you have to take care about bad actors, especially nasty once, it gets so ugly and convoluted.
Obviously if you're just using one matchmaking server it creates a single point of failure for all game servers in the event of a DDoS. But if that was really a concern you would use or create a sophisticated edge network that tries to prevent that. But then you're basically reinventing cloudflare (a way more complicated thing) to defend your game servers.
You should check out the Star Citizen Server meshing Tech. I think their approach is really cool, but probably Has to be deeply integrated in the game engine. So probably not manageable in reasonable time
Prime you are coding very Tiger style. I’m down with putting asserts throughout my code, but writing a simulator seems like a bit much to just pick up. How long did it take you to really get in to/master tiger style?
Your reverse proxy you made make me think of NAT + Firewall with the fact you need to filter than translate the ip than respond to the sockets. Or maybe NAT were always reverse proxy ?
You wrote a goodun... I'm working on something similar but in c++... with strongly typed (thingy) such that the compiler's proof checker is account for non business logic tests... I've semi rustified my code ... type safety not pretend memory safety (we're not animals here if you can point to it you can own it as far as I'm concerned).
It does handle errors, just not how we're used to errors being handled. Errors as values, which is the paradigm go falls into, is often more robust than try/catch because you know what can and cannot error based on the return type. It's still up to you to do stuff with those errors, but the compiler makes sure you've at least thought about it. Compared to JavaScript where half the functions in the browser can throw, and half the functions in Node can throw, but you don't know until you crash what can error, go error handling is extremely robust. (I'm not trying to be precise. I know it's not half, but I don't know if it's more than half or less than half of JS that can throw.)
@@yramagicman675 compiler makes sure you've at least thought about it. wait until "if err != nil{ return err }" becomes muscle memory and now you not thinking about errors again. Now the only benefit that it's easier to spot where your system can fail. But I prefer the Nim's way of doing it. In Nim you have exceptions + effect system: you can annotate critical parts of your system with `raises: []` pragma and now you are required to handle all exceptions that could be thrown or it won't compile. It gives agency to the developer, while offloading most work to compiler and also not polluting your code with meaningless noise.
@@dolorsitametblue that's a great way to do it. I'm sure veteran go devs have a hot key in their editor so 1 or 2 keystrokes expand to the if err == nil block. That's what I would do if I worked with go every day
@@yramagicman675It's my first time hearing about Go error handling so forgive my ignorance. Then go error handling is just java error handling but with return values instead of exceptions is it?
@@acommoncommenter9364 I've spent probably 6 hours working in Java in the worst possible code. I can't verify this theory. Maybe someone else can corroborate you theory.
noice! bravo articulating before you lose your ma'bles! i have a question... how long can a 'connection' persist? i have kinda similar solution with reservation for 3000 individual conns. its' footprint is tiny(RAM and CPU) with multiple auth layers. notably one 'app' runtime has lasted 2,888 days, others 400+ etc. each app is written in about 80% python and 20% native(OS). for your consideration; my solution also employs certs, and i have found when they update(periodically as they do, for me 90 days i think) i lose context i maybe in a position to address this 'issue' at some point being busy the now, i am thinking of re-contextualizing certs in the app(maintaining uptime) or more simpler just restart(which may bruise my uptime ego)
Up time should be measured in time between you needing to take action, not how long the program itself has been running. If your app goes down for half a second and restarts straight back up with no intervention, is it really down?
No, the middleman still acts like the client against the server. In other words, server isn't aware the connection is with a middleman, it acts as if its the client. That makes it a reverse proxy. But it sounds weird calling it that because reverse proxies are just mostly used as institutional packet interceptors.
I don't get it. From what I've learned a reverse proxy is just a proxy but for the servers, and it usually exists to distribute loads in a sophisticated way and cache data and prevent attacks. So supposedly if you know how to write a proxy you know exactly how to write a reverse proxy as well. Not to be confused with a software "proxy" equivalents that just balance a single server, maybe spin up some worker threads.
Yes and no. The forward proxy usually only maps one respond to one requests.I A reverse proxy can become a more complex assembler, when you do scheduling tasks to achieve load balancing, or you litterally need to assemble the final response from multiple sources. But simpler is usually better.
Every programmer's last words: "It's not far from being done"
it's prety much done locally, just have to push an MR real quick, don't worry about it
tombstone reads: "he was so close"
First 90% is usually way easier than the last 90%
It is never done, but we are
So close, yet so far away
Interesting project - i do a lot of enterprise reverse proxy work and even just configuring them can be extremely complex at scale. So many crazy edge cases, and complex requirements especially around persistence, monitoring, ssl, rewriting etc
The recap!!! This is awesome. Do more stream/project recaps please.
^^ it's always fun how simple, efficent and beautiful such code is, as long as you only care about good actors. Once you have to take care about bad actors, especially nasty once, it gets so ugly and convoluted.
TCP Tinder
ratio there would be lucky to reach 1:9
Just started following. You are so entertaining; I appreciate your excitement.
Good job man. Keep it up and I hope you will have fun while doing it.
4:41 Structured Logging shown, let's go!
Obviously if you're just using one matchmaking server it creates a single point of failure for all game servers in the event of a DDoS. But if that was really a concern you would use or create a sophisticated edge network that tries to prevent that. But then you're basically reinventing cloudflare (a way more complicated thing) to defend your game servers.
That's the fun part!!
@@ThePrimeTimeagenplease re-create cloudflare without the trust and safety team 😂
It's cool seeing you geek out on your project, keep it up.
my man, sip some herbal tea with honey
More of this! So great! I love how you explain things.
The title makes me think of Betteridge's law of headlines
You should check out the Star Citizen Server meshing Tech. I think their approach is really cool, but probably Has to be deeply integrated in the game engine. So probably not manageable in reasonable time
And that it basically just the P2P meshing tech used in Destiny over 10 years ago.
Prime you are coding very Tiger style. I’m down with putting asserts throughout my code, but writing a simulator seems like a bit much to just pick up. How long did it take you to really get in to/master tiger style?
Super Entertaining project loves the comentary
Your reverse proxy you made make me think of NAT + Firewall with the fact you need to filter than translate the ip than respond to the sockets.
Or maybe NAT were always reverse proxy ?
The amount of nerd talk in this video is amazing. I want to create such a thing myself too 😢
Awesome video! Please make more of these quick overviews that show some actual code
eBPF stuff would be really cool to watch, I've never used it myself though
Simulating client behavior is great. Will you also simulate sever processes dying and/or misbehaving?
Like how SQLite has a really in-depth testing suite that tests for various hardware failures too
Now I'm worried about authentication 😬
Pretty boxes my friend. Very well presented
“Lowest level” 👷♂️ we can go lower
Loved this!
whats the text font in your neovim called
I want to know too. Is that JetBrains Mono?
i have not keeping up with prime's videos recently, did he mentioned why he opted to develop this with go instead of his beloved rust?
He's been off the rust train for almost a year at this point, it's the year of learning go instead
This is amazing content.
dang, u are looking good!
... will this able to handle reconnecting players that disconnected mid game?
You wrote a goodun... I'm working on something similar but in c++... with strongly typed (thingy) such that the compiler's proof checker is account for non business logic tests... I've semi rustified my code ... type safety not pretend memory safety (we're not animals here if you can point to it you can own it as far as I'm concerned).
Did i just make the reverse proxy of the summer?
Please more recaps :)
So is a matchmaking server essentially a reverse proxy with additional logic?
your throat is killing me
I don’t know, did you?
Next step, direct server return ?
Loves go error handling. Doesn't handle errors
It does handle errors, just not how we're used to errors being handled. Errors as values, which is the paradigm go falls into, is often more robust than try/catch because you know what can and cannot error based on the return type. It's still up to you to do stuff with those errors, but the compiler makes sure you've at least thought about it. Compared to JavaScript where half the functions in the browser can throw, and half the functions in Node can throw, but you don't know until you crash what can error, go error handling is extremely robust. (I'm not trying to be precise. I know it's not half, but I don't know if it's more than half or less than half of JS that can throw.)
@@yramagicman675 compiler makes sure you've at least thought about it.
wait until "if err != nil{ return err }" becomes muscle memory and now you not thinking about errors again. Now the only benefit that it's easier to spot where your system can fail.
But I prefer the Nim's way of doing it. In Nim you have exceptions + effect system: you can annotate critical parts of your system with `raises: []` pragma and now you are required to handle all exceptions that could be thrown or it won't compile.
It gives agency to the developer, while offloading most work to compiler and also not polluting your code with meaningless noise.
@@dolorsitametblue that's a great way to do it. I'm sure veteran go devs have a hot key in their editor so 1 or 2 keystrokes expand to the if err == nil block. That's what I would do if I worked with go every day
@@yramagicman675It's my first time hearing about Go error handling so forgive my ignorance. Then go error handling is just java error handling but with return values instead of exceptions is it?
@@acommoncommenter9364 I've spent probably 6 hours working in Java in the worst possible code. I can't verify this theory. Maybe someone else can corroborate you theory.
noice! bravo articulating before you lose your ma'bles!
i have a question... how long can a 'connection' persist?
i have kinda similar solution with reservation for 3000 individual conns. its' footprint is tiny(RAM and CPU) with multiple auth layers.
notably one 'app' runtime has lasted 2,888 days, others 400+ etc. each app is written in about 80% python and 20% native(OS).
for your consideration; my solution also employs certs, and i have found when they update(periodically as they do, for me 90 days i think) i lose context
i maybe in a position to address this 'issue' at some point being busy the now, i am thinking of re-contextualizing certs in the app(maintaining uptime) or more simpler just restart(which may bruise my uptime ego)
Up time should be measured in time between you needing to take action, not how long the program itself has been running.
If your app goes down for half a second and restarts straight back up with no intervention, is it really down?
@@mattymerr701 exactly, its been years, literally years since i had to take action on these deployments.
thanks for the source code
So reverse proxy is a multiplexer?
I liked it with my 10 google accounts
What programming language is he using?
Go
bump
this is not reverse proxy this an Orchestrator
No, the middleman still acts like the client against the server. In other words, server isn't aware the connection is with a middleman, it acts as if its the client. That makes it a reverse proxy. But it sounds weird calling it that because reverse proxies are just mostly used as institutional packet interceptors.
Why be a persistent man in the middle? Once everything is good to go why not just tell the client how to talk to the server directly?
Where is SSL?
Nginx streams 0.1 🎉
i like this
🔥
Spoiler: no
if err != nil if err != nil if err != nil if err != nil ... I now know Golang!!! :)
abraço do Brasil : )
I don't get it. From what I've learned a reverse proxy is just a proxy but for the servers, and it usually exists to distribute loads in a sophisticated way and cache data and prevent attacks. So supposedly if you know how to write a proxy you know exactly how to write a reverse proxy as well. Not to be confused with a software "proxy" equivalents that just balance a single server, maybe spin up some worker threads.
warded
Yeah, that's about right. Proxy is a proxy is a proxy. The reverse part just says where it lives / who owns it.
Yes and no. The forward proxy usually only maps one respond to one requests.I
A reverse proxy can become a more complex assembler, when you do scheduling tasks to achieve load balancing, or you litterally need to assemble the final response from multiple sources.
But simpler is usually better.
@@MrHaggyywhen you're making multiple requests based on the one from the client, that's just a small service not a proxy.
@@MrHaggyywhen you're making multiple requests based on the one from the client, that's just a small service not a proxy.
quickie😁
mid
still mid
lessgo
1 minute and just 39 views? bro really fell off.
🤣🤣🤣 Ikr?
Le zoomer comment
@@saymehname no shit sherlock
@@saymehname seriously imagine thinking saying that is funny
First 🎉