I’ve now both gotten it working on 5.1.4 and have abstracted out the transport layer. As it stands which “transport” one uses is a compile-time option set by enabling or disabling some defines in config.h, but both serial (using pty to simulate real serial) and socket connections seem to be working at the moment for desktop use. It’s still somewhat rough around the edges, and I’d like to be able to support multiple transports from a single compilation, but I’ve not decided how I might want to do that yet (multiple modules? function pointers that allow switching within a single module file?).The existing module uses C-based exceptions to deal with transport-layer errors (take a look at luarpc_rpc.h if you’re interested). I know we’re not really using exceptions for most of the eLua modules, but I’m wondering whether I should leave that in place, or change that in order to be friendly to porting. As it is set up, it doesn’t have to derive from errno codes defined by system libraries (not sure whether Newlib provides an errno global), so if custom codes or strings are needed they can be set up. I think, though, with the current flow, some exceptions will need to be thrown in order to enable connection resets when the client disappears, or if bad data is sent/received.Additionally, argument handling for connection setup that varies between transports is included in the “transport” side of the code, so the API to the transport layer includes a few functions that want a lua_State. This feels a bit undesirable to me since some of them push stuff onto the stack depending on what args are given to them, and that number has to be passed back up the chain of called functions, since none of the transport layer functions are called directly from Lua.Also, beyond whatever was included in the original code, I’ve not done anything special security-wise to prevent clients from doing nasty things. That said, if you were letting someone connect to a LuaRPC server, you were already letting them run arbitrary code on your server (unless you disable loadstring), so… :-)I think I’ll have an eLua serial backend going sometime in the near future, and I’ll certainly mention that when it’s ready to be abused.