NeoRouter
http://www.neorouter.com/forum/

Expected reconnect retry behaviour for nrclient
http://www.neorouter.com/forum/viewtopic.php?f=3&t=5987
Page 1 of 2

Author:  MaxBlitzer [ Tue Sep 27, 2016 8:48 pm ]
Post subject:  Expected reconnect retry behaviour for nrclient

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.

Author:  MaxBlitzer [ Tue Sep 27, 2016 8:49 pm ]
Post subject:  Re: Expected reconnect retry behaviour for nrclient

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*

Author:  MaxBlitzer [ Mon Oct 24, 2016 7:22 pm ]
Post subject:  Re: Expected reconnect retry behaviour for nrclient

No response, at all? It would have been nice to get a fix for this into your update a few weeks ago.

Author:  ElTopo [ Fri Oct 28, 2016 3:00 pm ]
Post subject:  Re: Expected reconnect retry behaviour for nrclient

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.

Author:  carlosarze [ Fri May 11, 2018 11:43 pm ]
Post subject:  Re: Expected reconnect retry behaviour for nrclient

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 ?

Author:  smithassignment1 [ Fri Jun 29, 2018 1:52 am ]
Post subject:  Re: Expected reconnect retry behaviour for nrclient

I think reconnect retry behaviour is must. So one should go with that

Author:  avnir [ Fri Jul 06, 2018 6:17 am ]
Post subject:  Re: Expected reconnect retry behaviour for nrclient

+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.

Author:  MaxBlitzer [ Fri Jul 06, 2018 7:08 am ]
Post subject:  Re: Expected reconnect retry behaviour for nrclient

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.

Author:  mksharma [ Thu Aug 02, 2018 1:44 am ]
Post subject:  Re: Expected reconnect retry behaviour for nrclient

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.

Author:  andrewtiwsan [ Thu Jan 17, 2019 4:46 am ]
Post subject:  Re: Expected reconnect retry behaviour for nrclient

Very interesting post. I had a similar problem at work, I will try to solve it.

Page 1 of 2 All times are UTC - 5 hours
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
http://www.phpbb.com/