It looks like this implementation only works on the requestor side of the conversation -- that when we create / encode / write a header, it's presumed to be a request; when we read or decode a header, it's presumed to be a response. I would choose a side-agnostic design for a reference library to be used on both sides.
Also, presuming this runs over TCP or similar protocols, I would refrain from using the term `packet` in the code, as it is both jarring and misleading. TCP users are only concerned with streams -- packets themselves are handled by the TCP stack.
EDIT: to refer to a message implemented on top of the TCP stream, I would use the term message or frame
Good points. The code is indeed only intended to be used as a client.
I've mirrored the terminology used in the Memcached protocol specification, but now that you bring it up, it's true the word "packet" can be confusing.
It looks like this implementation only works on the requestor side of the conversation -- that when we create / encode / write a header, it's presumed to be a request; when we read or decode a header, it's presumed to be a response. I would choose a side-agnostic design for a reference library to be used on both sides.
Also, presuming this runs over TCP or similar protocols, I would refrain from using the term `packet` in the code, as it is both jarring and misleading. TCP users are only concerned with streams -- packets themselves are handled by the TCP stack.
EDIT: to refer to a message implemented on top of the TCP stream, I would use the term message or frame