FW: Select Call On Windows.

NTDEV
1

Hi Everyone,
I have the following code in Windows

FD_ZERO (&fds);
FD_CLR(hContext->s, &fds);
FD_SET (hContext->s, &fds);
timeout.tv_sec = 1;
timeout.tv_usec = 0;

/*
* We are supporting Connection Stalling.
* But for How much time the client stalls read??
* We take 2 minutes as default. CTT passes with two
* minutes and is a good time for closing the connections.
*/

SelectRet = select(FD_SETSIZE,
NULL,
&fds,
NULL,
&timeout);
if(!SelectRet)
{
/*Selection Timeout*/
printf(“%d:STO\n”,hContext->s);
//Cnt++;
//if(Cnt > 2) return false;
//continue;/*Try Again*/
return false;
}

if(SelectRet < 0)
{
/*Select Call Failed- Not Timeout*/
BcmLogMsg(“%d:SF”,hContext->s); fflush(stdout);
return false;
}

/*SEND THE DATA TO client.*/

The problem is that the select call is always succeeding even for a closed socket. Under linux this works great.
Any help will be highly appreciated.

Thanks,
– Ajitabh.

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@hotmail.com
Sent: Monday, July 27, 2009 3:05 PM
To: Extended Discussions on System Software (particularly Windows)
Subject: RE:[nttalk] Languages: C# is Not C++… F# is Pure Ass

I didn’t say the entire OS has no hardware process isolation. I said the OS rather “avoid(s)
the use of hardware protections and ensure the safety of executing code only via software.”

I see…

However, the idea of controlling safety/privileges/etc purely in a software is not new in itself and has
been used by microkernels for at least 25 years, although introducing managed language to the scheme makes the whole thing truly unique…

BTW, probably you remember that around a year ago we discussed the possibility of implementing drivers as message queues so that the whole thing synchronize itself. Actually, I think this idea may be quite interesting, particularly for RTOSes (both microkernel-based and monoliths)…

Anton Bassov

NTTALK is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

NTTALK is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

2

> The problem is that the select call is always succeeding even for a closed socket. Under linux

this works great.

It does not succeed on Windows either…

The problem is that, unlike Linux errors that are negative, Winsock’s WSA_ERROR codes are positive, so that you just treat WSA_ERROR code as success…

Anton Bassov

3

Thanks for the reply but MSDN article
http://msdn.microsoft.com/en-us/library/ms740141(VS.85).aspx

Says that select should return SOCKET_ERROR (-1) if there is no connection and then you go and call WSASocketError.

– Ajitabh

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@hotmail.com
Sent: Friday, July 31, 2009 4:43 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] FW: Select Call On Windows.

The problem is that the select call is always succeeding even for a closed socket. Under linux
this works great.

It does not succeed on Windows either…

The problem is that, unlike Linux errors that are negative, Winsock’s WSA_ERROR codes are positive, so that you just treat WSA_ERROR code as success…

Anton Bassov

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

4

> Says that select should return SOCKET_ERROR (-1) if there is no connection and then

you go and call WSASocketError.

Are you speaking about disconnected or closed socket in your original post??? I don’t know if it matters in this context, but in the latter case descriptor itself is invalid( in case of valid socket handle, it happens to be a handle referring to FO owned by AFD.SYS). A claim of being able to successfully make a system call on invalid descriptor sounds…uh,strange…

Anton Bassov

5

> It does not succeed on Windows either…

The problem is that, unlike Linux errors that are negative, Winsock’s WSA_ERROR codes are
positive, so that you just treat WSA_ERROR code as success…

Not correct.

ms-help://MS.MSDNQTR.v90.en/winsock/winsock/select_2.htm

“Return Value
The select function returns the total number of socket handles that are ready and contained in the fd_set structures, zero if the time limit expired, or SOCKET_ERROR if an error occurred.”

D:\WinDDK\6001.18002\inc\api\winsock2.h

#define SOCKET_ERROR (-1)

–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

6

>happens to be a handle referring to FO owned by AFD.SYS). A claim of being able to successfully

make a system call on invalid descriptor sounds…uh,strange…

At least this is an undocumented feature of any OS.

–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

7

Alright, I know that the select should not succeed because the immidiate send after select fails. If I ignore send error (which I was doing before because of signed unsigned mismatch)
The select suceeds properly.

Here is the code again.

SelectRet = select(FD_SETSIZE,
NULL,
&fds,
NULL,
&timeout);
if(!SelectRet)
{
/*Selection Timeout*/
BcmLogMsg(“%d:STO\n”,hContext->s);
Cnt++;
if(Cnt > 2) return false;
continue;/*Try Again*/
}

if(SelectRet < 0)
{
/*Select Call Failed- Not Timeout*/
BcmLogMsg(“%d:SF”,hContext->s);
return false;
}

/*Select Succeeded*/
/*Try to send the whole remaining buffer*/
SendSz = send(hContext->s,
Buffer,
XferSz,
SendFlags);
if(SendSz < 0)
{
BcmLogMsg(“\n ***** Sending Buffer failure ***** \n”);
return false;
}

Both SendSz and Selectare signed variables. I now treat the error from send as fatal and close the socket. Looks like its working great.
– Ajitabh.

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Maxim S. Shatskih
Sent: Saturday, August 01, 2009 5:43 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] FW: Select Call On Windows.

happens to be a handle referring to FO owned by AFD.SYS). A claim of being able to successfully
make a system call on invalid descriptor sounds…uh,strange…

At least this is an undocumented feature of any OS.

–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer