Info Status: Released It compiles and runs on Windows, Linux and Mac Feature development is basically finished Feedback needed from server admins Version: 1.0 "Albatross" Source code: https://github.com/ihlades/ACSRelay Opening post Hi! I've started work on a little software tool that allows you to connect more than one UDP plugin to the server. The idea is you will be able to run Minorating, sTracker and other server plugins at the same time. The following diagram should explain the concept: It works okay even if plugins request car updates at different rates, but the algorithm may not be the best. I'm currently implementing a new feature that will allow two ACSRelays to communicate with each other over TCP, thus enabling plugins over the internet. Since UDP does not guarantee datagram delivery, having a plugin on a remote machine is not a wise thing to do, but ACSRelay can allow for this in a safe manner, as TCP guarantees data delivery and data integrity. I'm trying to make ACSRelay available cross-platform, so you can run it both on Windows and Linux. The general philosophy behind ACSRelay is to get in your way as little as possible - no plugin modifications are needed (except for configuring them) and there are no special requirements other than having the necessary ports open. It's not currently tested (heck, I don't even know if it compiles since the last changes), so it will be a few more weeks until release, I hope. I will be back with more details.
I love seeing stuff like this; it just goes to show what a great platform AC is; so many things to do in all areas. You're an artist ? Cool, plenty to do. You're a sound guy ? Join in. You're a programmer ? We love you too. Any "digital" passion you might have, there's something you can do in AC . Looking forward !
<3 Thank you very much, this is highly appreciated. A good, neutral relay is really what is missing currently, but since everybody is busy with his own stuff nothing happened. 3 questions: #1 How do you plan to handle the realtime interval? It would be insanely cool if your Relay tracks the different intervals per plugin and redirects them accordingly (let's say plugin sTracker wants 10 Hz, Minorating 1 Hz) #2 Do you parse the messages? (ofc related to #1) I've seen the protocol file in the repository, but I'm wondering if you couldn't also just redirect the binary data #3 Do you mind posting about this on the ac forum? I'm sure some guys are highly interested and even might want to contribute/review your project Thank you very much for your effort, and best luck! Looks really good and promising. Edit: nvm about #2, this is a valid approach. I did always argue that a plugin has to handle higher frequency well (although it currently hurts my -.-), so you're good with only increasing the frequency @ https://github.com/ihlades/ACSRelay/blob/master/ACSRelay/ACSRelay/acsrelay.cpp Edit 2: in my opinion the same goes for Session + CarInfo. The plugin should always handle it correctly, not only if it's requested. So maybe you could think about ignoring that packet inspection and just redirect the stuff, at least this part is getting complicated
Great to hear from you Minolin, and good questions. #1 and #2 defined the architecture of the software early in the planning phase. I'll reply to #1 and #2 together: this is precisely how it works. The software "peeks" into several types of packets, but not all of them. It looks in ACSP_REALTIMEPOS_INTERVAL, ACSP_GET_CAR_INFO and ACSP_GET_SESSION_INFO when a message is coming from a plugin - this is required to know which info the plugin is interested in (interval of car updates + which car/session ID for the other two). Correspondingly, when a server message is received, the software peeks in ACSP_CAR_UPDATE, ACSP_CAR_INFO and ACSP_SESSION_INFO. ACSRelay tracks which plugin expects what piece of information and also at what intervals (for the car updates) and delivers the packets intelligently. Well, it's quite simple: for car updates each plugin has a timer for each car set at the required update interval; if the timer has fired and a car update packet is received from the server, it'll go through to the plugin. It's all in acsrelay.cpp and peerconnection.cpp. Obviously, this isn't the most precise way to do it, but plugins shouldn't rely on receiving packets at the exact specified interval anyway, because of the time resolution of the server, network delays and so on. For requested car/session info, each plugin has its own flags (one for each car/session). The INFO packets are delivered only to those plugins which have the necessary flag set. Packets are relayed with their binary data untouched. ACSRelay just dumps on one socket what it reads from another one. Also, one important aspect is that not all ACSP_REALTIMEPOS_INTERVAL go through to the server, because we're interested in sending only the minimum interval for car updates. I've tested ACSRelay, it really works! But I haven't tested it since adding the TCP daisy-chaining feature, which might've screwed things up. But I think this one is important for those who run remote servers, since installing binary, executable plugins may not be the easiest thing to do in this case. Plus, it allows you to have Windows- or Linux-only plugins, by running them on a virtual or remote machine. Also, I need to find the time to write dummy plugins which request car updates at different intervals to see that this works as intended. I can post in the official AC forums to let people know about this project, but I'd like to keep the discussion going on here, because I don't spend much time on the official forums.
Sounds very good. Clever setup really. I regret not having the time to review your project (but I know somebody who already does). The only thing I don't really like is the TCP part, I don't think you should offer this kind of tool to guys. More risks than gains (for them). Could you sketch a configuration file for a setup with two plugins, maybe minorating & stracker? I'd like to built something like "native" support for the acplugins4net framework.
Hello, Zeno- here (gcflora). I've made some minor updates to get it to compile on Linux and also added a simple cmake file. The cmake file should also work on Windows but I'll probably need to add some conditionals (well, I will... compiler flags for vc++, mingw, etc) but that's easy enough. I might make a bat file so that cmake for Windows will output Visual Studio and Code::Blocks projects but then again I might not; it's easy enough to do using the cmake documentation Cheers
Not saying you're wrong, but I just don't get how this is a risk for ACSRelays users (which is fair to assume are server admins). Could you please elaborate? I'm also considering to have TCP disabled by default. Yeah, sure. I'll do this later when I get home and read sTracker & MinoRating documentation. I think the sTracker and MinoRating configurations for this schema (with ACSRelay managing them both) should actually be explained in the README file, because these two are obviously the most popular plugins. Good stuff. The final software should run on Windows and Linux (it's kind of stupid to develop it under OS X on my behalf, but hey...). However, I wouldn't put too much time in build scripts and IDE project files. I think the best way to tackle this is to release binaries for each platform. The source code is open because I don't expect to install shady software from some game forum without knowing precisely what it does.
Yes, I agree. With the cmake file those IDE things are easy to produce and more of a developer convenience anyway. But cmake is necessary; if not then a traditional Makefile, but that's not as easy and less flexible. I suppose g++ *.cpp on the command line would work, but... well cmake is easier (for a start you don't have to build in the source or project directory so it keeps things clean)
@Minolin here's how the configuration files would look like if you were to run MinoRating, sTracker and ACSRelay on the same machine. Random values used for ports, of course. AC Server server_cfg.ini (relevant lines): Code: UDP_PLUGIN_LOCAL_PORT=9000 UDP_PLUGIN_ADDRESS=127.0.0.1:10000 ACSRelay settings.ini: Code: [SERVER] IP=127.0.0.1 # Server IP address LOCAL_PORT=10000 # ACSRelay UDP port REMOTE_PORT=9000 # Server UDP port TYPE=AC # RELAY for chaining multiple ACSRelay or AC for connecting to an AC game server # MinoRating plugin [PLUGIN_0] ADDR=127.0.0.1 # Plugin IP address LOCAL_PORT=11000 # ACSRelay UDP port REMOTE_PORT=12000 # Plugin UDP port # sTracker plugin [PLUGIN_1] ADDR=127.0.0.1 LOCAL_PORT=13000 # ACSRelay UDP port REMOTE_PORT=50042 # Plugin UDP port sTracker stracker.ini (relevant lines): Code: [STRACKER_CONFIG] ac_server_cfg_ini = <path to fake server_cfg.ini> listening_port = 50042 Now this is the stupid part. AFAICT, sTracker cannot send packets to a configurable port; it reads UDP_PLUGIN_LOCAL_PORT from the server_cfg.ini. With this in mind, we have to feed sTracker a fake server configuration file. The fake server_cfg.ini should contain at least this: Code: UDP_PLUGIN_LOCAL_PORT=13000 Since ACSRelay acts as the server for the plugins, we configured it to listen on port 13000 for sTracker. Regarding MinoRating, I didn't see any network-related options in the online documentation, so I just used the default 11000 & 12000 ports. Hope this helps, Victor.
Thank you, pretty good. I had hoped for a named entry though, maybe you could add+ignore an etry in [PLUGIN_n] like NAME=sTracker, so we can deploy all our stuff in a way it works in a default config. MR would then try to locate your settings.ini, find it's section and is good to go. This highly reduces our maintanace effort. You can override the UDP config with this section Code: [ACPLUGIN] ; proxy the AC server protocol on these ports, so multiple plugins may be chained (this is equivalent to UDP_PLUGIN_LOCAL_PORT in server_cfg.ini) proxyPluginLocalPort = -1 ; proxy the AC server protocol on these ports, so multiple plugins may be chained (this is equivalent to UDP_PLUGIN_ADDRESS in server_cfg.ini) proxyPluginPort = -1 ; udp port the plugins receives from. -1 means to use the AC servers setting UDP_PLUGIN_ADDRESS rcvPort = -1 ; udp port the plugins sends to. -1 means to use the AC servers setting UDP_PLUGIN_LOCAL_PORT sendPort = -1
MR has the problem you expected for the sTracker. It reads the server_config.ini and uses those ports. It can be overriden by the specified ports, but you have to set read_server_ini = 0 which causes other problems. Will be changed with the MR update after the ac 1.3 update in a way you can easily configure the ports (or even better, just read your settings.ini).
Thanks for the clarification, I really thought that last section of sTracker's config file was only about proxy stuff. That's good then. About MinoRating, please provide a method to set your own ports as it's much more versatile this way. I mean, sure, optimize it for the most probable usage scenario (on the same machine as the server, possibly with ACSRelay), but you needn't limit the software to those scenarios only. Adding a NAME key is actually a good idea. Right now, ACSRelay gives each plugin a name (the "PLUGIN_n") as an identifier. But adding a NAME key will only take 2 minutes to implement in the software and will allow for arbitrary plugin names.
Updates: It now compiles and runs on Mac, Linux and Windows. Added NAME parameter for plugins. Doxygen updates
With the next plugin release (I think 1.3 will be the time) you will have those: Code: <!-- AcServer/proxy listening port like defined in UDP_PLUGIN_LOCAL_PORT --> <add key="ac_server_port" value="11000" /> <!-- Plugin listening port towards acServer/proxy like defined in UDP_PLUGIN_ADDRESS=12000 (without 127.0.0.1, port number only) --> <add key="plugin_port" value="12000" /> For testing purposes you can use them in the plugin version RC3-1.1, they have been implemented in the very beginning. But you need to set Code: <add key="load_server_cfg" value="0"/> which will result in some error messages around the blacklist mode (shouldn't hurt). Plugin version 1.2 will then override the ports if they are defined, ignoring load_server_cfg completly. --------------------- Yeah, next step: Currently I recommend placing the MR binaries into ac_root/server/plugins/minorating so my default "where is my server root" path is ../../ and the guys don't need to configure anything. If we manage to do the same together, it would be great. So I ask you to define a default location that MR could search and use without additional settings. Sure, important is "by default". A lot server admins have quite advanced setups, but they also don't have problems understanding and configuring ports. Others have, and are doing best if you just say "put this here and this here and press start". --------------------- I didn't answer this yet, sry. The risk is a) security and b) performance. In a scenario where you run a plugin as-a service over the wire, you're basically let the acServer parse binary stuff you don't really know - and I assume that stefano hasn't invested much time to protect the UDP stuff against code execution. Unnecessary attack vector imho. Second is that - at least when you start with serious car update intervals - you're increasing the network traffic for the server. If you need centralized data processing (like MR does), you should setup a local plugin as aggregator and only send the required information to a backend. Of course there might be cases in between, but even then a simple (local UDP)->(intranet TCP) redirector plugin could work better then. Alltogether I don't think the option is worth it, confusing people and tempting plugin devs to do strange things.
IF I make it disabled by default, I think it will be only used by people who know what they're doing. Keep in mind that if you do not define a TCP port in the config file, the TCP feature is disabled. Speaking of security issues, the AC server is absurdly easy to mess with... with or without plugins, it's very easy to break things from the outside. But, then again, it's a simple game server, so what do we expect? L.E.: How about this default configuration file? Code: [SERVER] IP=127.0.0.1 # Server IP address LOCAL_PORT=10000 # ACSRelay UDP port REMOTE_PORT=9000 # Server UDP port [PLUGIN_0] NAME=MinoRating ADDR=127.0.0.1 LOCAL_PORT=11000 REMOTE_PORT=12000 [PLUGIN_1] NAME=sTracker ADDR=127.0.0.1 LOCAL_PORT=13000 REMOTE_PORT=13001 I'm thinking of delivering something similar, if not identical, with the software. I removed the server type reference (since people don't need to know about the TCP stuff) and added the plugin names. I'd propose that we consolidate the installation path for our plugins. Let's have all of them in a single place, such as "<AC_folder>/server/plugins/" so minorating will reside in "server/plugins/minorating" and ACSRelay in "server/plugins/acsrelay".
I'm with you here. I just think the legacy communication "attack" vector is big enough, we don't need to offer the plugin stuff as well. A silent feature will be ok. If anybody is trying to use it, I hope he comes somewhere to exchange thoughts (in a specific context). Great! Maybe, as a little addition: remove the explicit ADDR. Same story as above, no need to offer the idea of running the plugins somewhere else. Use 127.0.0.1 as default and have it overridable by people who know what they are doing. Sounds very good, I could think of a solution where plugins like MR would search for ../acsrelay/settings.ini per default (if not decativated by setting), and ignore it if it's not found.
Where/how would those who know what they're doing override it if not in the .ini file? Or do you mean people who compile it themselves?
