The dual I/O problem

Among the first problems that surfaced while coding ProtoWrap was the dual I/O problem: Data can come, at any time, from either the client or the server. Many different models were tested, being the most important ones:

Forking+IPC

As soon as two connections are established, the wrapper forks into two separate processes; the parent handles communication with either socket and the child with the other one. Now, this would work if the amount of validation were to be limited. Handling, however, more complex client/server interaction requires mantaining a state of the connection, which can only be achieved by having constant communication between the processes. This could be achieved fairly easily using threads, but as thread support in Perl is still regarded as experimental, the author decided to go for a more reliable solution. IPC signals, temporary files or other external methods are prone to becoming too slow, and would make the code far more complicated.

Preset whole lines

The wrapper knows beforehand how many lines does each command answer with, or how to determine when the last line is reached from the data stream itself. This could possibly be implemented without much hassle for different protocols, but a simple programming error can lead to problems much more dramatic and harder to spot. Depending on the protocol involved, a lockup state could easily be reached (for example, recieving even a single character from the client, without recieving an end of line afterwards, will never allow the server to talk again), making our server keep possibly hundreds of open, idle TCP connections, and maybe even locking other systems depending on our correct behavior.

Low-level

The wrapper could also talk with server and client not using the easy-to-understand, high-level socket interfaces (using Perl's IO::Socket module), but instead treating them with the lower level filehandle interface (with Perl's IO::Handle). By doing this, we can use IO::Select to handle I/O from multiple filehandles in quite an elegant way.

The low level model was chosen because of its high effectivity and low intrusiveness.