What about doing a mkfifo /var/lib/systemimager/clients.xml when si_monitor starts? then we should add an option in si_monitortk to save the clients data, but this is quite easy to implement...
And I agree, the protocol can be improved a lot, at the moment we're using the simplest implementation... another improvement could be to use UDP instead of TCP, I tried in the past to move to UDP, but I had some problems with netcat in particular for closing netcat at the end of the message (if I remember well)... maybe we can spend some time and investigate on that... but IMHO after 3.7.4 ;-) -Andrea Erich Focht wrote: > On Wednesday 02 August 2006 20:33, Andrea Righi wrote: >> Erich, >> >> thanks for the simulator! from a quick test it seems that the fs >> overhead is quite high... for example moving clients.xml in /dev/shm >> strongly reduce the load and cpu time of si_monitor and si_monitortk.. >> so the idea to move the data in RAM seems reasonable.. > > Good! /dev/shm would probably already help a lot. But not writing at all would > be even better, still for that you need some IPC method between the receiver > threads and the master thread. pipes seem to be the simplest tom implement. > > BTW: You are sending two requests right behind each other. One for status and > one for speed. Each triggers a write. Guess you could easilly extend the > protocol to save one ;-) > > Regards, > Erich > ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Sisuite-devel mailing list Sisuite-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sisuite-devel
