FreeTDS Development Group

["Scott C. Gray" <gray AT voicenet.com>]

On Thu, 22 Apr 1999 ark AT eltex.ru wrote:

> nuqneH,
> 
> Does anybody know how OOB data are used in TDS protocol?
> I am trying to write a proxy for TDS. I've noticed that MS SQL client
> sends something like cleanup request in OOB (it does happen when i close
> a request window or somth like that in client program). Real PITA for now,
> as far as i seen FreeTDS library does not handle OOB data so i could not
> find any reference what to do (i cannot transmit it "as is" because i
> have a TCP crypto tunnel that does not handle OOB so i need a way to
> translate it to whatever else). Any hints?

I can't speak much for FreeTDS libraries, but I can talk a little
bit about how OOB packets are utilized in Sybase TDS 4.6 and 5.0.

In TDS 4.6, a cancel--or attention--request (usually made via a
call to dbcancel() in db-library) generated an OOB packet which
caused a SIGURG signal to be raised in the server on the other 
end of the pipe.  Upon sending the OOB packet, the client library
would then read and discard packets from the network until it
received an acknowledgement of the packet from the server. Once
it receivees this acknolwedgement it knows that the communications
state of the network has been reset, packets are no longer waiting
and it may now issue new queries.

   SIDE NOTE:
      I can't tell you how many customers that I have been to
      that do the following in their code:

         dbuse( dbproc, "mydb" );
         dbcancel( dbproc );
      
      just to save a line or two of code to process the results
      from the use database command. When the dbuse() is executed
      a little packet is sent out with the "use database" command,
      and a little response is sitting on the network waiting to
      be dealt with.  

      Rather than dealing with it, the customer is sending out 
      *another* packet (the cancel request) which has *another*
      response (the aknowledgement). The dbcancel() call then
      discards all of the waiting packets.  

      To save a couple of lines of code, the programmer is
      generating twice as much network traffic (plus forcing
      extra context switching in the server while the SIGURG
      signal handler is called).

One major problem that Sybase hit with this method of cancelation
is that OOB's are not guarenteed by TCP/IP. So, under some circumstances
where the customer's network was very heavily loaded, the OOBs
would be lost, causing clients to hang forever waiting for an
acknowledgement.  Not good.

To address this (and to provide a more portable mechanism--not
all network stacks support OOB's), TDS 5.0 moved to in-band 
cancelations.  Under this mechanism, attentions are sent 
using a regular old packet (of type TDS_ATTENTION) down the
network just like any other packet. The disadvantage of this
mechanism is that the server must read all data waiting on the
network before it gets to the attention request (OOB's would
leap-frog over all data waiting on the network), but thanks
to the way TDS works, if the server is processing a query, then
there was no data pending to be read from the client anyway.
The advantage is that attentions could be dealt with in the
server just like any other packet, they are reliable, and 
portable across network stacks.

Now, from what little I know about MS TDS, it is still 
relatively TDS 4.6 based and therefore uses OOBs (correct me
if I am wrong).  If you are running over a tunnel that
does not allow OOB's, then you will probably need to write
servers that sit on either end and talk to eachother, wrapping
the TDS packets in such a manner that you may imbed the 
attention request in-stream, then turn them back into OOB's
on the other side.  Feasible but kind of nasty.

I hope this helps.
-scott

--
Scott C. Gray                 gray AT voicenet.com     "my keybard is brken"
Sybase Professional Services  scott.gray AT sybase.com
   http://www.voicenet.com/~gray/sqsh.html