Subject | Re: timeout a pending connection via a bad network? |
---|---|
Author | Adam |
Post date | 2005-12-18T00:24:44Z |
--- In firebird-support@yahoogroups.com, "Adam" <s3057043@y...> wrote:
As Helen said, technically it is the network layers "job" to make sure
that messages make it from the sender to the receiver. In a packet
switched network, you have all sorts of fun things that happen.
Packets can arrive out of sequence, corrupted, not at all or perfectly
in tact. They may arrive perfectly, but the acknowlegdement packets
may also be corrupt or lost. Generally speaking, networks don't stop
working, but rather deteriorate in performance to a point where they
are unsuitable for the communications they were designed for. Firebird
assumes that if the network is available, then it is perfect (as it
should).
There are different uses for the Firebird DBMS. If your system is
heavily user interactive, then it will require a more stable
connection then if it is not directly used by a human. If it takes 10
seconds to return a query that only takes 100ms on a stable network, a
human would get impatient (particularily if you tie up the main thread
with the query and so freeze the GUI from receiving paint messages),
whereas a program with no UI will just take longer to complete which
may not be an issue.
So it is up to you as the application developer to define the
acceptable response times. While Firebird is "chatty", even if it
wasn't, speed would still be a problem in many cases.
If you are intending to deliver your application over an unstable
network, then I would suggest that a "client-server" approach will not
work very well. Better off choosing some n-tier architecture.
Adam
>wrote:
> --- In firebird-support@yahoogroups.com, John vd Waeter <john@j...>
> >like the
> > Hi,
> >
> > Nobody? All applications freeze when networkthroughput drops down to
> > allmost zero or even stops at all?
> >
> > My case was a network (via internet) from which a ping returned
> about 5%
> > of the packets... not to mention the turnaroundtime. Really bad
> > performance. As I learned here that FB is rather "chatty" over the
> > network, I can understand that in these circumstances it looks
> > application locks up.might
> >
> > I would like to signal the user that network is bad, and that it
> > be a good idea to try later... How would I do that?I probably should have explained a bit more detail.
> >
> > tia!
> > John
> >
>
> Create another thread and ping the server? When the response time is
> "too slow", synchronise the thread to pop up the warning. The
> chattyness of Firebird will exagerate the speed issue, but I suggest
> that anything with just 5% success for ping is pretty much useless for
> any protocol.
>
> Adam
>
As Helen said, technically it is the network layers "job" to make sure
that messages make it from the sender to the receiver. In a packet
switched network, you have all sorts of fun things that happen.
Packets can arrive out of sequence, corrupted, not at all or perfectly
in tact. They may arrive perfectly, but the acknowlegdement packets
may also be corrupt or lost. Generally speaking, networks don't stop
working, but rather deteriorate in performance to a point where they
are unsuitable for the communications they were designed for. Firebird
assumes that if the network is available, then it is perfect (as it
should).
There are different uses for the Firebird DBMS. If your system is
heavily user interactive, then it will require a more stable
connection then if it is not directly used by a human. If it takes 10
seconds to return a query that only takes 100ms on a stable network, a
human would get impatient (particularily if you tie up the main thread
with the query and so freeze the GUI from receiving paint messages),
whereas a program with no UI will just take longer to complete which
may not be an issue.
So it is up to you as the application developer to define the
acceptable response times. While Firebird is "chatty", even if it
wasn't, speed would still be a problem in many cases.
If you are intending to deliver your application over an unstable
network, then I would suggest that a "client-server" approach will not
work very well. Better off choosing some n-tier architecture.
Adam