Community


All times are UTC - 5 hours




Post new topic Reply to topic  [ 9 posts ] 
Author Message
 Post subject: Expected reconnect retry behaviour for nrclient
PostPosted: Tue Sep 27, 2016 8:48 pm 
Offline

Joined: Tue Sep 27, 2016 8:26 pm
Posts: 28
Using latest free server on centos 7 server on a VPS. Clients are (mostly) XP or Win 7 or 10 headless.

One of the things I don't like about Neorouter is that the retry or reconnect after a server is down isn't robust. If you manually hit "Cancel" (where it appears its trying to reconnect) and then connect manually, it works. So however it thinks or attempts to reconnect obviously do not work. If it gives up or stops retrying, it should be clear instead of appearing to be retrying over and over continuously (on a headless system, I NEVER want it to give up, so I'm hoping this will be fixed in the next release, whenever that may be).

2016-08-30 03:04:07 and the downtime lasted for 19 hrs, 38 mins.

After 4 weeks that the server has been back up, 7 clients reconnected on its own. I recall that 2-4 of them had reconnected within the first 12 hours of it coming back up, not sure about the others. These may have all reconnected after PC reboot (I have the run a script to make sure they login after booting up), not relying on nrclient doing it on its own.

I started using Neorouter 4+ years ago to get off of Hamachi paid service, but I've had to continue my Hamachi subscription because of this issue. With Hamachi, you could remove the network connection for days and weeks and within a few minutes of restoring network connectivity, it reconnects. I don't recall ever seeing Hamachi fail to reconnect in many years of using it (they generally run into other bugs, but that's another topic).

What is the expected behaviour for nrclient to retry connecting to the server?

Thanks

p.s. This post is being hassled for being spam despite the absence of the three examples it provided instead of indicating exactly what its cranky about.


Last edited by MaxBlitzer on Tue Sep 27, 2016 8:53 pm, edited 2 times in total.

Top
 Profile  
 
 Post subject: Re: Expected reconnect retry behaviour for nrclient
PostPosted: Tue Sep 27, 2016 8:49 pm 
Offline

Joined: Tue Sep 27, 2016 8:26 pm
Posts: 28
FYI, the forum thinks that using a single slash to indicate 'or' is SPAM. At minimum, that should be a check for double slash.

*shakes head*


Top
 Profile  
 
 Post subject: Re: Expected reconnect retry behaviour for nrclient
PostPosted: Mon Oct 24, 2016 7:22 pm 
Offline

Joined: Tue Sep 27, 2016 8:26 pm
Posts: 28
No response, at all? It would have been nice to get a fix for this into your update a few weeks ago.


Top
 Profile  
 
 Post subject: Re: Expected reconnect retry behaviour for nrclient
PostPosted: Fri Oct 28, 2016 3:00 pm 
Offline

Joined: Tue Feb 10, 2009 4:11 am
Posts: 96
it would have been nice that neorouter client can try to reconnect to its server when it loses connection. but since neorouter team did not answer this topic, you can have some other monitoring process to do the job for you.

on a linux system, I use monit to monitor nrtap interface, if it's down then restart nrservice:

Code:
# check if nrtap link is up
check network nrtap with interface nrtap
   start program = "/etc/init.d/nrservice.sh start" with timeout 60 seconds
   stop  program = "/etc/init.d/nrservice.sh stop"
   if failed link then restart


on a windows system, write a similar program to check neorouter IP, if it's down then restart neorouter client service.

I found that monit solved almost 99% issue on my headless linux systems. I don't have any windows headless system so I can always manually re-connect.


Top
 Profile  
 
 Post subject: Re: Expected reconnect retry behaviour for nrclient
PostPosted: Fri May 11, 2018 11:43 pm 
Offline

Joined: Wed May 14, 2014 1:06 pm
Posts: 5
When I add that setup to Monit I get :

● monit.service - LSB: service and resource monitoring daemon
Loaded: loaded (/etc/init.d/monit)
Active: failed (Result: exit-code) since Fri 2018-05-11 23:42:04 CDT; 15s ago
Process: 3160 ExecStop=/etc/init.d/monit stop (code=exited, status=0/SUCCESS)
Process: 3166 ExecStart=/etc/init.d/monit start (code=exited, status=1/FAILURE)

May 11 23:42:04 raspberrypioffice monit[3166]: Starting daemon monitor: monit/etc/monit/monitrc:150: syntax error 'nrtap'
May 11 23:42:04 raspberrypioffice monit[3166]: failed!
May 11 23:42:04 raspberrypioffice systemd[1]: monit.service: control process exited, code=exited status=1
May 11 23:42:04 raspberrypioffice systemd[1]: Failed to start LSB: service and resource monitoring daemon.
May 11 23:42:04 raspberrypioffice systemd[1]: Unit monit.service entered failed state.

Any ideas ?


Top
 Profile  
 
 Post subject: Re: Expected reconnect retry behaviour for nrclient
PostPosted: Fri Jun 29, 2018 1:52 am 
Offline

Joined: Fri Jun 29, 2018 1:29 am
Posts: 1
I think reconnect retry behaviour is must. So one should go with that

_________________
Best Assignment Help in uk.


Top
 Profile  
 
 Post subject: Re: Expected reconnect retry behaviour for nrclient
PostPosted: Fri Jul 06, 2018 6:17 am 
Offline

Joined: Fri Jul 06, 2018 5:13 am
Posts: 1
+1 for reconnect behaviour in clients. I'm surprised they don't already do it!

Recently shutdown our NeoRouter server for some maintenance and started it after about an hour, and clients won't come back online! For us it's now very difficult as they are remote clients and we don't have physical access to the machines.

.........
Opened a ticket about this with Support. Will update once I know more.


Top
 Profile  
 
 Post subject: Re: Expected reconnect retry behaviour for nrclient
PostPosted: Fri Jul 06, 2018 7:08 am 
Offline

Joined: Tue Sep 27, 2016 8:26 pm
Posts: 28
avnir wrote:
+1 for reconnect behaviour in clients. I'm surprised they don't already do it!

Recently shutdown our NeoRouter server for some maintenance and started it after about an hour, and clients won't come back online! For us it's now very difficult as they are remote clients and we don't have physical access to the machines.

.........
Opened a ticket about this with Support. Will update once I know more.


They'll eventually come back on their own. I'm mostly disappointed that there was no comment on the currently designed behaviour so we know what to expect (1 hour? 12 hours? 24 hours?).

But I'm getting the impression NeoRouter development has seized. I'm just a free user so I can't complain too much, but it's pretty clear with 3+ years no development on linux free product. Linux free server is still using SSLv3 despite the change log saying it was fixed, which I would have thought would have triggered an immediate release fix, but 3 years later, reality says no.


Top
 Profile  
 
 Post subject: Re: Expected reconnect retry behaviour for nrclient
PostPosted: Thu Aug 02, 2018 1:44 am 
Offline

Joined: Thu Aug 02, 2018 1:42 am
Posts: 1
My expertise with QuickFixJ initiator aspect session reconnection is that the repair session reconnect logic is depend upon the availability of TCP connection. Because the TCP will not be on hand in your case, repair session reconnect will not hearth. There is a history thread looking to reestablish the TCP.  It you plug your community back, the session reconnect shall happen.

_________________
Fmovie


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 9 posts ] 

All times are UTC - 5 hours


Who is online

Users browsing this forum: No registered users and 2 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron