LuaRPC Update Jun 1, 2009

I’ve got a few more issues to attend to before I’m going to put the LuaRPC code into the eLua trunk.  One thing that I’m thinking about that I’ve not yet come up with a satisfactory solution for is dealing with connection state.  The original code used sockets, and therefore the protocol makes some assumptions that, in most cases, data arrives in order with no errors, unless some exception is thrown.One advantage of all of this is that the code is reasonably simple and is minimal on CPU usage.  However, I think it’s a little too minimal to handle serial communications where a client might hangup or one simply gets a bad read, and there are only the TXD and RXD lines to indicate physical/data link state.  So far what I’ve done is padded out each buffered read & write (one or many bytes) with a header and tail byte (different) so that either the client or server can complain and jump back to waiting for fresh requests on error.  I may consider following HDLC a little more closely in terms of asynchronous framing, but this may be OK for now.It should be easy to layer checksums, addressing, retransmission or other assurances on top of this implementation by simply wrapping the functions that read and write chunks of data.