At 12:42 PM 17/12/2005 +0100, John vd Waeter wrote:

>Yes, but it was Jason on the IBO-list that told me this is not an
>IBO-issue but an issue of the clientlibrary...

Not quite: he said: "I'm not aware of any facility via the API to
accomplish this.
This is a Firebird question essentially."

Given that Jason's concern is the API, I suppose he was right, strictly
speaking, insofar as it wasn't an IBO issue.

>Therefore I thought this
>might be the correct maillist... correct me if I'm wrong...

Not wrong: we try to give some help with network problems here, as far as
we can. But you need to understand that Firebird runs over the top of the
OS and network layers. The OS and the network are expected to work. The
API can respond in a fairly blunt way if it gets an outright refusal from
the network. The software isn't designed to run in two tiers on a
Kbit-speed network: even 10 Mb in a LAN is almost too slow for 2-tier.

>But is it really the applications responsibility? The app uses the lib
>and it's the lib that is connecting sockets and its the sockets that hit
>the wire etc...

Nope. It uses TCP/IP (or other protocols) as a transport and it gains
access to sockets via requests to the transport's interface - winsock2 in
the case of Windows. It has no way to tell there's a deficiency in the
transport unless the NOS sends it a message. As long as the NOS is waiting
for packets, the socket request is alive.

>Somewhere in this chain I think there should be a
>possibility to monitor the quality of the connection and to ring a bell
>when quality drops below a certain level.

There is: it's called ping.

>The sockets see no trouble, as they don't timeout as long as single
>packets arrive within their time-out period. And the application relies
>on the lib.

And the lib relies on the NOS. The application relies on the application
developer to cover the bases. The application developer relies on the ISP
to provide sufficient service and on the site user to configure network
servers and clients appropriately to that service. It's also the
application developer's job to warn the site user that trying to use his
2-tier system across a telephone network is not covered by the reality clause.

>I don't think its good programming bypassing the lib to the sockets,
>sending pings and monitor their responsetime. I was hoping somewhere in
>the lib this would be possible, and assuming it would, that was the
>reason I first addressed the IBO-list, as the IB-connection talks to the
>lib...
>
>But ok, if this is not the case, I'll use the ping-monitor...

And do a bit of a rethink about your architecture, perhaps?

As a tip, you can use the Indy components for Winsock2 (raw sockets) stuff
but pinging through winsock2 needs Administrator rights. You can do a
user-level ping through icmp.dll - here's a link to a free ping.pas unit
for this purpose, by Zarko Gajic:

http://delphi.about.com/od/internetintranet/l/aa081503a.htm

>Thanks for your time, have a nice saturday! :-)

Tks, it was a fairly busy one. :-)

./heLen