Conference noted::pwnt

This is from a customer.
I'm hoping someone here can offer suggestions for him:

-----------------------------------------------------------------------
1.      I can't get the getsockopt function call to work at all when I try
to receive the optional data which accompanies an inbound connect request
to my server process.  Here's my code..

"both hDnetListenSocket and the pointer to the storage to receive the new
socket (phDnetNextSocket) are passed into
this routine"
short                  csUserData;
optdata_dn     tUserData;

memset(&tUserData, '\0', sizeof(optdata_dn)); tUserData.opt_optl =
OPLSRV_MAX_DNET_USER_DATA;

 .
 .
 .
 .

*phDnetNextSocket = accept( hDnetListenSocket,
(sockaddr*)&tSocketAddress, (int*)&lSocketAddress );
if ( *phDnetNextSocket != INVALID_SOCKET )
    {
lStatus = OPL__SUCCESS;
      }
else
      {
lStatus = GetLastError();
return(lStatus);
      }

sStatus = getsockopt( *phDnetNextSocket,
DNPROTO_NSP,
DSO_CONDATA,
(char*)&tUserData,
(int*)&csUserData);

I get a return code of -1 and when I invoke GetLastError() I get a code of
10014.

-----------------

2.      I can't get the setsockopt function to work when I try to reject an
inbound connect request.  Here is my code.

"achUserData and hDnetSocket are both passed into this code"
optdata_dn     tUserData;
 .
 .
 .

memcpy(tUserData.opt_data,
achUserData,
csUserData);
tUserData.opt_optl = csUserData;
sStatus = setsockopt( hDnetSocket,  <==== I get success from this one.
DNPROTO_NSP,
DSO_DISDATA,
(char*)&tUserData,
sizeof(optdata_dn));

sStatus = setsockopt( hDnetSocket,  <==== I get -1 from this one and
when I invoke GetLastError(), I get
DNPROTO_NSP,     10038.
DSO_CONREJECT,
0,
0);

-----------------------------
3.      After I initially BIND a task name to a socket, and then close the
socket and create another one, I am unable to BIND the same task name to the
new socket eventhough I got rid of the first socket.  Why is this?  Also,
after I BIND the task name the first time, I am unable to "see" my task name
utilizing the NCP utility on the NT machine.  Is this normal?  I kind of
expected to be able to see the tasks like you can see them on the VMS machines.

I am not sure how helpful this is, but 14 is EFAULT, usually means
one of the parameters (or structure members) is not correct.

38 is ENOTSOCK, which usually means you have somehow done a close
or shutdown or somehow messed up your socket

hth,
--roger

a fourth question from the customer:

When in the process of connecting to a remote system, you get a socket, and
you want to put it in deferred-accept; mode by using setsockopt, but it gives
you error 10014. You are passing these parameters:
Socket
Dn_protonsp
Dso_acceptmode
Address of char that has acc_defer constant
The number 1 - which is the length of the value of the previous parameter.

> When in the process of connecting to a remote system, you get a socket, and
> you want to put it in deferred-accept; mode by using setsockopt, but it gives
> you error 10014. You are passing these parameters:
> Socket
> Dn_protonsp
> Dso_acceptmode
> Address of char that has acc_defer constant
> The number 1 - which is the length of the value of the previous parameter.

	See the programmer kit release notes.  I spent alot of time
	writing that particular release note.  Winsock does *not*
	support the concept of defered accept, it *always* accepts
	the connection.  Maybe Microsoft has fixed it with their
	Winsock-2 implementation, but the problem with their Winsock1.1
	implementation was most definitly is their design.  They supported
	it in one of the betas or internal baselevels of NT V3.1, then
	to fix a problem they had with TCP, they changed the behaviour.

	you'll also see another release note when you or the customer reads
	them about another winsock restriction on the length of the
	get/setsockopt value argument .....

>	See the programmer kit release notes.  I spent alot of time
>	writing that particular release note.  Winsock does *not*

Its a very good description of the restrictions too....