Open michaelmeling opened 2 years ago
does not work with connection that starts with wss://
My bad, had cast _stream to NetworkStream, instead of just Stream, so SslStream failed.
With your fork Close( any args ) - server part, is not working.
@conspiracynomad Should be fixed
Now other issue, sometimes httpclient timeout happens
Does this happen when you call Close(), or is it unrelated?
On Thu, 15 Dec 2022 at 10:13, conspiracynomad @.***> wrote:
Now other issue happens, sometimes http timeout happens
— Reply to this email directly, view it on GitHub https://github.com/sta/websocket-sharp/pull/703#issuecomment-1352762734, or unsubscribe https://github.com/notifications/unsubscribe-auth/AQDV75HNOX73BDWOAJSIY23WNLOMXANCNFSM55IOHZEA . You are receiving this because you authored the thread.Message ID: @.***>
from stacktrace it's related to httpclient with SendAsync
Does this happen when you call Close(), or is it unrelated? … On Thu, 15 Dec 2022 at 10:13, conspiracynomad @.> wrote: Now other issue happens, sometimes http timeout happens — Reply to this email directly, view it on GitHub <#703 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AQDV75HNOX73BDWOAJSIY23WNLOMXANCNFSM55IOHZEA . You are receiving this because you authored the thread.Message ID: @.>
Also, yeah, issue with close not fully fixed, sometimes user connection not closes.
I don't think any of the code related to SendAsync or the sending functionality was modified in this PR. Do you have any sample code to reproduce this issue?
Is this issue reproducible on .NET 5 (or previous) using the normal websocket-sharp library without this PR?
Does this happen when you call Close(), or is it unrelated? … On Thu, 15 Dec 2022 at 10:13, conspiracynomad @.> wrote: Now other issue happens, sometimes http timeout happens — Reply to this email directly, view it on GitHub <#703 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AQDV75HNOX73BDWOAJSIY23WNLOMXANCNFSM55IOHZEA . You are receiving this because you authored the thread.Message ID: @.>
Apparently this happens because the connection does not have a timeout, try, for example, to connect from the client to the server, then let's say turn on the VPN, or turn off the Internet so that your connection breaks down, the bottom line is that the connection will remain "alive" after that
Using StreamThreads library to flatten the recursion in receive. The flattened code has been put into StreamThreader.cs
Referencing issue #702
A fork has been created for a NET 6.0 build at https://github.com/michaelmeling/websocket-sharp
The StreamThreads library can be found at https://github.com/michaelmeling/StreamThreads