On Wed, Sep 15, 2004 at 04:55:05PM -0400, Hugo Duncan wrote:
documentation is sorely lacking... but giallo adds a level of indirection to what I have understood of your current thinking:
reads, writes etc are not directly initiated by the demultiplexer, rather by the connection class, which is responsable for combining the socket (pipe, or whatever else) class with the demultiplexer, hiding the details of which demultiplexer is used and ensuring the socket is in the correct blocking/non-blocking/ asynch mode.
Ok, I considered that to be obvious. Consider the abstract Source 'device'. This device is capable to delivering a (byte) stream of data and/or a stream of data in the form of 'packets'. Also the byte-stream will will be delivered in packets (significantly more than 1 byte at the time) but in that case the size of a 'message' or packet is unknown. Then what is needed is the following: 1) An object that encapsulates the 'device' abstration. 2) A way to request more data (this exists of a function call to which the user provides a buffer pointer, and the size of that buffer) 3) An entry point for a thread to call to 'sleep/wait'. 4) A callback (or completion) function that is called when a new packet was received. It should be possible that point 4) is *entirely* handled in the user code, the only thing that the user wants it get control of the thread again once data is available. The user then can examine the received data, manage its own buffering and decide to either decode a message and handle it - or to leave the partial message in the buffer and request for more data. Only once we have this interface we can provide "convenience" classes that do buffering for the user as well. And even think about providing protocol decoders too for common types of protocols (text, envelloped binary, fixed message sizes etc). The most frequently used name for the function mentioned in point 2 above that I have seen for sockets is 'async_recv'. Note that async_recv cause its completion routine to be called as soon as new data is available and additional data would cause more delay (blocking). A function async_recv_n, that requests *precisely* 'n' bytes, and not less, can be easily implemented on top of async_recv - or by means of the OS in some cases. -- Carlo Wood <carlo@alinoe.com>