I ran into an issue today where one of my coworker's clients managed to overflow the m_RawBuffer on IRCNetwork
His Textual client was configured to send an OPER command on connect, and so it did this every time he detached and reattached to the ZNC instance. This in turn sent back a RPL_YOUREOPER message each time, all of which were added to m_RawBuffer until it overflowed.
In this particular case, the RPL_WELCOME message overflowed, and Textual doesn't consider you to be connected until it gets it, so it would eventually time out the connection.
It seems like the best fix would be to only store one RPL_YOUREOPER message, but I'm not entirely sure what the right mechanism is to make that happen. (I'm happy to try and throw code together given some high-level direction)
I ran into an issue today where one of my coworker's clients managed to overflow the `m_RawBuffer` on `IRCNetwork`
His Textual client was configured to send an `OPER` command on connect, and so it did this every time he detached and reattached to the ZNC instance. This in turn sent back a `RPL_YOUREOPER` message each time, all of which were added to `m_RawBuffer` until it overflowed.
In this particular case, the `RPL_WELCOME` message overflowed, and Textual doesn't consider you to be connected until it gets it, so it would eventually time out the connection.
It seems like the best fix would be to only store one `RPL_YOUREOPER` message, but I'm not entirely sure what the right mechanism is to make that happen. (I'm happy to try and throw code together given some high-level direction)
<!-- github-sync-id:16502681 -->
999cc085d2 already removed this from the buffer. It's unreliable and clients should use the o mode. See full commit message for details.
999cc085d2906879bbe634ef3af472cde2d5a0d0 already removed this from the buffer. It's unreliable and clients should use the `o` mode. See full commit message for details.
<!-- github-comment-id:20663256 -->
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
I ran into an issue today where one of my coworker's clients managed to overflow the
m_RawBufferonIRCNetworkHis Textual client was configured to send an
OPERcommand on connect, and so it did this every time he detached and reattached to the ZNC instance. This in turn sent back aRPL_YOUREOPERmessage each time, all of which were added tom_RawBufferuntil it overflowed.In this particular case, the
RPL_WELCOMEmessage overflowed, and Textual doesn't consider you to be connected until it gets it, so it would eventually time out the connection.It seems like the best fix would be to only store one
RPL_YOUREOPERmessage, but I'm not entirely sure what the right mechanism is to make that happen. (I'm happy to try and throw code together given some high-level direction)999cc085d2already removed this from the buffer. It's unreliable and clients should use theomode. See full commit message for details.