Jump to content


VIP Member
  • Content Count

  • Joined

  • Last visited

  • Days Won

  • Feedback


Elfocrash last won the day on May 1

Elfocrash had the most liked content!

Community Reputation

195 Excellent

About Elfocrash

  • Rank

Profile Information

  • Current Mood
  • Gender
  • Country
    United Kingdom

Recent Profile Visitors

6,318 profile views
  1. Hahahha I just noticed it's you, sorry
  2. As I mentioned in my first post, the Autoproxy solution is currently in production and has been for about 2 weeks without any issues for a server that was constantly attacked. Well it does though. It's not a cheap way to protect against it though. You can get very expensive ddos protected VPSes and host the proxies there. The proxy has such a small footprint that you don't need a beefy VPS to host it. This can't happen because the proxies only pass traffic through to the server if a player with this IP is connected to it. Since the ddos attacks come from another IP the proxy won't allow them through to the gameserver. The orchestrator keeps note of who is where and will only allow connected players traffic in. Again I'm not saying this is a one size fits all solution for anything, and I'm not here to sell or advertise anything. The thing that I find interesting and I wanted to share is the ability to transfer players from one connection to another without disconnecting them. I have absolutely 0 interest in explaining networking concepts and this will never be used by anyone else other than me and the server who wanted me to implement this for them in the first place.
  3. It would be easier to repurpose the friend chat window to use the discord APIs, but then you would have to trust the server owner to not do anything weird with your credentials and implement OAuth for Discord properly, which let's be honest, it's not gonna happen.
  4. You sound like you have no idea what you're talking about. IpTables can filter a lot of the bad traffic but nowadays it's hugely ineffective against sophisticated gameserver attacks, and so are ddos mitigation solutions. Asynchronous mmocore has absolutely nothing to do with anything we are talking about so I don't know what you even bring it up. It's completely offtopic. No because those solutions are general solutions for mainly webservers. Even though they can do basic TCP, I'd rather have my own code in there because I don't need any of the existing bloat of an existing solution and I want a lot of specialized code to deal with proxy transfers and L2 Specific data in the proxy. Also Nginx is kinda bad compared to something like Traefik, which is what I would use if I wanted an existing solution. It also does WAY too much, and my solution has such a small footprint compared to any other generic solution, just because it only does the bare minimum that I want it to do. On top of that, if you can read an architectural diagram, the load balancer and the reverse proxies are two separate solutions. PS: I also like the fact that you just googled "Reverse proxy" and because Nginx was the first thing that shows up you brought it up. You missed the part that said that Nginx is also a loadbalancer, mail proxy and http cache. :D PS2: This solution (without the ingame proxy change, just the reverse proxies and orchestration) is in production currently for one of the biggest interlude servers. The owner might not want me to spoil the name so I won't go out of my way to reveal that.
  5. Again, stop thinking forward proxies like Nik. This is a reverse proxy with load balancing orchestration. The gameserver is untouched. It is still a gameserver. No tunnelling, no iptables, no hardware protection or any shit like that. IP tables are just firewall rules. This doesn't act like that. It's a completely different thing doing a completely different job. The proxy services are just middlemen that abstract your gameserver. Will go down before any malicious traffic gets to the gameserver from them, and the orchestrator will decommission them until the attack stops. They are designed to do that. The machine they run on won't go down, but the service itself will. You both totally miss the point and don't understand the solution. This is not the place for me to explain such networking concepts and solutions. You can google that.
  6. Like I said before, you get disconnected and reconnected to another IP but you never get the message of the disconnection if you follow a specific packet sequence to establish the new connection. The client just won't throw it. That loading screen you see in the video if part of this sequence. TCP is followed to at T since you DO get disconnected and reconnected but you never see that. I'm not "altering" anything. I close one and open a new one. I can't say any more without spoiling the solution.
  7. I mean, I can take another video showing the ip change with netstat. Could also setup the server and you can do the netstat yourself but I won't buy two VPSes for that :D The fact that you can't think of another way this can work, doesn't make it impossible :P In fact, if I set up the server and you used some packet sniffer you would understand exactly how it works so I think I'll pass on the live test thing and let you wondering :D
  8. Well that’s the part I can’t share yet until I decide what to do with this but yeah that’s how it works.
  9. I wasn't aware of this package. Yeah this package would actually make it way easier for higher chronicles. I am not doing it via this way, but I will implement that on H5 and see the results. It's 100% consistent, you just have to nail the packet sequence. I wish Interlude had the RaidServer packet. It would same me a lot of investigation time.
  10. I do not utilized any RaidServer logic (I don't even know what that is really). L2 client will terminate itself when the connection is dropped but it will only show the "Disconnect" popup only on specific stages. If you disconnect and reconnect in the right time, you can cheat it. That's how it works. I don't know what Raidserver is and I think I didn't accidentally use that (?) The client is untouched.
  11. 1) No the player doesn't go through a universal gateway. The Loginserver takes care of that. Ofc that means that if they take down the loginserver people can't log in, which is a problem with any implementation anyway. The loginserver does all the communication with the load balancer and it uses that logic to display the appropriate proxy list. The player will connect straight to the proxy service. No gateway involved. 2) Let me put it this way. The players never gets a disconnection message and doesn't have to do any manual relogin, but he will indeed get disconnected and reconnected to a new proxy. It is all done for him without him knowing or noticing a disconnection, through a very specific sequence of events. 3) I thought that I would initially need client side extension but it turns out the your can cheat the client if you play your packets right. (tested it in h5 as well and this behavior is the same)
  12. Ha here is the magic. The connection is being re established but the client doesn’t show that you’re getting disconnected and reconnected. That’s why I needed the restart loading screen. Because it allows me to do the reconnection gracefully behind the scenes. Edit: diagram added
  13. It’s not trying to do something. It’s doing it, way better than a forward proxy mind you. Also your statements about high and low lever as as stupid as this one: “Why don’t you code in assembly then?” I also find it super funny that you need someone else to tag team in order to argue your point. It's really how we become better as developers. Anyways keep playing with your archaic solution. I won't respond to neither you nor your mate when he is here to save you from your own ignorance. GN :D