1 of 1 people found this helpful
Sounds very frustrating!
Just want to check that you are connecting through FileMaker's Open Remote... dialog, and not via file sharing.
I finally resolved the issue. We had two issues. The first was a faulty switch that connectd two windows computers to the main network. Neither of these two computers runs filemaker so it was thought that could not be the problem and the switch was set to bridge mode anyway. It seems for some reason that switch was causing a "double NAT". The second issue was a faulty Airport Extreme Base station. It is just two years old. We replaced to router and the switch and everything is now working as it should.
It seems FMS 13 is less tolerant of network interuptions than FMS 12, as in retrospect these problems had been occurring for a couple of months. We put it down to the flaky server which is why we replaced it with the Mac Mini.
Thank you for your input and concern.
I had some posts on this forum and FMExperts in March and April re: FMS 13 and MacMinis. Tried 2 of them (apple swapped them out for us). We has totally reproduceable issues with client disconnects - the deploy is 4 sites with 3 of them remote. Clients connect in the morning and periodically use the system. A 2012 iMac and a 2014 MacPro in EXACTLY the same physical space work without any disconnects. Filemaker case filed. Apple cases filed. Have spoken with FileMaker staff at Devcon 2014. They have "heard reports" about "packet sensitivity"
"When you are courting a nice girl an hour seems like a second. When you sit on a red-hot cinder a second seems like an hour. That's relativity." - Albert Einstein
Even if the exact implications of these can be difficult to determine, don't forget that a different OS can change the network behaviors with its network stack settings, although FMS almost certainly uses its own values for some of these. On OSX we can see these values with the sysctl command, eg:
$ sysctl net.inet.tcp net.inet.tcp.rfc1323: 1 net.inet.tcp.rfc1644: 0 net.inet.tcp.mssdflt: 512 net.inet.tcp.keepidle: 7200000 net.inet.tcp.keepintvl: 75000 ...
I have been unable to do any more on this for a while. I will be able to get back to it next week. At the moment it seems that the local connections are fine but remote connections do not stay connected.
Will keep you posted on my results.