@chrism01
yeah, its a good idea to do this so you can do remote config too
i thought about this, but i don't want this to be a security hole
now it doesnt matter cause
it works!
fifo's aren't the easiest way to solve this kind of stuff
the problems i had with the fifo stuff:
i read many simple examples and i did some examples which worked good
then i tried to implement it to make something like a "fifo-configuration infrastructure"
the goal was to be able to configure every process of a server seperately
so i could for example change the serverport on the fly (thats cool!)
the problems i had where:
the configserver sends the config request to its fifo-childs and each child reads it using a configthread
the thread does the configuration and sends a response back to the server!
the response was my biggest problem
first i didn't understand why a FIFO is a half-duplex pipe!
so if you want a full duplex fifo, you have to create 2 fifos
if you open the fifo O_RDWR it's only a half duplex pipe, so if the same process writes something and reads again it will read what it wrote!
the second problem i had was that the configthreads write some data in the serverpipe but it wasn't created already
it was because every example i read did a mkfifo and in the next line a open(); so i didn't think about using this seperately
i was sending the request to the threads, did a mkfifo and opened and i only got some responses with a bit luck, because the pipe was opened too late
now i do a mkfifo, send the request, open the fifo O_RDONLY and read the response ;-)
the third problem was i didn't know what happens to my server fifo if many childthreads try to open the fifo using O_WRONLY
and now comes a really tricky part
if the server does a mkfifo
then sends the request
and the clients open the pipe, write the response and close it!
the END OF FILE is getting sent too!!
this means, if i send the request to 2 childthreads and both threads write the response and
then i read from my serverfifo, the read(); returns 2 times 0
so i read
first read: "RESPONSE"
second read: returns 0
third read: "RESPONSE"
fourth read: returns 0
so i made it part of my protocol: i send the request to the childthreads and i count how many childs got the request (if(write()>0) count++)
then i checked how often read returns 0 (readcount++)
if readcount==count i got every response
this method seems to work very well
