To be able to use this codec on top of network protocols to communicate with untrusted clients, the codec layer should have the feature to be optionally able to discard a message (and returning an I/O error) if the buffered undecoded content is larger than a library-user specified size. This limit should be imposed not only on next (= recv), but on send too (althrough it should be non-fatal in that case, e.g. the underlying stream could be used to try to send another message); If next fails bc of a too big message, no further messages can be retrieved (althrough that depends on the encoding used. If the codec allows to skip-ahead to the beginning of the next message, the error would be non-fatal. the codec should have a method which returns a bool indicating if it supports reading messages after one message was to big.) But even if next fails and can no longer retrieve messages, send should be able to send further messages (e.g. to signal to the client that the connection is aborted because of a too big message).
To be able to use this codec on top of network protocols to communicate with untrusted clients, the codec layer should have the feature to be optionally able to discard a message (and returning an I/O error) if the buffered undecoded content is larger than a library-user specified size. This limit should be imposed not only on
next(= recv), but onsendtoo (althrough it should be non-fatal in that case, e.g. the underlying stream could be used to try to send another message); Ifnextfails bc of a too big message, no further messages can be retrieved (althrough that depends on the encoding used. If the codec allows to skip-ahead to the beginning of the next message, the error would be non-fatal. the codec should have a method which returns a bool indicating if it supports reading messages after one message was to big.) But even ifnextfails and can no longer retrieve messages,sendshould be able to send further messages (e.g. to signal to the client that the connection is aborted because of a too big message).