FreeTDS Development Group

["Frank M. Kromann" <frank AT kromann.info>]

Hi James,

That made it work with ioctl_blocking = 1, but I'm still having problems
with the rest of the code (More M$ issues I think).

I changed an in to unsigned int in tds/read.c and now I'm able to read the
first package, but it seams to be wrong. This is the content from my log

Received header @ 12:49:03
0000 00 00 00 00 3a 12 ab 71-                        |....:.½q|


12:49:03 looking for login token, got  0()
12:49:03 tds_process_default_tokens() marker is 0()
Unknown marker: 0(0)!!

The same php code on a Linux box (freetds 0.60) returns this in the log

Received header @ 2003-07-14 12:49:10.208037
0000  04 01 01 dc 00 33 01 00                            |...Ü.3..|

I'll fix my autoconf stuff so I can compile from cvs.

- Frank

> > From: Frank M. Kromann [mailto:frank AT kromann.info]
> > Sent: July 14, 2003 1:55 PM
> > 
> > SO_LINGER and SO_KEEPALIVE are both defined in winsock.h and are bot
> > visible to the preprocessor.
> > The changes from 1.95 to 1.96 does not seam to have anything 
> > to do with
> > the connect() function and reverting the changes from 1.96 to 
> > 1.97 does not have any effetc.
> 
> Hi Frank, 
> 
> Well, that's one longshot that finished out of the money.  :-/  Be
advised,
> I have no real experience with socket programming in unix or Win32.  All
I
> can do is read the docs and offer some possible suggestions.  
> 
> > The problems with connect() seams to be connected to the setting of
> > nonblocking mode. If I change line 311 to 
> > 
> > ioctl_blocking = 0; /* ~0; //TRUE; */
> 
> (I think that variable inversely named, btw.  I would expect
"ioctl_blocking
> = 0" to yield a *nonblocking* socket.  "ioctl_nonblocking = 0" suggests
that
> nonblocking is false i.e., it blocks.  And, for the record, I really
dislike
> negative flags.  Better to state the affirmative.)
> 
> Microsoft's docs indicate that ioctlsocket() returns SOCKET_ERROR on
error,
> which on my machine is defined as -1.  So I have to believe that the
call
> succeeds (returns 0).  
> 
> I think the problem lies in Microsoft's semantics for connect(2).  Our
code
> expects BSD semantics:
> 
>       retval = connect(tds->s, (struct sockaddr *) &sin, sizeof(sin));
>        if (retval < 0 && errno == EINPROGRESS)
>               retval = 0;
> 
> Microsoft doesn't return -1 and set errno.  They return SOCKET_ERROR
(-1),
> and say WSAGetLastError() will return WSAEWOULDBLOCK.  They don't touch
> errno.  
> 
> Here's a quick hack:
> 
>       retval = connect(tds->s, (struct sockaddr *) &sin, sizeof(sin));
> # if WIN32
>        if (retval < 0 && WSAGetLastError() == WSAEWOULDBLOCK)
> # else
>        if (retval < 0 && errno == EINPROGRESS)
> # endif
>               retval = 0;
> 
> Does that make any difference?
> 
> --jkl
> 
> > I'm able to connect. Then it is on to the next problem - 
> > connection dead
> > :-)
> > 
> > 10:47:54 Connecting to 127.0.0.1 port 1433, TDS 7.0.
> > 10:47:54 tds_put_string converting 6 bytes of "obelix"
> > 10:47:54 tds_put_string wrote 12 bytes
> > 10:47:54 tds_put_string converting 6 bytes of "myuser"
> > 10:47:54 tds_put_string wrote 12 bytes
> > 10:47:54 tds_put_string converting 7 bytes of "PHP 4.0"
> > 10:47:54 tds_put_string wrote 14 bytes
> > 10:47:54 tds_put_string converting 7 bytes of "myalias"
> > 10:47:54 tds_put_string wrote 14 bytes
> > 10:47:54 tds_put_string converting 10 bytes of "DB-Library"
> > 10:47:54 tds_put_string wrote 20 bytes
> > 10:47:54 tds_put_string converting 10 bytes of "us_english"
> > 10:47:54 tds_put_string wrote 20 bytes
> > 10:47:54 tds_put_string wrote 0 bytes
> > 10:47:54 tds_process_login_tokens()
> > 10:47:54 looking for login token, got  0()
> > 10:47:54 tds_process_default_tokens() marker is 0()
> > 10:47:54 leaving tds_process_default_tokens() connection dead
> > 
> > - Frank
> -----------------------------------------
> The information contained in this transmission may contain privileged
and confidential information and is intended only for the use of the
person(s) named above. If you are not the intended recipient, or an
employee or agent responsible for delivering this message to the intended
recipient, any review, dissemination, distribution or duplication of this
communication is strictly prohibited. If you are not the intended
recipient, please contact the sender immediately by reply e-mail and
destroy all copies of the original message. Please note that we do not
accept account orders and/or instructions by e-mail, and therefore will
not be responsible for carrying out such orders and/or instructions.
> 
>