Skip to Content.
Sympa Menu

freetds - Re: [freetds] CS_SERVERADDR tag is not handled correctly in ct_con_props

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: Stephen Marshall <smarshall AT kayak.com>
  • To: FreeTDS Development Group <freetds AT lists.ibiblio.org>
  • Subject: Re: [freetds] CS_SERVERADDR tag is not handled correctly in ct_con_props
  • Date: Mon, 6 Jan 2014 12:10:34 -0500

Let me try to explain in better detail:

Problem:
The CS_SERVERADDR enum is not properly honored in the ct_con_props function
call.
For example, this call should effectively set the host and port for a DB
connection, but it results in an error when the connection information is
actually used.
ct_con_props( g_connection,
CS_SET,
CS_SERVERADDR,
(CS_VOID*)server,
CS_NULLTERM,
(CS_INT*)NULL
);
Here: g_connection is a pointer to type CS_CONNECTION, and server is text
of the form "<host> <port>". Note that FreeTDS provides other ways to
specify host and port (e.g. setting the server parameter to
"<host>:<port>"; however, the method using CS_SERVERADDR does not work.

Approaches to fix:
I see two ways to attack this problem. Of course, you may see others.

One approach is to ensure port information is set in the CS_CONNECTION data
structures and then passed to the other internal data structures used to
establish a connection in FreeTDS. This would be a true fix to the
problem, but would require some changes to at least a few internal data
structures.

Another approach is the mark the CS_SERVERADDR tag as disabled in FreeTDS.
This would not actually fix the problem, but would allow client
applications to work around the limitation. However, I think this can be
achieved by simply undefining CS_SERVERADDR in cspublic.h.

If you have any thoughts on ways to fix this, I'm certainly open to
suggestions.

Steve



On Mon, Jan 6, 2014 at 9:58 AM, Kayak <smarshall AT kayak.com> wrote:

> Marc is right. By tag, I mean the enum CS_SERVERADDR
>
> Sent from my iPhone
>
> On Jan 6, 2014, at 9:40 AM, Marc Abramowitz <msabramo AT gmail.com> wrote:
>
> > My guess is that Stephen is referring to the code around this line in
> > src/ctlib/ct.c (around line 395) in the ct_con_props function:
> >
> > case CS_SERVERADDR:
> >
> > There are comments mentioning that this code is handling the "[hostname]
> > [port]" syntax but from messages on the sqsh bug report it sounds like,
> > FreeTDS somehow still fails to connect.
> >
> >
> >
> >
> > On Mon, Jan 6, 2014 at 6:21 AM, Frediano Ziglio <freddy77 AT gmail.com>
> wrote:
> >
> >> 2014/1/2 Stephen Marshall <smarshall AT kayak.com>:
> >>> FreeTDS 0.91 does not honor the CS_SERVERADDR tag in the ct_con_props
> >>> function. This function and tag are used to allow database connections
> >>> using a "<host> <port>" syntax.
> >>>
> >>
> >> Which "tag" ?
> >>
> >>> There is code in FreeTDS that compensates for this problem by allowing
> >> the
> >>> user to specify the server name as "<host>:<port>". FreeTDS supports
> >> this
> >>> syntax as a fallback case when a server name cannot be found in the
> >>> configuration file. See freetds file src/tds/config.c,
> >>> parse_server_name_for_port function for details. However, this is not
> a
> >>> standard part of the TDS protocol. Client applications conforming to
> the
> >>> standard can end up doing the wrong thing. I have noticed this problem
> >> in
> >>> the sqsh client, but may affect other clients as well.
> >>>
> >>> The connection code should either be fixed or the CS_SERVERADDR macro
> >>> should be disabled. The latter would signal to client applications
> that
> >>> CS_SERVERADDR does not work per spec, which would allow client
> >> applications
> >>> to avoid calling this function when linked against FreeTDS.
> >>>
> >>> Note: this problem was originally submitted as a bug to the sqsh
> project,
> >>> but latter determined to be a problem in FreeTDS. Further details of
> the
> >>> original submission can be found here:
> >>> http://sourceforge.net/p/sqsh/bugs/60/
> >>>
> >>> Also note that I tried to fix this myself, but I got a little lost in
> >>> mapping of connection information between several different data
> >>> structures. It does not seem like the port information is carried
> >> through
> >>> all of them. With some guidance on how to proceed without inducing
> side
> >>> effects, I would be happy to work on this problem.
> >>
> >> I do not follow at all.
> >>
> >> Frediano
> >> _______________________________________________
> >> FreeTDS mailing list
> >> FreeTDS AT lists.ibiblio.org
> >> http://lists.ibiblio.org/mailman/listinfo/freetds
> >>
> > _______________________________________________
> > FreeTDS mailing list
> > FreeTDS AT lists.ibiblio.org
> > http://lists.ibiblio.org/mailman/listinfo/freetds
>




Archive powered by MHonArc 2.6.24.

Top of Page