Other than to beware of concurrent edits (e.g. network thread adding to the queue while the processing thread is removing from the queue) yes, that can work quite well. The network is just a data transfer medium. You are right to want to keep it simple. Write data, read data, that's it.
The interesting part is what you do with that data inside the game.
Well, I'm locking the queues while I'm reading or writing to them. The current mechanism tries to;
Network thread --
Lock incoming queue and write to it, then unlock
Lock outgoing queue and send packages, then unlock
Game thread --
Lock outgoing thread and write to it, then unlock
Lock incoming queue and read from it, then unlock.
Just to minimize locking. Probably not perfect, but it works so far and I'm happy.
If any of you have any experience regarding entity-component-systems and how to integrate network to them easily while still keeping them flexible/extendable, the whole point of a entity-component-system, then please drop by in my other thread.
Looks good to me!
I have a full message/scheduling environment (called Flow) built around lazy type evaluation and the like a bit like AgentC describes in his answer to the other thread.
You can build one too if you like, no big deal to it. Also like that there is no distinction to networked or non-networked messages as all individual variables come with full type info (this means that yes bit compressed flags and small variables can take a lot of space - in which case you send a special binary field and compress them all into it) and if you as receiver cannot handle it you just don't. Simple. The approach of creating elaborate class hierarchies, special message container structures and the like is antiquated and quaint (in my opinion), but it is used by industry giants such as google, so it must be good for something :-)
: Restored post contents from history.