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

A Task was cancelled #84

Open
rizwan1239 opened this issue Feb 21, 2022 · 7 comments
Open

A Task was cancelled #84

rizwan1239 opened this issue Feb 21, 2022 · 7 comments
Labels
requires feedback Ticket author needs to provide further infos requires investigation Information needs to be collected in first place

Comments

@rizwan1239
Copy link

Hi. The server randomly throws this exception anytime. The last time I found it was when no client was connected. What should be done?

image

@Toemsel
Copy link
Owner

Toemsel commented Feb 21, 2022

Stop trying to send packets over a dead connection.

@rizwan1239
Copy link
Author

Stop trying to send packets over a dead connection.

Doesn't it automatically stop on calling connection.Close() on both sides?

@Toemsel
Copy link
Owner

Toemsel commented Feb 21, 2022

It closes, but packets in the send-queue still try to make it through. The lib embraces a pretty slim state machine: ONLINE, OFFLINE. That's it. Everything before and after has to be considered in your code.

In your case, I assume the connection dies while sending a paket. (e.g. the sent packet is faulty)

If you think this behavior isn't intended or even a bug, please set up a small example project for further analysis.

@Toemsel Toemsel added the requires feedback Ticket author needs to provide further infos label Feb 21, 2022
@rizwan1239
Copy link
Author

rizwan1239 commented Feb 21, 2022

It closes, but packets in the send-queue still try to make it through. The lib embraces a pretty slim state machine: ONLINE, OFFLINE. That's it. Everything before and after has to be considered in your code.

In your case, I assume the connection dies while sending a paket. (e.g. the sent packet is faulty)

If you think this behavior isn't intended or even a bug, please set up a small example project for further analysis.

Yeah, technically connection dies when the server is sending client a packet because connection might have closed on client side. Possibly comes from this part of code.
image

I use it to check if the client is still available on the network. If an exception happens, I quickly close the connection. Do you think there still should be an issue?

@Toemsel
Copy link
Owner

Toemsel commented Feb 21, 2022

I see. You might want to check whether the connection is still alive before you call connection.Close()
Moreover, there is no need to perform pings manually. That is already a part of the lib itself. (It checks when the client/server is not reachable anymore) All you have todo is to subscribe to an event: connection.ConnectionClosed

You can configure the TIMEOUT (default 2.5 sec) or disable the pinging completely.

@rizwan1239
Copy link
Author

Are you talking about connection.SendPing()? It's probably not awaited call and doesn't have a response either. So will it cause an exception in try catch for detection of ping fail?

And yes I already have subscribed to the ConnectionClosed event.
image

The initial exception randomly happened long after server was left without any clients. I tried to regenerate the exception by leaving it with 0 clients. Also tried to rapidly connect and disconnect connections but couldn't generate it. It randomly happens and sadly ends up crashing the application since its self contained build.

@Toemsel
Copy link
Owner

Toemsel commented Feb 21, 2022

Strange. I have to test this case on my machine. So, in order to reproduce the issue, one has to:

  1. Connect a client
  2. Disconnect the client (force or via .close())
  3. Server experiences exception

// flaggy issue - doesn't occur all the time

@Toemsel Toemsel added the requires investigation Information needs to be collected in first place label Feb 21, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
requires feedback Ticket author needs to provide further infos requires investigation Information needs to be collected in first place
Projects
None yet
Development

No branches or pull requests

2 participants