Conference jamin::pathworks32

What would cause a WSAConnect() to fail with error 10051 (WSAENETUNREACH)?
If I try to run a server case (using WSAAccept()), that works fine.

Testing the client case (which is broken), I am running the server and the 
client on the same node.  Testing the server (which works) the server is nt
and the client is vms.  I dont have a vms server I can try, but running the
client to a non-existant node gives the same error.  (I am successfully
calling WSAStartup.)

Is there a 'guide to error codes' somewhere?  I looked in the sdk, and could
not find the error code by name.

--roger

    DECnet WinSock 2 returns WSAENETUNREACH when an IocbSubmitEx() 
    call to the underlying IOCB32 transport interface returns an error.  
    A quick look at the IOCB32 code shows possbile failures due to:
        decnet transport (DECIOCB.SYS or .VXD) not loaded
        IOCB32 unable to allocate memory or create an event object
        DeviceIoControl call to transport fails
    
    In the WinSock 2 architecture, WSAStartup() does not access the 
    underlying Service Providers (DECnet, TCP/IP, etc).  All the
    code for WSAStartup() is contained in the WinSock 2 framework
    (WS2_32.DLL).  The Service Providers are not invoked until a
    call in made that includes an address family such as socket()
    or WSASocket().

RE: failure reasons

>    A quick look at the IOCB32 code shows possbile failures due to:
>        decnet transport (DECIOCB.SYS or .VXD) not loaded

since the server code works on the same node, I would guess thats not
the problem.

>        IOCB32 unable to allocate memory or create an event object

Dont know why there would be trouble allocating memor, or an event.
Are the events require different/more stuff on client than server?

>        DeviceIoControl call to transport fails

Not sure what to guess at for this one.  The transport apprears to be
there (WSASocket() succeeded.)   DeviceIOControl sounds like the 
interface to the network card, and Ive no idea how to diagnose that.


The most puzzling to me is the server side works fine - listen(), and
WSAAccept() complete w/out any errrors....

--roger

    
    I am moving some software from V4.1B to PW32 on NT 4.0.
    
    We include windows.h which includes  winsock2.h,  then
    we include prgpre.h which includes socket.h  from  the
    pathworks sdk,  needless to  say  the  compiler  barfs
    about various duplicate definitions.
    
    I have searched for documentation on SDK  changes  and
    the like and haven't come up with anything. We used to
    define a macro DNET_USE_WINSOCK before  including  the
    prgpre.h file and things just worked.  This is no long-
    er the case.
    
    What is a person to do ?  I noticed windows.h  has  an
    #ifndef WIN32_LEAN_AND_MEAN which I suppose I could de-
    fine to prevent inclusion of the winsock stuff,  but I
    just want to hear what the party line is on this.
    
    _sjz.

Cant give the party line, but I had to define a compiler symbol, MSVC_VER
or something like that, to include winsock2.h instead of winsock.h.  I
saw it in windows.h, I think.

.02
--roger

    
    There is this in the windows.h that I have using VC++ V4.2 on
    an Intel Box.
    
    #if(_WIN32_WINNT >= 0x0400)
    #include <winsock2.h>
    #include <mswsock.h>
    #else
    #include <winsock.h>
    #endif /* _WIN32_WINNT >=  0x0400 */
    
    but there is nothing that I see in winsock2.h or prgpre.h and
    socket.h that looks like it prevents multiple definitions  of
    identifiers and functions.   if i try the lean and mean thing
    i get errors of the "undeclared identifier" persuasion.
    
    still looking for the right answer.
    _sjz.
    

>    #if(_WIN32_WINNT >= 0x0400)
>    #include <winsock2.h>
>    #include <mswsock.h>
>    #else
>    #include <winsock.h>
>    #endif /* _WIN32_WINNT >=  0x0400 */

Yup, and I defined _WIN32_WINNT to be 0x0400, and it works w/out errors.

--roger

    
    I did exactly that to no avail.   I do get winsock2.h,
    but later when  I  include  prgpre.h  which  includes
    socket.h all hell breaks loose.
    
    For instance in my environment I have the following
    
    INCLUDE=C:\MSDEV\INCLUDE;C:\MSDEV\MFC\INCLUDE;C:\PATHWORKS\INCLUDE
    
    where the pathworks directory is the place I unloaded
    the SDK.  Then I have the following program :
    
    #define _WINNT_WIN32 0x0400
    #include <windows.h>
    #include <prgpre.h>
    
    main()
    {
       return 0;
    }
    
    which produces the following 
    
C:\> cl foo.c
C:\PATHWORKS\INCLUDE\socket.h(45) : error C2011: 'sockaddr' : 'struct' type redefinition
C:\PATHWORKS\INCLUDE\socket.h(99) : error C2011: 'timeval' : 'struct' type redefinition
C:\PATHWORKS\INCLUDE\socket.h(118) : warning C4005: 'SO_DEBUG' : macro redefinition
C:\PATHWORKS\INCLUDE\socket.h(119) : warning C4005: 'SO_ACCEPTCONN' : macro redefinition
C:\PATHWORKS\INCLUDE\socket.h(120) : warning C4005: 'SO_REUSEADDR' : macro redefinition
C:\PATHWORKS\INCLUDE\socket.h(121) : warning C4005: 'SO_KEEPALIVE' : macro redefinition
C:\PATHWORKS\INCLUDE\socket.h(122) : warning C4005: 'SO_DONTROUTE' : macro redefinition
C:\PATHWORKS\INCLUDE\socket.h(123) : warning C4005: 'SO_BROADCAST' : macro redefinition
C:\PATHWORKS\INCLUDE\socket.h(124) : warning C4005: 'SO_USELOOPBACK' : macro redefinition
C:\PATHWORKS\INCLUDE\socket.h(125) : warning C4005: 'SO_LINGER' : macro redefinition
C:\PATHWORKS\INCLUDE\socket.h(126) : warning C4005: 'SO_DONTLINGER' : macro redefinition
C:\PATHWORKS\INCLUDE\socket.h(150) : warning C4005: 'AF_OSI' : macro redefinition
C:\PATHWORKS\INCLUDE\socket.h(151) : warning C4005: 'AF_MAX' : macro redefinition
C:\PATHWORKS\INCLUDE\socket.h(173) : warning C4005: 'PF_MAX' : macro redefinition
C:\PATHWORKS\INCLUDE\socket.h(211) : warning C4142: benign redefinition of type
C:\PATHWORKS\INCLUDE\socket.h(211) : error C2373: 'accept' : redefinition; different type modifiers
C:\PATHWORKS\INCLUDE\socket.h(212) : error C2373: 'bind' : redefinition; different type modifiers
C:\PATHWORKS\INCLUDE\socket.h(213) : error C2373: 'connect' : redefinition; different type modifiers
C:\PATHWORKS\INCLUDE\socket.h(214) : error C2373: 'getpeername' : redefinition; different type modifiers
C:\PATHWORKS\INCLUDE\socket.h(215) : error C2373: 'getsockname' : redefinition; different type modifiers
C:\PATHWORKS\INCLUDE\socket.h(216) : error C2373: 'getsockopt' : redefinition; different type modifiers
C:\PATHWORKS\INCLUDE\socket.h(217) : error C2373: 'listen' : redefinition; different type modifiers
C:\PATHWORKS\INCLUDE\socket.h(218) : error C2373: 'recv' : redefinition; different type modifiers
C:\PATHWORKS\INCLUDE\socket.h(220) : error C2373: 'select' : redefinition; different type modifiers
C:\PATHWORKS\INCLUDE\socket.h(221) : error C2373: 'send' : redefinition; different type modifiers
C:\PATHWORKS\INCLUDE\socket.h(222) : error C2373: 'setsockopt' : redefinition; different type modifiers
C:\PATHWORKS\INCLUDE\socket.h(223) : error C2373: 'shutdown' : redefinition; different type modifiers
C:\PATHWORKS\INCLUDE\socket.h(225) : warning C4142: benign redefinition of type
C:\PATHWORKS\INCLUDE\socket.h(225) : error C2373: 'socket' : redefinition; different type modifiers
C:\PATHWORKS\INCLUDE\iocb.h(242) : warning C4005: 'MSG_OOB' : macro redefinition
C:\PATHWORKS\INCLUDE\iocb.h(243) : warning C4005: 'MSG_PEEK' : macro redefinition
C:\PATHWORKS\INCLUDE\iocb.h(244) : warning C4005: 'MSG_DONTROUTE' : macro redefinition
C:\PATHWORKS\INCLUDE\sioctl.h(30) : warning C4005: 'FIONREAD' : macro redefinition
C:\PATHWORKS\INCLUDE\sioctl.h(31) : warning C4005: 'FIONBIO' : macro redefinition
    
    _sjz.

instead of prgpre.h, include ws2dnet.h

    
    that works,  though it brings on a host of other problems.
    
    for instance,  now we have  most  everything  defined  in 
    ws2dnet.h. but the return type for getnodexxx has changed
    from 'struct nodeent *' to 'struct nodeent_f *' (which of
    course is different from what we see on Digital  UNIX  so
    now we have to define a new marcro which varies  by  plat-
    form so our (which is common across  the  platforms  will
    compile).   And of course the definition in  dnetdb.h  in
    the current kit has different from the definition in  the
    file ws2dnet.h
    
    so before I go on,  is there a  document  that  describes
    all of these differences (which are not all  that  minor)
    and how one is to port code from the V4.1B version of the
    SDK to the PATHWORKS 32 version of  the  SDK ?   At least
    then I would know what to expect.
    
    _sjz.

    
    for now,  i will take that as a no.  but let me ask
    some other less rhetorical questions.
    
    if i use ws2dnet.h i get the FAR definitions.  I don't
    want them.  I just want the  regular definitions for
    things like nodeent without the _f. i tried just including
    dnetdb.h and dn.h but that results in numerous things be
    undefined at compile time.  what is the incantion for
    getting the regular definitions ?  or why would i want
    the _f versions ?
    
    also,  must I link against the WINSOCK.DLL provided by
    PATHWORKS and do I have to redistribute that.   it would
    seem that sread,  swrite, sclose, and sioctl are unique to
    the PATHWORKS WINSOCK.DLL.  we currently use send, recv,
    closesocket,  ioctlsocket instead from WSOCK32.DLL.
    
    _sjz.
    
    

>    for now,  i will take that as a no.  but let me ask
>    some other less rhetorical questions.

I never got one, but I dont work in the pw group.....
    
>    if i use ws2dnet.h i get the FAR definitions.  I don't
>    want them.  I just want the  regular definitions for
>    things like nodeent without the _f. i tried just including
>    dnetdb.h and dn.h but that results in numerous things be
>    undefined at compile time.  what is the incantion for
>    getting the regular definitions ?  or why would i want
>    the _f versions ?

Are you 'upgrading' to winsock v2, or just trying to rebuild
a v1.1 app?   If you are just trying to rebuild, the Winsock
v2 api spec, section 2, has a blurb about backwards compatibility.
Basically all you are supposed to have to do is add the winsock2.h
include, and bang, your done.  Apparently this does not work as
you had hoped.  (I went straight to v2.2, so never noticed.)
Beats me why xxx_f's are different or better.  They do seem to
work ok in v2.  (I thought the FAR qualifier was a macro that
expanded to nothing.)

>    also,  must I link against the WINSOCK.DLL provided by
>    PATHWORKS and do I have to redistribute that.   it would
>    seem that sread,  swrite, sclose, and sioctl are unique to
>    the PATHWORKS WINSOCK.DLL.  we currently use send, recv,
>    closesocket,  ioctlsocket instead from WSOCK32.DLL.

If you are using winsock v2, you do not need to link w/the
winsock lib provided w/pathworks.  The pathworks extended
functions are accessed through WSAIoctl(), see dnext.c in
the samples directory for how to get at them.

If you are winsock v1.1, all bets are off.  (I used a call
to LoadLibrary() and GetProcAddress() to find out if they
were around.)

hth (but Im not sure it does)
--roger

    Existing WinSock 1.1 applications are intended to run over the WinSock 2
    framework without recompiling.  WinSock 1.1 applications should not
    use the WinSock 2 headers, they can and should be built with the 
    WINSOCK.H header file. Just because the underlying framework is
    WinSock 2 does not mean that the application has to upgrade to
    WinSock 2.
    
    The WinSock 2 architecture replaces the WINSOCK.DLL that each
    transport vendor supplied with a WINSOCK.DLL (and WSOCK32.DLL)
    shim that passes the WinSock 1.1 request first to WS2_32.DLL, which
    then passes the request to the appropriate transport service provider
    based on the address family (AF_DECnet, AF_INET) supplied in the
    socket() call. Microsoft is the supplier of the new WINSOCK.DLL,
    WSOCK32.DLL and WS2_32.DLL. PATHWORKS 32 supplies the DECnet service
    provider. 

    
    Even though the FAR in the _f versions is a  no-op,
    the typedef is not.  We have code that used to com-
    pile on NT, ULTRIX, and Digital UNIX with  no  dif-
    ferences.   Is that now history ?
    
    Is the answer to keep dorking around with some com-
    bination of includes until it compiles ?
    
    _sjz.

    
    seems like my line of questioning is getting nowhere.
    
    how about this question.   does the pathworks 32 sdk
    work with VC++ V4.1 ?  as best as I can tell the  an-
    swer is no.   reason being that windows.h  for  V4.1
    includes winsock (no provisions for winsock2.h) and
    all the pathworks stuff includes winsock2.h.
    
    can i build applications using the new sdk against
    winsock 1 ?
    
    _sjz.
    

    
    finally an answer (though i had to do it myself).  if
    you are a version of the WIN32 SDK that does not have
    winsock2 (e.g. Visual C++ V4.1),  then you need to in-
    clude the winsock2 stuff (from the pathworks  distrib-
    ution) before including windows.h (which includes win-
    sock.h) winsock2.h includes a #define to prevent  sub-
    sequent inclusion of winsock.h.
    
    _sjz.

If I use WSAocket(), I am unable to do (from different threads) simultaneous
WSASend() and WSARecv().  For the callback and overlap parameters, I am 
passing null.  The api spec says this will cause the call to operate as
if it were a regular send() or recv().

Switching to socket(), I can do simultaneous WSASend()/WSARecv() without
changing any other code.

I am using the 'default' socket returned by socket() or WSASocket(), ie I
dont call setsockopt() on it.  Is this the expected behavior?  Or am I
missing a socket option somewhere?

--roger

BTW, if it matters the behavior described in .32 is on a duplicated socket.

I have a few related questions regarding duplicating sockets.


   1) In winsock2 using tcp I can duplicate sockets using DuplicateHandle().
      For decnet sockets, DuplicateHandle() does not work.

      Is that intentional?  Is it supposed to work?  (If I use
      WSADuplicateSocket() things seem to work fine.)

   2) If I use CloseHandle() to close a socket() created socket, it appears
      to do nothing.  (I duplicate the socket, and then close the original.)

   3) After duplicating a socket, closesocket() closes the descriptor
      and appears to drop the link to the client.  (The client thinks
      the link goes down.)  In our app, almost invariably the original
      socket is closed before WSASocket() can be called with the 
      duplicated WSAPROTOCOL_INFO, is that a problem?  (Its not on TCP?)

   4) (Not really a question) If I do not call closesocket() after
      WSADuplicateSocket(), if the server terminates the link and calls
      closesocket(), the client never notices.  (It the same as 2)

--roger

If we press CTRL-C on our listening server, it takes a LOOONNNG time
for the window to come back.  When it does we get some sort of device
driver error message - could not complete blocking call within timeout.
Using ncp and setting the link state off this does not occur.


Is there a socket option or other way we can control how long the timeout is?

--roger

    I believe DuplicateHandle() only works for sockets that are
    implemented as file handles.  This is optional for WinSock 2.
    DECnet WinSock 2 sockets are not implemented as file handles.

Environment:
	Alpha NT 4.0
	Pathworks: EFT2C
        

WSAGetOverLapped() on a receive (and send) call always returns incorrect 
receive count, and its always a magic number of 0xfffe. The data gets 
transferred fine, but it is the transfer count which is incorrect. I have 
provided a small code snippet below, which runs as a server and the socket in 
question here was returned by WSAAccept().

I would really appreciate if someone could pls tell me what I am doing wrong.
Any tips? suggestions ?

Thanks

-Jayakumar

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

   listen_sock = WSASocket (AF_DECnet, SOCK_SEQPACKET, DNPROTO_NSP,
                     NULL, 0, WSA_FLAG_OVERLAPPED );

			........

   sock = WSAAccept( listen_sock, (struct sockaddr *)NULL, NULL,
                      ws2__conditionFunction, (u_long)&cb_parms );

   overlap.hEvent = WSACreateEvent();

   sec_stat = WSARecv( sock, &rcvbuf, 1, &len, &flags, &overlap, NULL );

   if (sec_stat == SOCKET_ERROR)
   {
      sec_stat                    = WSAGetLastError();
      if (sec_stat == WSA_IO_PENDING)
          sec_stat  = WSAGetOverlappedResult( sock, &overlap, &len, 
                                              TRUE, &flags );
   }

more info on .-1

	Creating an OverLapped socket but doing a blocking WSARecv() and 
WSASend() by specifying NULL overlapped parameter seems to work fine.

any thoughts?

Thanks
-Jay

Our application is a server process which accepts multiple DECnet connections.

For each connection there is thread which hangs on a WSARecv() and another
thread is used to do WSASend(). So when a WSASend() is issued on a thread, 
another thread is waiting on a WSARecv() for the same socket.

This seems to work fine.. until the 99th connection, wherein the first call
to WSASend() access violates. This access violation happens all the time
exactly at the 99th connection and is predictable.

I wonder if I am overlooking something while doing a simultaneous WSARecv() and 
WSASend(). The socket was created as an overlapping socket, while the WSARecv()
and WSASend() are issued as a blocking I/O.

Any pointers to where the problem might be or what I may be doing wrong ?

Thanks
-Jay

Our application is a (Alpha) server process which accepts multiple DECnet 
connections, duplicates the socket to a child process which taks to the clients.

In the child process for each connection there is thread which hangs on a 
WSARecv() and another thread is used to do WSASend(). So when a WSASend() is 
issued on a thread, another thread is waiting on a WSARecv() for the same 
socket.

This seems to work fine.. until the 99th connection, wherein WSASend()
call access violates. I noticed this happens the first time WSASend() is issued
-when- a WSARecv() is pending on another thread. If a WSARecv() is not pending 
on the other thread then WSASend() seems to go fine. 

This access violation happens all the time exactly at the 99th connection and 
is predictable.

I wonder if I am overlooking something while doing a simultaneous WSARecv() and 
WSASend(). The socket was created as an overlapping socket, while the WSARecv()
and WSASend() are issued as a blocking I/O.

Any pointers to where the problem might be or what I may be doing wrong ?

Thanks
-Jay

some more findings/answers:

RE .34.3 (closesocket() closes socket even though WSADuplicateSocket() called)
    We have discovered (empirical evidence) that forcing the process to wait
    after duplicating the socket until after the 'worker' process creates a
    new socket then the closesocket() as expected.  To wit, we have to enforce
    the following timing restraints:

        Proc 1          Proc 2
        socket
        listen
        accept
        duplicate
        wait            socket
                        signal proc 1
        close

RE .38 (overlapped result len was always feee)
RE .33 (I think) (socket vs WSASocket and (WSA)send/recv)
    The following scenario allows us to have multiple send/recv outstanding
    in multiple threads in multiple processes at the same time:
        WSASocket( AF_DECnet, SOCK_SEQPACKET, DNPROTO_NSP, 0, WSA_OVERLAPPED )
        WSASend/WSARecv( sock, bufs, bCnt, &len, flags, NULL, NULL )

--roger

    re 34.3 (issuing closesocket() after WSADuplicateSocket() but
    before WSASocket() in new process)
    
    DECnet WinSock 2 currently does not increment the reference count
    for duplicate sockets until the WSASocket() is issued in the new
    process. Therefore closing the existing socket on process 1 before
    creating the socket on process two closes the link.
    
    This behavior was based on the two points.
    
    1.  The sample scenario in the WSADuplicateSocket documentation that
    	shows the closesocket() after the WSASocket() in the new process.
    
    2.  "The underlying socket, however, will remain open until closesocket()
        is called by the last socket descriptor."  In the DECnet SPI,
        the descriptor and related process-specific data is created by 
        WSASocket() in the new process, not by WSADuplicateSocket() in the
        original process.
        

    re 82.38
    
    It's a bug.  Will definitely be fixed for the TIMA release.  If the need
    is more urgent please file a high-priority QAR.

re .42

We have a working workaround, so we dont plan to go back to overlapped io.
(Unless it fixes the 99th connection acc vio.)


--roger

re: .41

>>    This behavior was based on the two points.

While I can't comment on which methodology is correct, there are two reasons I
can think of as to why this is an issue:

- Historically its always been the case in Unix and NT that duplicating a 
  socket or an handle creates another instance of it. Fortunately this is
  also the case for Winsock2 TCP, even though Wsock2 requires 2 steps for
  duplicating a socket (WSADuplicate() in the main process  and WSASocket() in
  the child process).

- The main process should wait for the child process to signal before doing a
  closesocket(). Forcing the main and child to have some means of interprocess
  communication, just because they happen to use DECnet Winsock, is a 
  definitely a hassle, compared to using TCP Winsock, not to mention differing
  code paths

  just my thoughts!
  
-Jayakumar

When I establish many connections (~150) to our app, eventually a call
to WSARecv() fails, error 997 (IO_PENDING).  We pass NULL for the final
two parameters, forcing blocked mode receive.  Is this actually indicative
of something else (MSGSIZE? WOULDBLOCK?) or a bug?  This is with the wsp
created 19-march.  I create teh socket overlapped, but pass null for the
overlap and callback parameters, and 0 for flags.

--roger

I asked this "up top", but I guess this the appropriate to ask here.

Can anyone here answer my customer's question?

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

On page 5-34 in the Digital Pathworks 32 Application Programming Interface, at
the bottom of the page are a list of two WIN32 IOCB Restrictions.

The first one states:

This interface works only on Windows 95 with protected-mode transports.
A WIN32 interface for applications written to WIN32s is not available.
PATHWORKS 32 for Windows NT does not have a WIN32 IOCB Interface"

I don't understand this?  Does this mean that I cannot use the IocbSubmitEx
or IocbSubmit functions from NT but only from Windows 95?  There's lots of
other text which talks of NT with the IOCB but this statement has me
confused.  Could you please shed some light on the situation?  I would
very much appreciate it. Thank you.

Page 5-1 states:

	Support for WIN32 applications running under Windows 95 and NT is 
	provided in the IOCB transport interface.  Both DECnet and LAT 
	protocols are supported through this interface.


Page 5-34 states:

	The following restrictions apply to the WIN32 IOCB interface:

	This interface works only on Windows 95 with protected-mode
	transports.  A WIN32 interface for applications written to WIN32S
	is not available.  PATHWORKS 32 for Windows NT does not have a
	WIN32 IOCB Interface.