Mac -> MSSQL disconnect/timeout

Ben Butler ben.butler at
Thu May 15 20:07:09 EDT 2008


If the below is the cause and either the NAT translation is timing out
(Xlate) and then not being restablished to the same server socket as a
persistent connection - anyway - for interest - these are the defaults
in a Cisco PIX:

timeout xlate 0:05:00
timeout conn 1:00:00 half-closed 0:10:00 udp 0:02:00 rpc 0:10:00 h225
timeout h323 0:05:00 mgcp 0:05:00 sip 0:30:00 sip_media 0:02:00
timeout uauth 0:05:00 absolute

Xlate is NAT, others of interest would be conn.

I would be surprised if all firewalls don't timeout idle connections
after a certain period to avoid socket exhaustion - as I understand it /
believe - any which are based on some flavour of Unix / Linux kernel a
network socket is a sort of file and there is a limit in the maximum
number of open file handles and hence sockets that the kernel supports -
I believe the default is ~65K so that means max this number of sockets
unless the kernel parameters have been fiddled with.

As many routers and firewalls on the market are infact flavours of their
"IOS" running on top of a Linux core kernel (again I believe this is
true but happy to be told I am wrong) - then all these boxes have this
same potential limit and consequently will all have idle timeouts for
connections to prevent exhaustion occurring over time - particularly
with things like syn attacks that half open connections and many other
port scans which I so common and frequent it is hardly worth logging
them to a syslog server because you collect a mountain sized Mauna Loa
collection of data requiring disk storage for all 9,700 cubic miles of

My point is if your problem relates to timeouts on something requiring a
persistent connection you might be better exploring the possibility of
firing keep alive packets, or keep alive queries to nail the connection
open.  In 4.3 the MySQL DAMs have a $ping() method although executing
anything: select * from 1; just to send some traffic should have the
desired effect - and you could put this on a $timer method.  This
potentially represents a neater and tuneable solution to get round any
customer specific hardware.

Just my thoughts for this morning.

Btw for those that are interested in my 9700 miles3:

Kind Regards


-----Original Message-----
From: omnisdev-en-bounces at
[mailto:omnisdev-en-bounces at] On Behalf Of Reg Paling
Sent: 16 May 2008 00:40
To: OmnisDev List - English
Subject: Re: Mac -> MSSQL disconnect/timeout

Hi Rob,
> I have deployed my Studio 4.2 app on both Win and Mac.  They are both 
> hitting against a common MSSQL database server.  On Windows I am using

> the built in drivers and everything is working fine.  On Mac (OSX
> 10.4) I am connecting through Actual's drivers, and it's working great

> except when the app is idle for a while, maybe 15-30 minutes.  If that

> happens, it appears that it has disconnected from the database and you

> get the spinning wheel.
I've had similar problems, caused by the firewall/modem/router dropping
the connection.  When you first connect, the router sets up an entry for
port 1433 in its temporary routing tables and as long as there is
activity the entry stays alive. But eventually the firmware logic
decides to time out.  All the little low-cost appliance routers have
different firmware in them and they all do their thing with varying
levels of obscurity!  Most of them don't allow you to set the timeout
parameters.  Sounds like this setup may well have a different type of
router at each point?

So my guess is that this is the cause and the apparent difference
between Mac & Windows is just a coincidence.  I'd suggest you find a
cheap model that works and replace the ones at the non-working sites
with the same model.

Manage your list subscriptions at

More information about the omnisdev-en mailing list