meta_leap Sorry then, I wrongly assumed with the Programming tag included, stdio and JIT would be plain-jane normal terms 😀 excuse my ignorance, for I am new here ^_^

Salads of smart-sounding words do not clear communication make.

But as you wish. You can state clearly what you want to build and get some actually useful suggestions. Or you can continue to write as if you're desperate to prove you're computer-knowledgeable and not get any because nobody can decipher your intent. So please be punctual, succinct and simple. No need to act like a tryhard to prove you're not a noob. We get it 😉

    Megalomaniak For your case A, I seem to recall OS class having an execute method. Not sure about listening for the output of the external process tho. Never needed to do something like this myself previously

    That's the class I was looking for, not knowing the name, hooray! Thanks heaps! So I didn't phrase my own searches well enough.

    So OS is cool... for my use-case it'll be create_process at game start and kill at game end, but since there's no "standard I/O" with that sub-process on offer in this API, I'll still will have to use UDP. But at least I can run-and-stop that 2nd program (in a hypothetical not-on-my-machine future scenario)... will pick UDP over C++ during my hobbyist/leisure-time tinkerings for sure. =)

      To be clear tho, if you are asking about making a server, there is already a headless godot server build and of course you can use RPC for UDP connections via GDScript or C#.net as well.

      • xyz replied to this.

        Megalomaniak From what I've gathered so far I think the OP's intent was to delegate some performance intensive simulation to an external (native or otherwise) process and stream or serve data from that process to Godot app, one-on-one locally. Not full featured server.

        They basically wanted to ask if this can be done via named pipe communication. The answer is yes but only through C# Process class. GDScript doesn't have support for pipes. There was a discussion on Godot's github about this but Linietsky said "better to use TCP instead"

        So if it must be via a pipe, use C# Process. Otherwise it'll need to be either TCP or UDP socket. I'd go with TCP if communication is not time critical.

            xyz From what I've gathered so far I think the OP's intent was to delegate some performance intensive simulation to an external (native or otherwise) process and stream or serve data from that process to Godot app, one-on-one locally. Not full featured server.

            To my mind that's still a server tho, it serves a purpose. But sure, localhost rather than networked. Take for an example neverwinter nights games, I don't recall if that applied to the first one, but I know for a fact the second game used the same server to host a local single player game just as the networked multiplayer. Either ways the game actually ran on the server side of it not the client side. It just bundled the server and the client together and if you wanted to play MP you had to host the game yourself but your singleplayer session also ran on that server.

            • xyz replied to this.

                Megalomaniak I guess it's just a matter of how loose you want to be with terminology 🙂 Sure, you can call something like this a server. I personally wouldn't use that term for a program that can only do one-to-one communication, regardless of if being local or over a network. I'd argue that one-to-many is the defining feature of a server.

                    xyz Would you consider Godot's "servers" i.e. RenderingServer to be not-servers?

                    • xyz replied to this.

                        award Yes. But again, it's just a matter of semantics and conceptualization. You could for instance say that each node talks to RenderingServer as a client so then by my "definition" we should consider it a server. It's a moot point.

                          Yeah better to call it "backend" maybe than server... a rose is a rose by any other name 😎

                          OK, for anyone from the future with a similar need searching around, here's how I see this going down:

                          • in local-dev / debug builds, godot game UDP-connects to localhost "server"
                          • for hypothetical release builds, the "server" prog (and not the godot game binary) is the game-starting prog and it runs the godot game binary, this let's both communicate via standard-I/O pipes, on the Godot side via printraw (print line to stdout aka the "server") and OS.read_string_from_stdin (in sep thread — read next line from stdin aka the "server").

                          The line protocol could be no-whitespace-JSON or custom. Will use the former, assuming GDScripts JSON APIs are anyway C++ underneath =)

                          The two different modes are of course so I can F5-run with the GDScript debugger/profiler etc.

                          Thanks for the lively discussion, good lookin' out 😁

                          • xyz replied to this.

                            meta_leap Exchanging bytes by printing to console is a very inefficient and troublesome way to do it.

                                xyz the bytes are a given either way: they go over sockets or over std pipes. Are you truly telling me Godot's C++-based UDP networking is faster (or less "troubling") than Godot's C-side stdout/stdin pipes which are opened by libc before even main(), have no network checksums etc? I'm hyper-eager to learn more here, I mean it without snark..

                                What is it, are there costly string/byte conversions and happening script-side rather than C-side?

                                • xyz replied to this.

                                    meta_leap Are you truly telling me Godot's C++-based UDP networking is faster (or less "troubling") than Godot's C-side stdout/stdin pipes

                                    It might be, depending on what actual i/o streams are abstracted away by stdin and stdout on your target system(s). Printing to console is not without cost either. There are also possible encoding issues. Try to benchmark it.

                                    If you insist on using operating system inter-process communication, better to do it via proper named pipes, especially if exchanged data is plain binary bytes.

                                        xyz I'll check it out for sure. Still optimistic as I'm only targeting the usual-3 desktop OS kernels and their std pipes are likely to be on-par to named ones (sans the name "overhead"). But yeah good points for potential pitfalls to look out for. If When this ever gets so far as to become an installable offering for another's machine, that is 😁

                                        • xyz replied to this.

                                            meta_leap Also note that inter-process communication is always platform dependent, at least to a degree. Using a platform-agnostic network protocol can spare you any potential gotchas there. It's also better for future scalability - for example should you wish to port to another more exotic platform or expand the thing to communicate with remote machine(s).

                                            Even if mid level network protocol proves to be slower on a specific platform, I doubt the difference will be of any real significance if there is no need for high-volume frame-by-frame communication, as you stated is the case in the OP. So I don't see any reason to ditch the leisure and maintainability benefits of a network protocol.

                                            But looks like this is moving into premature optimization zone now. I'd go with UDP packet exchange for start and worry about alternatives when/if it starts to cause bottlenecks.