Skip to Content.
Sympa Menu

freetds - Re: [freetds] removing a todo

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: "James K. Lowden" <jklowden AT freetds.org>
  • To: FreeTDS Development Group <freetds AT lists.ibiblio.org>
  • Subject: Re: [freetds] removing a todo
  • Date: Mon, 8 Jan 2007 21:28:29 -0500

ZIGLIO, Frediano, VF-IT wrote:
> >
> > In net.c, there is this question about sendto(2) on a UDP port:
> >
> > /* TODO is there a way to see if server reply with an ICMP (port not
> > available) ?? */
> >
> > There is not. Well, there is, but it is extremely difficult
> > and complex,
> > taking up a whole chapter in Stevens's Unix Network Programming.
> > Certainly it's not worth it.
>
> The problem is understanding if server cannot reply to our request. If
> server reply that port is closed is useless to repeat loop 16 times.
> I think that a better change would be to change comment to a
>
> /* There is no easy way to detect if port is closed so we always try to
> get a reply from server 16 times */

Added.

> You know, my memory is not so good so I bet that some years later I will
> ask me the same question...

You too? Sometimes I read my own messages without recognizing them until
I get to the signature.

> I think that removing tdserror call is not so good.
> tds7_get_instance_port is called by tds_connect and if is not able to
> get port is just return without any notice to library. We can't
> dinstinguish between "server is not available" and "timeout" so I
> notified a timeout. I agree that notifying a timeout on every loop is
> not correct but at least when you finish loop and port is not valid
> would be helpful.

OK, but SYBETIME is wrong, I think. I don't think Microsoft db-lib can
connect to an instance. It looks like the URL below shows the ODBC error?


http://support.microsoft.com/kb/265808

So we would define:

SYBEPORT and TDSEPORT = 67
Instead of severity 61, I would use EXCOMM (11)
Intead of "Client unable to establish connection" (too vague), I'd say
"Unable to learn instance port number from server" or something like that.


Sound OK?

This raises another compatibility point. libtds is generating msgno
values and based on db-lib messages. That makes it easy for db-lib to
process. If the ODBC driver wants other values, it has to convert them.
ct-lib should, too, but no one's complained yet. (N.B. for other readers:
the msgno values generated by libtds to ct-lib haven't changed. I put new
logic in place, but I didn't change the message numbering scheme.)

--jkl




Archive powered by MHonArc 2.6.24.

Top of Page