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

Can't restart connection after disconnect #71

Closed
alexruden opened this issue Aug 7, 2019 · 12 comments
Closed

Can't restart connection after disconnect #71

alexruden opened this issue Aug 7, 2019 · 12 comments

Comments

@alexruden
Copy link

Connection was stopped after internet disappeared (or any another reason). I want to restore connection by command connection.start, but get fail "Starting connection failed - invalid state". That means that connection can't started because it's current state is 'stopped', not 'initial'. (func start() in HttpConnection.swift). Also I can't get current state (if now is not in 'connected') to force stop and start connection.
I think need change logic to like:
if changeState(from: .initial || .stopped, to: .connecting) == nil {
And would be good to make public state of connection. Thank you.

@moozzyk
Copy link
Owner

moozzyk commented Aug 7, 2019

This is currently by design. Once the connection is stopped it cannot be started. Currently, you will have to create a new connection each time you want to connect to the server. Having said that, I admit that doing this and getting it right is challenging. I started thinking on making the connection re-usable/restartable but it is actually more challenging than changing the condition you pointed to.

And would be good to make public state of connection.

What are the scenarios you need it for?

@blavkjay
Copy link

@moozzyk i am implementing a chat application with your library. Beautiful job you have done i must say but the only challenge i am having is because the connection times out and i have to reopen it everytime...I just put my methods in the viewWillAppear()...but then it is bad userExperience meaning it has to reload all the messages and conversation again anytime a user leaves the messaging tab.

@moozzyk
Copy link
Owner

moozzyk commented Aug 17, 2019

@blavkjay - I think you are discussing a few issues hereL

it has to reload all the messages and conversation again anytime a user leaves the messaging tab.

I have an impression that the connection is being closed because it goes out of scope and is being deinitialized. Make sure you keep a reference to your HubConnection instance for the entire time you expect the connection to the server be open. If you for instance create a HubConnection instance in a function and will not keep the reference as a class variable as soon as you leave the method the local variable will go out of scope and the connection will be closed. The same would happen if the hub connection reference is a class variable but the instance of the class that keeps a reference to the hub connection instance is deinitialized. In your case it feels that you keep the reference to the hub connection on the messaging tab and if the user is leaving the messaging tab it is being cleaned up resulting in deinitializing the hub connection instance and therefore breaking the connection to the server.

the connection times out

In general this should not happen. The underlying connection is using webSockets and the webSocket protocol by default tries to ensure that the connection stays alive. If you see frequent time outs (not really sure what it means - is this disconnects?) the problem can be on the client or on the server. I would recommend turning on logging at the debug level on the client to see what error you get.
You may also want to check if this is not the server that is terminating the connection.

@Narek1994
Copy link

Hi @moozzyk , thanks for this beautiful library.
I just wanted to know if this is fixed or not yet, because I am getting same behavior, after logout in my app, I am stopping the connection, and after login start it, but getting this error
020-01-18T05:58:59.828Z debug: Attempting to chage state from: 'initial' to: 'connecting'
2020-01-18T05:58:59.828Z debug: Changing state to: 'connecting' failed
2020-01-18T05:58:59.828Z error: Starting connection failed - invalid state
2020-01-18T05:58:59.828Z debug: Invoking connectionDidFailToOpen
if I create new HubConnection each time before start(), everything works, is this normal solution to keep in app?
Thanks.

@moozzyk
Copy link
Owner

moozzyk commented Jan 18, 2020

Currently the connection is not reusable - you need to create one before starting. Normally it is not a big issue. It gets however tricky when trying to handle error cases where you would like to try to reconnect to the server after connection was lot. I have started working on a reconnectable connection in this branch: https://github.com/moozzyk/SignalR-Client-Swift/tree/reconnect but it is not yet ready. When it's ready it should also make it possible to restart connections.

@Narek1994
Copy link

Narek1994 commented Jan 18, 2020

ok Thanks, so in case you have described(lost connection) will I get notification in any of this methods?
func connectionDidClose(error: Error?)
func connectionDidFailToOpen(error: Error)
if yes, I think I can stop and invalidate the hub, create new one and start new connection, what do you think?

@Narek1994
Copy link

Narek1994 commented Jan 18, 2020

I just faced a problem, when I am stopping and starting connection 10 times in a small period of time app freezes( for example when app moves to background and moves back to foreground), can you suggest anything related to this?
Thanks in advance

UPD 1
Problem is with
self.startDispatchGroup.wait(), if I got it correct, when I am stopping and moving app to background and quickly reopen it, doing this few times, self.startDispatchGroup.wait() just freezes UI and endlessly waits and leave() doesn't invoke in any situation.
What if I comment this line self.startDispatchGroup.wait(), should we really need anything to be finished to be able to close the connection?

UPD 2
If I got it correct, problem is if during negotiation request we move app to background because it doesn't use URLSessionConfiguration.background, so we don't get result and it never leaves DispatchGroup.

@moozzyk
Copy link
Owner

moozzyk commented Jan 18, 2020

Thanks for the update! This is a good find - I have not seen it but I am glad it was found before I merged it back to master. I opened a separate issue to track this #86. Could you turn on logging at the debug level and attach logs to the issue I created?

@moozzyk
Copy link
Owner

moozzyk commented Feb 19, 2020

@apphardtask - if this is in a function then when function completes its execution the hubConnection variable will go out of scope and the object it references will be destroyed. You need to keep the reference to the hub connection.

@moozzyk
Copy link
Owner

moozzyk commented Mar 15, 2020

I believe the original question was answered. The reconnect issue is being tracked as #86 and I think it should be resolved now.

@moozzyk moozzyk closed this as completed Mar 15, 2020
@abhidaasari
Copy link

abhidaasari commented Feb 2, 2024

@moozzyk , I have implemented "https://github.com/AutosoftDMS/SignalR-Swift" this in our project , but what is the difference between yours library and AutosoftDMS/SignalR-swift, and the issue is with this library is we are unable to get the call back whether the connection is closed or disconnected, because of that we cant start a new connection due to this request time out happening,

and also we are unable to implement your library into our project because you have not provided full code on this, please write a entire class to implement your library and reconnection logic .
thanks

@moozzyk
Copy link
Owner

moozzyk commented Feb 4, 2024

I am not too familiar with AutosoftDMS/SignalR-swift but at first glance, it is meant for the old (non-ASP.Net Core) of SignalR. This client works with the ASP.Net Core version of SignalR.

I don't believe there is any significant functionality missing in this implementation.

Please do not comment on unrelated and closed issues but open a new issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants