Disconnect clients in case of inappropriate protocol #256
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Currently we have a problem when publishing a binary message and having JSON-protocol connection – publications to channel do not work (return an error) in case of Memory engine (since broadcast is synchronous at the moment). In case of Redis engine there is a chance that only some connections will receive the data until we hit an encoding error (in Redis Engine case broadcast is asynchronous upon reading from PUB/SUB).
This is due to the fact that we can't serialize binary to JSON – so broadcasting obviously returns an error. That's usually a programmer error, all connections should be Protobuf-based to properly work with binary. But this can also happen occasionally during migration from JSON to binary formats. So users come across weird behaviour here which can not be fixed easily (as clients continue reconnecting).
Here we are disconnecting clients which can not handle binary payload with
3506: inappropriate protocolDisconnectinstead of returning an error on publish. So valid connections will work, invalid connections will be disconnected.Problem like this should usually be detected on development stage. We also log about suc AB27 h cases on WARN level (with the first observed client ID and user ID).
We also disconnect in cases when we can not serialize Reply or Unidirectional Push for single
Client.Probably this may be addressed in some alternative form – though do not have any good ideas at the moment.