WebSocketSharp unit test failure due to StackOverflow #91
Comments
|
System.Net.Sockets.NetworkStream.BeginRead can sometimes call a callback in the same thread in which it was called. I came across something similar in Socket.BeginRead when switching from .Net Framework to .net. It seems that in .net, the probability of calling a callback in the same thread is much higher due to some optimizations. It was decided to call a task in the callback that performs processing if the callback call was synchronous. |
Hmm, interesting... But I don't see why it should overflow unless the callback starts stream.BeginRead again from the same stream.Position. The same stream.Position means that read bytes count = 0, which indicates the end of the stream, so the process should stop. Looks like bug in application code. Am I missing something? |
|
I forgot to clarify, stack overflow occurred if there was data in the buffer at the time of each callback call and if the BeginRead call occurred in a callback that was passed to BeginRead. Apparently, some condition for exiting recursion is not met in the websockets. I also think that this is a bug in the websocket. Whether it will be fixed is unknown. It looks like there are now two potential stable channel implementations left - quick and httplistener-based websocket. |
|
@yallie I can confirm that I have experienced the @sancheolz Did you manage to workaround the recursion issue in your code? In that case, I would be very interested to get some tips :-) |
@anders9ustafsson, please try updating to the latest version of CoreRemoting. |
@sancheolz, I'm currently using Fleck library in one of my projects. A few years ago I was evaluating Fleck and websocket-sharp and found that Chromium browsers Also, there is WebSocket4Net, based on SuperSocket library, but I haven't tried it. |
|
@anders9ustafsson you need to check property IAsyncResult.CompletedSynchronously. IAsyncResult is passed to callback wich passed to BeginRead. If CompletedSynchronously returns true then you neen run receive logic in Task.Run, else run it as is. @yallie thanks for the information. I really want to try out a new implementation of the channel on websocket when I find some time. I think I'll focus on it. |
@sancheolz Please keep in mind the channel is still beta. I'm not sure I've done everything right — it just passes the unit tests, nothing more. |
|
Thanks for the info @yallie , I think it is a great step in the right direction to make use of the .NET internal support for WebSockets. I did try it with my application, but for some reason failed to establish contact between the client and the server. Not sure why, I will investigaste further. And thanks @sancheolz for the info. I have tried to make use of |
I knew it shouldn't be that easy! :-/ — What platform are you using, Windows, Linux? My best guess is a problem with HTTP.sys driver permissions. Localhost connections don't require any configuration, that's why the unit tests run without any issues. But accepting connections from other machines requires administrator privileges and setting up namespace reservations with netsh: Configuring HTTP and HTTPS... |
|
@yallie I am running on Windows 11, client and server on same machine. I have tested with and without message encryption in case that would play a role, but no difference. I am using .NET binary formatter serialization, but that shouldn't matter either, right? |
That's weird...
No, it shouldn't matter. Have you tried running CoreRemoting unit tests on your machine? But do they work for your setup? If they do, please try to spot the difference |
|
Unit tests succeed. I will investigate more thoroughly to identify the root cause of the failing communication in my application, I'll get back to you as soon as I have more information. |
|
@yallie Here is what I have found so far. My server was invoked with Ideally though, it should not matter if the host name differs in the server and client invocation, as long as the same machine is referenced. I am still having problems with the handshake; the server has issued the handshake but the client is not able to recognize it. I'll continue my investigation. BTW, looking at the |
Yes, I think it shouldn't matter, too.
I tend to use ConfigureAwait(false) every time I remember about using it. And as I said, I'm not sure I've done everything right — the code just passes the unit tests, and that's it. |
Hmm, apparently I was using it wrong... UPD. Removed ConfigureAwait from the sync GetResult calls. |
|
@anders9ustafsson new websocket channel is based on HttpListener. And if you set Hostname to "+" it will listen at all network interfaces(loop, eth0 and other) and it's addresses.With Hostname set to "localhost" it listens loop interface only. |
|
@yallie I've tried the latest revision at this moment. RemotingClient.Connect() freezes in it. |
Too bad! Could you please make a unit test demonstrating the issue? |
Describe the bug
WebSocketSharp channel unit tests occasionally fail due to stack overflows (quite rare actually).
To Reproduce
Run WebSocketSharp unit tests until they fail. Not guaranteed!
Expected behavior
The unit tests should not produce stack overflow.
Additional notes
PS. Disabled WebSocketSharp tests for now (this channel is going to be superseded by new HttpListener-based websocket channel) — see commit f8abb35.
The text was updated successfully, but these errors were encountered: