Skip to Content.
Sympa Menu

freetds - RE: [freetds] FreeTDS (on FreeBSD) lost connection toremoteMSSQLserver

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: "ZIGLIO, Frediano, VF-IT" <Frediano.Ziglio AT vodafone.com>
  • To: "FreeTDS Development Group" <freetds AT lists.ibiblio.org>
  • Subject: RE: [freetds] FreeTDS (on FreeBSD) lost connection toremoteMSSQLserver
  • Date: Mon, 27 Jun 2005 17:08:15 +0200

>
> > From: ZIGLIO, Frediano, VF-IT
> > Sent: Monday, June 27, 2005 9:35 AM
> >>
> >> Is there any way to detect server disconnection?
> >> I have FreeTDS installed from ports on FreeBSD 5.3 (version 5.0 as
> >> port says).
> >> Everything working great, but in case network problems or
> SQL server
> >> restart tds_submit_query simply returns 0 (TDS_FAIL) with no extra
> >> information.
> >> Can I handle such kind of situation?
> >> Thank You!
> >>
> >
> > I remember some (old) post on this subject... it seems that FreeTDS
> > is too silent about connection closing. It close correctly
> connection
> > and all future function should return failure condition however it
> > do not launch any message to client. James, what do you think about?
> > How do proprietary libraries behave? Do they continue informing
> > client that connection is closed?
>
> I don't know, because I keep my clients connected? ;-)
>
> Looking at the code, tds_write_packet() returns TDS_SUCCEED
> or TDS_FAIL.
> No information is stashed in the TDSSOCKET about what's
> wrong. I think
> that's the OP's complaint: he can't discover what's going on.
> (I don't
> see even a log message, let alone anything being sent to the error
> handler, btw.)
>
> The communication error messages, from doc/dblib_errors.txt:
>

Mmmm...

> Bad token from the server: Datastream processing out of sync.

>From src/tds/token.c

default:
tds_client_msg(tds->tds_ctx, tds, 20020, 9, 0, 0,
"Unknown marker");
if (IS_TDSDEAD(tds))
tds_set_state(tds, TDS_DEAD);
else
tds_close_socket(tds);
tdsdump_log(TDS_DBG_ERROR, "Unknown marker: %d(%x)!!\n",
marker, (unsigned char) marker);
return TDS_FAIL;
}

Perhaps proprietary error is clearer

> DB-Library capabilities not accepted by the Server.
> Unexpected capability type in CAPABILITY datastream. 392

I use very few capability

> Error in closing network connection.

?? quite strange, not handled (kernel error ??)

> Unable to connect: Adaptive Server is unavailable or does not exist.
> Unsolicited event notification received.
> Adaptive Server connection failed.
> Negotiated login attempt failed.

it would be fine if FreeTDS could distinguish these errors and report to
client...

> Error in sending out-of-band data to the server.
> Read from the server failed.

from src/tds/net.c

if ((len = goodread(tds, header, sizeof(header))) < (int)
sizeof(header)) {
/* GW ADDED */
if (len < 0) {
tds_client_msg(tds->tds_ctx, tds, 20004, 9, 0,
0, "Read from SQL server failed.");
tds_close_socket(tds);
tds->in_len = 0;
tds->in_pos = 0;
return -1;
}

good

if (x < 1) {
/*
* Not sure if this is the best way to do the error
handling
* here but this is the way it is currently being done.
*/
tds->in_len = 0;
tds->in_pos = 0;
tds->last_packet = 1;
/* return 0 if header found but no payload */
return len ? -1 : 0;
}

no message... bad

> Unexpected EOF from the server.

We do not distingue this error from a read error (I don't think is a big
problem...)

> Unable to open socket.

from src/tds/net.c

if (TDS_IS_SOCKET_INVALID(tds->s = socket(AF_INET, SOCK_STREAM,
0))) {
tdsdump_log(TDS_DBG_ERROR, "socket creation error:
%s\n", strerror(sock_errno));
return TDS_FAIL;
}

no error to client

> Read attempted while out of synchronization with Adaptive Server.
> Unknown message-id in MSG datastream.
> Unable to set communications timer.
> Unrecognized TDS version received from the server.
> Write to the server failed.
>

from src/tds/net.c

if (retval <= 0) {
tdsdump_log(TDS_DBG_NETWORK, "TDS: Write failed
in tds_write_packet\nError: %d (%s)\n", sock_errno,
strerror(sock_errno));
tds_client_msg(tds->tds_ctx, tds, 20006, 9, 0,
0, "Write to SQL Server failed.");
tds->in_pos = 0;
tds->in_len = 0;
tds_close_socket(tds);
return -1;
}

good

> EXCOMM is described as "Failure in communication with Server -- the
> DBPROCESS is dead."
>
> When communication has been lost -- I'm not sure how we know when that
> is -- I think the only thing to do is to set issue the error "Write to
> the server failed" (differs by library) and set tds->state = TDS_DEAD.
> That way the client libraries would know the TDSSOCKET is no good, and
> should consistently refuse to use it.
>
> This is the reward for making timeouts work: now we have to tell the
> client what's wrong, instead of just retrying forever!
>

Correct but is what code do now.

> Of course, I'm just reasoning from the code and the documentation,
> knowing, as an application programmer, how I'd like libsybdb
> to behave.
> I'm not set up to test this with the vendors' libraries. If someone
> else would like to do that, I'm sure we'd learn something.
>
> HTH and regards,
>

I'll try to do some tests...

bye
freddy77




Archive powered by MHonArc 2.6.24.

Top of Page