Cabal Online Gateway/Proxy

I remember when you guys used to talk about a proxy. So, I'm doing one and testing in Punky's server. Here are some screenshots: (I'm not hosting any CO service btw, so its not fake.)

random account test:
http://img815.imageshack.us/img815/4624/wrongu.png

my account test:
http://img528.imageshack.us/img528/4708/channels.png
http://img824.imageshack.us/img824/724/charsx.png

although all ips in the enc is 127.0.0.1, I still can enter Punky's world and play o.o would be nice if someone can tell me what is that all about lol

it still needs to be fully tested regarding subjects as lag issues ie.

I got the IP stored somewhere else :3 ?

When we talked about a proxy (multiple times), we said it would be a bad idea...

but it was only in theory nab...
just quoting a friend of mine when i said it could cause lag in PT:

Quote:

---

But you do know that every pixel of your Ubuntu desktop is transmitted to the X-Server via the TCP/IP stack to the localhost, probably via a desktop compozitioning "proxy" such as Compiz Fusion. ^_^

Each extra task the hardware is asked to perform is going to increase "load" on some portion. The question is whether that load would result in "lag".

---

lol, desktop compositing is something completely different... Is this the same friend that told you the other thing that was wrong? ;) I'm telling you now that this is going to cause lag, which will affect peoples' gameplay in a very negative way. Think of combo...

Quote:

---

Originally Posted by Yamachi

lol, desktop compositing is something completely different... Is this the same friend that told you the other thing that was wrong? ;) I'm telling you now that this is going to cause lag, which will affect peoples' gameplay in a very negative way. Think of combo...

---

what other thing?(oh, that var thing? XD not its not, yes that one was an epic fail XD)

bobsobol said that, here is the thread: http://forum.ragezone.com/f286/pt-proxy-811036/

maybe in PT it wouldnt produce lag because it would run in the same machine as the server? while in Cabal, it would be on a different machine?

It's going to cause lag, regardless, especially if your proxy isn't written to handle 100's of connections efficiently.

I cant see why it would cause lag. The proxy would be in the same country as the linux server, and maybe, in the same machine if its under a virtual machine.

howevern, I agree that it would cause lag if the proxy is in china and my server is in usa. you know, it only gets the packet and just sent it further. just like one of the many routes of the packet. how much time would it increase? a few ms?

IP thief! The dude removed my name! Hahahahahaa.

Treading on Yamachis turf here. :blink: Everybody please ignore my nick colour, it doesn't apply here. :D:

I also said this:-

Quote:

---

Originally Posted by bobsobol

I would also add, or remind you, that this Gateway / Proxy does not have to exist at the TCP/IP level, in this case. It could be an API proxy on Winsock library.

I've used one of these to change the "encryption" or "protocol", and while I'm sure it increased the CPU load, I don't think it would impact "lag" until the CPU activity became saturated.

---

Which I believe is closer to the way Compiz Fusion works. (thought I've not analysed it, just seen one of those block diagrams of where it fits into the system)

IDK about CABAL protocol, but if Nickttes proxy can be re-targeted that easily (looks like a modification of the same code, but could just be similar design choices) I'm guessing it's not quite as complex as a streaming media re-muxing gateway, let alone one that transcodes the stream. That's the time you really start hitting lag... unless you write bad (no... to harsh, in-expert) code.

In many ways the NAT Gateway port-forwarding in most home routers is a very simple proxy. All it does is forward traffic on one WAN port to a specific other port on a LAN IP. Most are based on in-built routines in BSD, where the whole "socket" idea started.

They will often keep some level of traffic and routing log... so if you're looking at achieving packet logging with your proxy / gateway program, that would seem reasonable. Try to keep disk writes low, perhaps log to SQL, the Registry or Windows System Events... or on other OS, system logs. If you really want to manage the files your self, careful buffer tuning would probably be in order.

We where looking at adding, modifying and enhancing existing features and securities in PT, and that will increase the CPU load, for sure. But the PT server really doesn't place much strain on that resource at all, so it's not a big issue.

SSL tunnels are popular for securing connections, and that is also little more than a simple proxy, passing one unencrypted port to an encrypted one, and probably doing the opposite at the other end.

I'm used to using caching proxies to reduce lag, (commonly, DNS, LDAP, HTTP ... but anything which frequently serves largely static records is a target ... so, fe. IRC would not be suitable, and therefore, most of an MMO isn't either) and protocol exchanging gateways to increase availability, or reduce intrusion risk. For example, using a gateway to serve FTP, or POP & SMTP via HTTP... to serve RTSP via RTP or MMS or serve HTTPS from a plain HTTP web server. Yes, of course you can tunnel your MMO protocol via SSL... and yes, that will certainly introduce some lag. How much will depend on many factors, and you may like to just try it out to see.

All these things work, and are beneficial under certain circumstances. Of course, they are all very common, well documented protocols for which there is a wide availability of developers already actively working to improve one-anothers' code. But RaGEZONE is all about trying to improve that situation for people like us.

If you get a memory leak, or fail to tune & profile the threading and IO sufficiently, performance will wane under strain. That's a given.

I know that PT isn't CPU intensive, and isn't bandwidth intensive. The server falls over because of limitations in it's 32-bit memory space and poor memory management long before the user count can get to use most of these resources. I've never run a CABAL server, so I can't say anything about how that will go.

If all you are looking to do is change the port easily, or log a few key packets, or even filter out certain packets known to cause problems, you should be okay. The more elaborate the translation / filtering you implement, the more you will run into problems. The more simultaneous connections you support, the more you will have to watch your own resource use. And of course, as with anything relying heavily on tasks / threads, you will have to keep a close eye on re-entrance and data integrity of your threads / processes.

The only thing I can say is, try it, and see how it goes. Best of luck to you.

Problem is, you'd be decrypting, analysing, taking the appropriate action, encrypting, then sending on to its final destination. You have to do this both ways, so you're doing more work than the server does on that front. You're also talking about doing this on the same machine as the server.
Posted via Mobile Device

Okay... that's a valid issue. Or, at least, it could be.

In PT the "encryption" is 95% a single XOR instruction, and 3% figuring out where not to use it... so it's largely irrelevant. If you set the encryption key to 0, you almost don't know it's there. :lol:

Beyond that, we know where the routines are in the server, and regularly replace them... if we replace them with empty routines, or remove them all-together, then we can perform the algorithm entirely in the proxy, and our "encrypted" client will still connect to our unencrypted server via the proxy, which is now the only place encrypt / decrypt is done. (server side)

Even with more sophisticated cryptography, maybe you can find a similar solution for CABAL?

Quote:

---

Originally Posted by Yamachi

Problem is, you'd be decrypting, analysing, taking the appropriate action, encrypting, then sending on to its final destination. You have to do this both ways, so you're doing more work than the server does on that front. You're also talking about doing this on the same machine as the server.
Posted via Mobile Device

---

ah, now I see your point =p

But you wont have to change *all* packets. Just one or another for security reasons. you know?

Quote:

---

Originally Posted by bobsobol

Even with more sophisticated cryptography, maybe you can find a similar solution for CABAL?

---

Yeah, I suppose you could remove encryption.

Quote:

---

Originally Posted by .Price.

ah, now I see your point =p

But you wont have to change *all* packets. Just one or another for security reasons. you know?

---

If all you wanted was to block some packets and prevent certain exploits (like illegal names), then yeah. However, if you wanted to support newer features, things start getting much more... processor-heavy. Also, keep in mind that you're essentially opening doubling the number of TCP connections required per client. It would be nice, but it will definitely introduce extra latency, no matter how little you actually do. The more you do, and the more players you have connect, then more you are going to notice that extra latency.

Adding new features will increase complexity, and add some logic to decoding. Adding a proxy adds another active task in memory and some additional logic. Again, I'm not sure how great the difference would be between adding support for extra functions to the server, compared to adding the support to a proxy.

Now, as I said, you don't have to pass the information via TCP/IP... because you can replace the normal server socket code (and, potentially the cypher code) with code to communicate via other means... NamedPipe is obvious, the Windows Messaging service is another (that usually communicates UI interaction, but also signals between programs and service startup, suspension and shutdown etc. See Snarl for a very good, simple example of these messages in practice)

Additionally... why are we worried about the open socket count exactly? Okay, XP, and to a lesser extent Vista and 7 are crippled on the number (unless you "patch" it) but the thinly disguised reason for that was that you shouldn't buy a home / workstation OS to run your server apps on. They aren't built for it. In any server OS the number of socket handles shouldn't be an issue. (if they are, you may want to look at switching brand XD)

Yes, managing handles to open ports in your proxy program will need to be done "with care". Or am I missing your point there again Yamachi?

Again, until it's tried, all of this is just theoretical conjecture. Linux and NetBSD are very much built for this kind of task, Windows and MacOS "claim" to be sufficiently competitive. From what I read, very few "independent" developers outside Microsoft and Apple would actually choose these OS out of any preference other than "our users demand", and if they have a Linux version it typically far out-strips the Windows version. (with Macs, the hardware lock-in is usually the killer)

As a side note, Windows "Named Pipes" can be accessed from a Linux server via SAMBA, I believe. (do you really want to run this system across two OS? I doubt it)

Named pipes use TCP, you know :p. Also, the server runs on linux. Sure, there might not be any harm in trying, but there's no point in making it public just for everyone to be disappointed if it falls through.
Posted via Mobile Device

Hmm... Not sure about Linux, but Unix supported Named Pipe before TCP/IP. They where actually part of the C "streams" system they built into the "everything is a file" philosophy. It's traditionally just a shared memory stream.

Windows Named Pipes work locally even if you don't have the TCP/IP stack loaded. Though Windows hasn't supported "Named Pipes" for nearly as long. It was very unreliable on V4.

SMB (CIFS) is typically overlayed on TCP/IP, but can be run through other network protocols. (notably, we used to use NetBEUI a lot)

If the server is Linux based, I would suggest that the proxy should be so also. Certainly, the number of sockets should not be an issue on any Linux build. .Price. works in C#, encourage him to build against MONO. (I keep trying, but PT is always Windows, for shame)