Don't print out extension message data if unrecognized.

Don't print out extension message data if unrecognized.

By design unrecognized extension messages should be silently dropped; printing them has the potential to adversely impact the reciever's performance, if unexpected messages are large.

Committed: https://crrev.com/87036997191865c6d90f997a46141de5dfaff11c
Cr-Commit-Position: refs/heads/master@{#293383}

[Wez, 2014-08-29 20:46:16]

wez@chromium.org changed reviewers:
+ sergeyu@chromium.org

[Sergey Ulanov, 2014-09-02 18:33:26]

Since host and client are supposed to exchange list of capabilities to discover
which extensions are supported on other end it shouldn't be expected that either
of them receives messages if unknown type. Maybe just log message type, but not
message content?

[Wez, 2014-09-02 19:00:04]

On 2014/09/02 18:33:26, Sergey Ulanov wrote:
> Since host and client are supposed to exchange list of capabilities to
discover
> which extensions are supported on other end it shouldn't be expected that
either
> of them receives messages if unknown type. Maybe just log message type, but
not
> message content?

It's not intended that there be that tight a coupling between capabilities and
extension messages; it'd be perfectly valid to send an extension message at
startup for some reason, regardless of whether the peer will ignore or respect
it, for example.

[Sergey Ulanov, 2014-09-03 01:06:23]

On 2014/09/02 19:00:04, Wez wrote:
> It's not intended that there be that tight a coupling between capabilities and
> extension messages; it'd be perfectly valid to send an extension message at
> startup for some reason, regardless of whether the peer will ignore or respect
> it, for example.

Can we at least log message type? You are trying to improve performance by not
logging these messages, but usually network bandwidth is more expensive resource
than logging, and sending ignored messages waste bandwidth and affects
performance even more than logging. This change makes it more likely that we
will be sending bogus extension messages without noticing them.

[Wez, 2014-09-03 01:13:03]

On 2014/09/03 01:06:23, Sergey Ulanov wrote:
> On 2014/09/02 19:00:04, Wez wrote:
> > It's not intended that there be that tight a coupling between capabilities
and
> > extension messages; it'd be perfectly valid to send an extension message at
> > startup for some reason, regardless of whether the peer will ignore or
respect
> > it, for example.
> 
> Can we at least log message type? You are trying to improve performance by not
> logging these messages, but usually network bandwidth is more expensive
resource
> than logging, and sending ignored messages waste bandwidth and affects
> performance even more than logging. This change makes it more likely that we
> will be sending bogus extension messages without noticing them.

We could log in debug builds, certainly; what we don't want is badly behaved
peers consuming resources on the other end of a connection.

[Wez, 2014-09-03 23:43:02]

PTAL

[Sergey Ulanov, 2014-09-04 00:02:01]

lgtm

[Wez, 2014-09-04 00:06:41]

The CQ bit was checked by wez@chromium.org

[commit-bot: I haz the power, 2014-09-04 00:09:38]

CQ is trying da patch. Follow status at
 https://chromium-status.appspot.com/cq/wez@chromium.org/524843002/40001

[Wez, 2014-09-04 00:11:55]

The CQ bit was checked by wez@chromium.org

[commit-bot: I haz the power, 2014-09-04 00:15:06]

CQ is trying da patch. Follow status at
 https://chromium-status.appspot.com/cq/wez@chromium.org/524843002/60001

[commit-bot: I haz the power, 2014-09-04 03:04:50]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2014-09-04 03:04:52]

Try jobs failed on following builders:
  android_clang_dbg_recipe on tryserver.chromium.linux
(http://build.chromium.org/p/tryserver.chromium.linux/builders/android_clang_d...)

[Wez, 2014-09-05 00:15:33]

The CQ bit was checked by wez@chromium.org

[commit-bot: I haz the power, 2014-09-05 00:21:27]

CQ is trying da patch. Follow status at
 https://chromium-status.appspot.com/cq/wez@chromium.org/524843002/60001

[commit-bot: I haz the power, 2014-09-05 00:54:59]

Committed patchset #4 (id:60001) as 99d45d8881b13e16e61586545842e6e0e814a1e8

[commit-bot: I haz the power, 2014-09-10 03:34:21]

Patchset 4 (id:??) landed as
https://crrev.com/87036997191865c6d90f997a46141de5dfaff11c
Cr-Commit-Position: refs/heads/master@{#293383}