Proposal: lightweight TDS proxy utility (tdsproxy) built on libtds

[yairlenga]

Hi all,

I’ve been experimenting with a small generic TDS proxy built directly on libtds (no ct-lib/db-lib).
The goal is a transparent passthrough that can optionally act as a read-through cache for deterministic queries — similar in spirit to tsql and bsqldb, but sitting between clients and the real ASE/SQL Server.

Motivation

• Centralize routing / observability for TDS traffic
• Reduce backend load for repeated read-only queries via simple caching
• Provide a test harness for protocol debugging and packet inspection
• Stay 100 % protocol-correct: no custom token emitters, just replay ASE/SQL Server’s own bytes

Concept

Client  <—TDS—>  [tdsproxy FE]  <—TDS—>  [tdsproxy BE]  <—TDS—>  Server
                         |                         ^
                         |                         |
                         +——— (optional cache: read-through, packet replay) ——+

• Implemented entirely on libtds (TDS 5.0 – 7.4)
• Default mode: pure passthrough
• Optional “packetized replay” cache — on a hit, re-send the exact byte stream seen from the server (perfect fidelity)
• Lives as a new utility under src/apps/tdsproxy/; build-optional, no changes to core code
• Very small surface area: listen socket → libtds FE → backend connection → copy bytes → (optional) cache

Asking for feedback

Would a self-contained tdsproxy utility like this be welcome in-tree as an example / debugging tool?
If there’s interest, I’ll follow up with a detailed design note and pseudocode prototype.

Thanks for any thoughts or prior-art pointers,
Yair Lenga

[freddy77]

It looks somehow similar to the pool server in src/pool. Yes, it has different features and purposes. I have no idea which queries can be cached in a production environments. Usually queries contains tables and tables tends to change. You can replay the binary stream but you have to check the connection settings, otherwise the saved stream could became invalid.
It's not clear which kind of testing you would like to implement, can you give some example?

[yairlenga]

Many thanks to the pointer. It’s very similar, and I can reuse lot of code.

few changes based on my requirements - caching:

1. My use case involve reading data from a downstream process, I was planning to assume reasonable TTL (e.g. 1 min, 5 min) - data history for reporting - ok to be few minutes behind.

2. I need to support per user context/stateful session. So I plan to open the backend connection per client. The client will enable/disable caching using special sql command “set caching on”/“set caching off”, which I will parse. I have limited control over the client - I can send those command before/after starting sequences that are known to use highly cacheable results.

3. The code is structured very well - the main loop is very efficient in handling large number of connection with few thread. I did not review all code - I need to understand the thread creation/termination. From quick loo, looks like thread are created whenever (1) user connect (2) user finish login (3) connection is assigned to a user. For my use case - small number of persistent connections - might be easier to assign a thread to each user, since inbound connections = outbound connection.

Again, thanks for great pointer p. It will cut my dev time significantly !

As far as the testing - I thought about building a test mode into the server, which will allow querying in memory table. This will add 2 pseudo command “cache-set key value ttl”, than “cache-get key”.

with those 2 commands the test script will execute a series of isql commands to ensure the conditional caching work.

While in theory, possible to merge new functionality into existing server - I believe separate programs are the best, asvesvhnsupport different function, and mixing them together not worth the risk.

[yairlenga]

Side question - anyone know if server works with sybase ase 16 backend.

[freddy77]

Side question - anyone know if server works with sybase ase 16 backend.

Surely pool part does not handle Sybase. There's a src/server part implementing part of a server. Mostly the requirements for the pool part, but there are some generic part supporting both. But mostly the target of FreeTDS is client not server so that part is much more in "development/experimental" state.