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.
2 comments
[ 2.9 ms ] story [ 13.9 ms ] threadIt 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