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

Large messages issue #47

darkl opened this issue Dec 31, 2015 · 3 comments


Copy link

@darkl darkl commented Dec 31, 2015


I've been told that WampSharp has issues with the vtrotola WebSocketListener transport and large messages.

After investigating this, this seems to be an issue that looks like a race condition in WebSocketListener. I'm attaching some code that reproduces this. Note that not every run results with an exception, so it seems this is really some kind of race condition.

See the code here. You need to install vtortola.WebSocketListener, WebSocket4Net and Newtonsoft.Json. The application should crash at some point with this exception:

An unhandled exception of type 'Newtonsoft.Json.JsonReaderException' occurred in Newtonsoft.Json.dll

Additional information: Unterminated string. Expected delimiter: ". Path '[31].tags[0]', line 1, position 32776.

Investigating the received message, we see a substring of the sent JSON ending with this suffix "i��y2���".

You might suspect that this may be a problem related to WebSocket4Net, but it works fine with other WebSocket libraries such as Fleck.

Any help is appreciated,



This comment has been minimized.

Copy link

@vtortola vtortola commented Dec 31, 2015

I will take a look in the next few days.

The default value for the ping interval is 5 seconds, could you try to disable the ping setting Timeout.InfiniteTimespan and try again? I maybe the problem is because WSL is sending a ping frame interpolated with data frames if the data is very large (totally legal according to the specification).

Thanks for taking time in making the reproducible case and reporting it 👍

@darkl darkl referenced this issue Jan 1, 2016

This comment has been minimized.

Copy link

@darkl darkl commented Jan 1, 2016

Thanks @vtortola, it turns out to be an issue with the WebSocket4Net library not treating injected control frames in the middle of a fragmented message as specified in the protocol. Thanks for leading me to the right direction. 👍

@darkl darkl closed this Jan 1, 2016

This comment has been minimized.

Copy link

@vtortola vtortola commented Jan 2, 2016

No problem :) I just saw your pull request to WebSocket4Net, nice 👍

Playing with your example code I also found that ClientWebSocket (the default .NET 4.5 client) eventually crashes when sending frames bigger than exactly 16376 with PING/PONG enabled.

This will work:

 Task.Run(async () =>
     var writeBuffer = new ArraySegment<byte>(Encoding.UTF8.GetBytes(String.Join("", Enumerable.Range(0, 16376).Select(i => "a"))));
     while (!_cancel.IsCancellationRequested)
         await ws.SendAsync(writeBuffer, System.Net.WebSockets.WebSocketMessageType.Text, true, CancellationToken.None);
         await Task.Delay(10).ConfigureAwait(false);

Now changing the length of the payload from 16376 to 16377 and it will fail in a couple of seconds. I can see a frame with the right length but containing bytes that are not the letter 'a' (97) is being received. Scary.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
2 participants
You can’t perform that action at this time.