At 03:59 AM 19/01/2010, Russell R wrote:
>Hi
>This is the summary of all my other posts. Sorry for the confusion earlier,
>but I thought it best to consolidate. I am running the latest version of
>firebird client (2.5.1) built for .net 2.0 compact framework (Thanks Jakub).
>
>During a fetch cycle of a large select, I often get a 10054 error on the
>server and read error within the client code. This only happens when
>communicating via a LAN connection (never via a USB).
Problems occurring during "fetch cycle of a large select" ought to make you at
least suspicious that your client application is the one that is crashing. Are
you sure the client device has enough resources to what you're asking it to do?
A crashed app means (eventually) a dead socket and thus a 10054 error in
firebird.log, which reflects the loss of one side of a socket.
>I have tried many different error recovery tatics and none of them seem to
>work. Also the network I am using is only local and so there shouldn't be
>too much noise. Once I get the 10054 error, the only solution seems to be
>to close the connection and start a new one. However, this is quite time
>consuming on a Windows CE device and the server eventually crashes.
If the *server* crashes as the result of a client operation from the network
then the cause is usually a call to a buggy UDF. Otherwise, it's really hard
for a client to crash the server. Does it really crash? If/when it does, with
luck there will be some clue in the system logs and/or firebird.log.
>Therefore I think the issue must be related to how the client/server
>interacts with TCP and this would mean looking into the client code. Whilst
>I have the code, I don't think I could readily find out what is going on.
The client and server "interact" with TCP/IP only insofar as they use it as a
transport layer *if* the client uses TCP/IP protocol for its connection. The
Firebird server (and guardian, if it is being used) report any network error
messages in firebird.log but they don't have any influence over a broken
socket. (TCP/IP is out of the picture if the client uses a different protocol,
btw.)
You will see 10054 ("Connection reset by peer") errors under various
conditions. Some are significant, some not. Clients that "crash out" of a
connection, e.g., by switching off the PDA while an operation is in progress or
encountering some other unhandled error, will break the socket and cause a
10054 error. That's just an example: there's a long list of possibilities.
Sometimes this sort of problem occurs when the TCP/IP timeout and/or keepalive
parameters for the network are unsuitably configured for the types of clients
that use it, causing the TCP/IP server to reset a connection arbitrarily if it
decides the peer is unresponsive. A network connection is only as fast as the
slower end of the partnership. With a slow client, it's not unusual for a
Windows server with default TCP/IP properties to cause this problem.
If the network setup is allowing DHCP to assign an arbitrary node address for
the host then it is possible for a slow client to "lose" the server if a
timeout occurred that eventually left a server program idle. Use a static IP
address for the host server and, if necessary, for those slow clients. It
might not solve the whole problem but at least any recovery procedure at the
client can hope to retrieve a valid connection handle if it is able to refresh
its end of the connection before the server notices it is lost.
Note that Windows updates have been known to "break" network conditions that
worked previously but that might have been vulnerable to some threat that the
update addresses.
>Please could someone help out
No obvious single answer here, though, and the issues mentioned are just clues,
pretty much all OT for the net-provider, afaiu.
Helen
------------------------------------------------------------------------------
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
http://p.sf.net/sfu/rsaconf-dev2dev
_______________________________________________
Firebird-net-provider mailing list
Firebird-net-provider@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/firebird-net-provider
