Skip to Content.
Sympa Menu

freetds - Re: [freetds] Pooling with SQL2K

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: brian AT bruns.com
  • To: freetds AT lists.ibiblio.org
  • Cc: freetds AT lists.ibiblio.org
  • Subject: Re: [freetds] Pooling with SQL2K
  • Date: Thu, 04 Dec 2003 17:47:15 -0800 (PST)

On Fri, 28 Nov 2003 01:13:51 -0500, "Don Gray" wrote:

>
> I understand that connection pooling is currently only
> available for protocol version 4.2
>

I've done some recent work at getting TDS 5.0 working
too, if I can manage to get it finished soon, I'll be
checking that in.

> I would like to use pooling with SQL2K and so
> understand that code will need to be changed to
> accomplish this.

I know Jim responded with a pretty accurate
description, but I'll give you my take anyway.

One small clarification, the way the pooling server is
written currently, the client and server protocol
version must match. This is because we are not
re-packing the data as it flows from server to client,
we just monitor the stream to determine when it is done
and thus we can return the server connection back to
the pool.

> I have begun reviewing the pool source and would like
> any input that could be provided reagrding the types
of
> changes that should be made to support other protocol
> versions.

I'll try to be fairly complete here about what needs to
be done to support TDS 7.

1. a flag "tds version" needs to be added to the config
file. see config.c for details, add a corresponding
field to the TDS_POOL structure in pool.h. This will
be then be used in the following when we must determine
protocol version.

2. pool_user_login() needs to call tds7_read_login()
instead of tds_read_login() when configured for TDS
7/8.

3. pool_user_login() needs to forge a login
acknowledgement stream for TDS 7/8. This is probably
the trickiest part when dealing with NTLM
authentication, as it requires an additonal state check
in pool_process_users(). (Instead of

-> login packet
<- login ack packet

you actually get

-> login packet
<- challenge packet
-> auth packet
<- login ack packet

My advice, start with server logins and tackle ntlm
after you get that working. Technically, there is no
reason for the pool to support ntlm that I can think
of. Still you'll need some nice traces to figure out
what is supposed to show up in the login ack stream and
in which order.

4. Note, the pool -> server connections currently just
grab the protocol version from the freetds.conf file
which allows users to misconfigure the thing. A check
should be put in pool_mbr_login(). (optional step)

Once, you can login in, you need only monitor the
response stream to figure out when the repsonse ends.
Everything else is blindly given from server to client
while the client has a server connection allocated.
This is done pretty much all in stream.c. There are
three type of tokens (PDU's). Fixed, variable, and
row.

5. Fixed sized tokens are listed in
tds_get_token_size(). You shouldn't have to change
anything here unless you run across a fixed length tds7
only token (doubtful).

6. Variable length tokens have their size transmitted
in bytes 2-3 of the token (byte 1 is the token type)
You shouldn't have to change anything here either,

7. *except* in order to handle row tokens, we need to
parse apart the results token when we see it. In TDS
4.2 this is actually two separate tokens, in TDS 7
there is a new format, so add a read_tds7_results()
function to stream.c and parse the packet for number of
columns, types, and sizes. This will allow you to
process the row tokens. Use read_col_names() and
read_col_info() as a rough guide on how to populate the
res_info structure and storing in pmbr->res_info.

8. row tokens. If you did number 7 correctly, your row
tokens should handle themselves. One possible caveat,
Since TDS7 is UCS-2 format, character strings are 2
bytes per character instead of 1. You may need to
remove assumptions from the code where I used bytes and
characters interchangably.

> Are the changes "addtional" in nature, meaning that
> more code needs to be added to handle multiple
versions
> or are they "rip and replace" type changes that lead
to
> the code currently being used for 4.2 being replaced
as
> well?

The changes would be "additional" according to your
definition, just a config file entry to switch the
server between 4.2 or 7.

> Can you point me to anything that might not be obvious
> in other portions of the "main" tds code base as a
> guide?
>
> Are there any "land mines" that I should be aware of
in
> attempting to implement these changes?

Forging the login acknowledgement and parsing the tds7
results token are the difficult pieces. look at
tds/token.c to see how to read the tds7 results. As
far as the login ack, set TDSDUMP on a non-ntlm (server
login) freetds -> sql server connection. and look at it.

> I cannot commit that I can effect these changes but I
> am serious about making an effort to assist this great
> project.

Happy to help, but my response time isn't the best
these days.

> Thanks!




Archive powered by MHonArc 2.6.24.

Top of Page