Factorio Forums

Hey,

As you probably already know me i am a big fan of using rcon and i recently founded out it takes quiet a lot of time until factorio answer to rcon tasks.

Is it possible maybe to have a game start parameter to make remove this rcon "security" it looks like it's blocking to prevent ddos or something like that.

What could i do i tried to optimize the scripts i am using the most i could.

we really need a C/++ ABI for server side mods to be compiled and executed only on the server, for example. clusterio would very much benefit from native mod API. Lua still would be the only way client side mods would work.

Maybe instead provide a whitelist of IPv4 / IPv6 addresses to which there would be no ddos protection / delay / logging? And include localhost in the list by default.

There is no limiting or protection built in to the rcon logic. It runs the same as network packet logic as far as I know.

Rseding91 wrote: ↑Wed Feb 12, 2020 7:52 pm There is no limiting or protection built in to the rcon logic. It runs the same as network packet logic as far as I know.

how about a server side ABI for high throughput commands?

ptx0 wrote: ↑Wed Feb 12, 2020 8:04 pm

Rseding91 wrote: ↑Wed Feb 12, 2020 7:52 pm There is no limiting or protection built in to the rcon logic. It runs the same as network packet logic as far as I know.

how about a server side ABI for high throughput commands?

stdin?

ptx0 wrote: ↑Wed Feb 12, 2020 8:04 pm

Rseding91 wrote: ↑Wed Feb 12, 2020 7:52 pm There is no limiting or protection built in to the rcon logic. It runs the same as network packet logic as far as I know.

how about a server side ABI for high throughput commands?

That sounds totally unnecessary. What is wrong with TCP connection to do that?

for even higher throughput than that. stdin is based on pipes and still respect their in-kernel limits. tcp requires handshake on each connection. I am thinking of this for Clusterio where we might have many instances all transferring hundreds of thousands of items per second.

ptx0 wrote: ↑Wed Feb 12, 2020 9:04 pm for even higher throughput than that. stdin is based on pipes and still respect their in-kernel limits. tcp requires handshake on each connection. I am thinking of this for Clusterio where we might have many instances all transferring hundreds of thousands of items per second.

Not really something I want to put any effort into supporting.

Rseding91 wrote: ↑Wed Feb 12, 2020 9:45 pm

ptx0 wrote: ↑Wed Feb 12, 2020 9:04 pm for even higher throughput than that. stdin is based on pipes and still respect their in-kernel limits. tcp requires handshake on each connection. I am thinking of this for Clusterio where we might have many instances all transferring hundreds of thousands of items per second.

Not really something I want to put any effort into supporting.

fair enough, running more than one instruction per tick isn't a hard requirement, anyway, as it turns out.

There is nothing preventing you from running multiple commands on the same RCON connection at the same time, and there's nothing preventing you from having multiple simultaneous RCON connections running commands, both of these things let you run more than one command per tick. If you're running commands one at a time waiting for the previous one to complete before running the next one you're going to run into two limits: the first is that commands are processed once per tick limiting you to one command per tick, and the second is that commands are streamed at a rate of 100 bytes per tick reducing down to 25 bytes per tick when there's 20 players connected (these are the defaults, you can change this with the minimum/maximum segment_size options in server-settings.json.) If you send large commands they will take a long time to stream into the game.

If you chose to run multiple commands in parallel or increase the segment_size limits keep in mind that due to this issue Windows clients to gets dropped from the server when more than 8000 bytes worth of commands are executed in a span of 2-3 ticks.

-------

Being a Clusterio developer myself I can also say a server side only C++ mod interface is something that would be of very little value to Clusterio, and it would also be very limited in what it could do due to Factorio's shared deterministic state model. The gist is that if a server side only mod changed the game state then all the clients would desync as they would be unable to reproduce that change to the game state.

Mhmm, how does it works for multiple rcon commands per rcon connection?

Also would be stdin faster and of course stable ?

You open a connection then send commands and get replies, anything more specific than that would be dependent on what RCON implementation you use. For sending data into Factorio stdin and RCON are both limited to streaming commands at the speed given by the segment_size limits in the server config, for sending data out of Factorio using RCON was faster in my tests.