Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[enhancement] Getting e.RawData still decodes byte array to string internally #758

Open
vritme opened this issue Sep 18, 2024 · 0 comments

Comments

@vritme
Copy link

vritme commented Sep 18, 2024

In this file: https://github.com/sta/websocket-sharp/blob/master/websocket-sharp/MessageEventArgs.cs

public byte[] RawData {
  get {
    setData ();

    return _rawData;
  }
}

e.RawData property of websocket message event calls the same setData() method, which is used for e.Data property:

public string Data {
  get {
    setData ();

    return _data;
  }
}

And setData() method, when called for the first time for a given event object and if opcode is not Binary (I guess this means technical for the purposes of websocket protocol), unconditionally tries to decode byte array to string via TryGetUTF8DecodedString() method in order to prepare string _data field for e.Data property to use (even if called from e.DataRaw, where byte array to string decoding is not needed):

private void setData ()
{
  if (_dataSet)
    return;

  if (_opcode == Opcode.Binary) {
    _dataSet = true;

    return;
  }

  string data;

  if (_rawData.TryGetUTF8DecodedString (out data))
    _data = data;

  _dataSet = true;
}

Calling _rawData.TryGetUTF8DecodedString on e.RawData property call prior to returning just _rawData byte array breaks the point of using e.RawData property for the purpose of message processing speedup via avoiding string allocation and byte array to string conversion.

I suppose the e.RawData property should be reworked like this:

public byte[] RawData {
  get {
    return _rawData;
  }
}
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant