My question is, how do I get my pipe on created proccess?
I have headless server, where I creating instances of Gameplay Servers and I tried approach of creating proc then set pipes using FPlatformProcess::CreatePipe and those void pointers passing into FPlatformProcess::CreateProc, and now i scratch my head how I can access the pipe from created proc and send a message back to proc that created it?
(I know I can use sockets etc, but i want to use Pipes using unreal)
this is quite vague.
do you know how to use pipes, or are you asking on how to write/read on them?
i havent used pipes on ue before i only have a vague memory. but afaik pipes are treated pretty much like files on most os. which means you read and write to them using the same functions you use to read/write on files. though on most platforms reading from a pipe is a blocking operation, if the pipe is empty it might block until something writes (and flushes).
calling createpipe returns a handle (similar to a filehandler i believe) maybe you could share that number with other process to open the pipe as well.
look for ManagedProcess.cpp::CreateManagedProcessWin32 it does some stuff with the default pipes.
So probably there is a way in ue to create a pattern of “Named Pipes” and use it on processes.
Blockquote
do you know how to use pipes, or are you asking on how to write/read on them?
Blockquote
^ Well I didn’t used pipes before, I heard about them as “a one of many ways” so far I used sockets, also on my list is learn how to use Shared Memory, but if they work on files then is pretty straight to me.
sockets are pretty much like pipes on network in terms of how they work (though this is a very rough statement).
im assuming you’ll get more performance out of a pipe though.
btw i don’t know what you’re trying to do, but if you’re gonna look into sockets, unreal has implementations for Stomp and OSC built in.
I already used sockets localy to perform data exchange between instances of the server, wanted to switch into pipes seems like more accurate solution for instanced of server on the same machine
My work(if i can name it like that, is more like working on self development by creating personal project) is to create a game, that works on dedicated server, match two players into game, launch instance of server with gameplay map, then communicate master server with instance of the game(gameplay) by sending information like the match is over, length of the game etc, now i created separated logic for pipes in ActorComponent for my GameModes both on master server and instance of gameplay, and in incoming days I gonna test pipes how they perform ^^
imho practice is the best way to learn. keep it up
that’s also my way to learn and what allowed me to start my own game (and a reason why too).
regardless if you plan on using it. these are my thoughts on practicality:
if you are using this on servers, i might go with sockets over pipes preferably.
since that might give you more flexibility. it’s easier to have the instance on different vms/machines than on the same one. you can scale them and you can restart them. and you isolate them, which might be a nice security concern.
sockets are a bit low level for practical use. unless you are going to implement your own framework, which, unless your goal is to make a framework, i would prefer using something a bit higher level. i like osc since is fast and really easy to use, but im not sure it’s bidirectional, though nothing stops you from having a osc server on both instances and cross connect.
stomp is an alternative that i used. it’s nice since you can use it on websockets, android devices, etc. but its text based like http, so its slower.
and aside all that, i recommend you take a look at cbor, unreal has an implementation for it.
its like json but binary (there are still places where i would use json but for pipe transmission, it might be preferrable).
and is also widely available, like in python and others.
all the best, and i hope you make public your findings and learning (even with a github project), so others can learn too.
