Contents   Index

Problems with PeStO

I have encountered the following problems with $\mathcal{P}$$e$$\mathcal{S}$$t$$\mathcal{O}$:

1. On the server empty lockfiles are created. This is really not a problem, but it is does not look "pretty".
2. Filenames must have the same meaning on the server and on the client. Thus if the client application references opens a file "foo.txt" then the primary copy of "foo.txt" must be in the same directory as the server program was started from, i.e., current working directory. During testing this of course posed no problem, but if the system is to be used for real someday, then an alternative solution may have to be considered.
3. When disconnected and using close $ET \! B$ of zero,^7.1 then child processes awaiting better communication are created. If this is done many times then the (UNIX) system may run out space for additional open file pointers and/or socket descriptors, or even result in too many processes.
4. If client and server are not synchronized then $\mathcal{P}$$e$$\mathcal{S}$$t$$\mathcal{O}$ will behave unexpectedly. The current version of the server actually accepts requests initiated by the client after the server has received it!

I believe that the first and second problem are easy to live with. I do not know about the third one! A way to solve that one, could be to let a single process (e.g., a daemon) handle all "pending" closes. All in all I think that $\mathcal{P}$$e$$\mathcal{S}$$t$$\mathcal{O}$ works OK. The fourth problem was expected and is solved by remembering to keep the clients synchronized with the server--it is easy to do, but it must be remembered!

Footnotes

... zero,^7.1

Or any $ET \! B$ that times out before any type of connection is made.

  Contents   Index