You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In WebSocketClient.cs, on line 150, the bytes are sent to the socket in a try {} catch () {} statement and for now simply re-throws a new exception to the client of the library with the original exception as inner exception. However, it shouldn't be the responsibility of the user to wrap the call to Cli.SendFrames() in a try {} catch () {} statement.
The reason SendFrames() is a part of the WebSocketClient class and not the WebSocketServer class is that sometimes, other internal classes may need to send control frames but only have a reference to the client object and not the server. Also, I think it makes more sense from a semantic standpoint.
To go around this, a 'proxy' method could be implemented in the WebSocketServer class that would receive a cli and a frame as arguments. It would then call the cli.SendFrame() method in a try {} catch () {} statement. When catching an error, the WebSocketServer will be responsible for executing any logic to remove the client from the active sockets and raise an OnError event so the client is notified of the exception and that the client for which it occured is no longer active
The text was updated successfully, but these errors were encountered:
In WebSocketClient.cs, on line 150, the bytes are sent to the socket in a
try {} catch () {}
statement and for now simply re-throws a new exception to the client of the library with the original exception as inner exception. However, it shouldn't be the responsibility of the user to wrap the call toCli.SendFrames()
in atry {} catch () {}
statement.The reason
SendFrames()
is a part of theWebSocketClient
class and not theWebSocketServer
class is that sometimes, other internal classes may need to send control frames but only have a reference to the client object and not the server. Also, I think it makes more sense from a semantic standpoint.To go around this, a 'proxy' method could be implemented in the
WebSocketServer
class that would receive a cli and a frame as arguments. It would then call thecli.SendFrame()
method in atry {} catch () {}
statement. When catching an error, theWebSocketServer
will be responsible for executing any logic to remove the client from the active sockets and raise anOnError
event so the client is notified of the exception and that the client for which it occured is no longer activeThe text was updated successfully, but these errors were encountered: