Thankx for your replies Ed and Max!
I think I will read specifications more closely from now on 
----- Original Message -----
From: Ed Lau
To: NT Developers Interest List
Sent: Friday, February 01, 2002 8:37 PM
Subject: [ntdev] Re: TDI_DISCONNECT_RELEASE problem
This is by design - when a TCP connection closes, it enters the TIME_WAIT state for a period of time equal to twice the maximum segment lifetime. You can see the state of TCP connections on your machine by typing “netstat -a -n -p tcp” at a command prompt.
Regards,
Ed lau
MidCore Software, Inc.
900 Straits Tpke
Middlebury, CT 06762
www.midcore.com
----- Original Message -----
From: Vovkos
To: NT Developers Interest List
Sent: Friday, February 01, 2002 10:57 AM
Subject: [ntdev] Re: TDI_DISCONNECT_RELEASE problem
Thanks for your reply Max!!
I figured out: that’s not my TDI client fault - I have the same behavior in
usermode. That’s what my usermode test app do:
- open tcp socket and BIND it to some port
- CONNECT to remote node
- do GRACEFUL DISCONNECT with either shutdown(SD_SEND) or closesocket (with
either SO_DONTLINGER (1) or SO_LINGER (l_onoff = 1, l_linger > 0))
I run this app once, and:
if I run this app during next several minutes I got WSAEADDRINUSE error on
connect - just the same as in my TDI client.
(By the way, bind operation completes successfully)
It appears that after graceful disconnect transport holds address in a limbo
state for some time…
Question - is this by design? If there a way to overcome this behavior?
Thanks in advance.
Vladimir
P.S.
Of course it is not a problem if I had unbinded socket for connection, but
in my case there is no client and server, and both nodes can initiate
connection…
----- Original Message -----
From: “Maxim S. Shatskih”
To: “NT Developers Interest List”
Sent: Friday, February 01, 2002 10:03 AM
Subject: [ntdev] Re: TDI_DISCONNECT_RELEASE problem
> You must not close the TCP connection file object till both a) your
TDI_DISCONNECT_RELEASE is sent and b)
> TdiClientEventDisconnect(TDI_DISCONNECT_RELEASE) is called.
>
> TDI_DISCONNECT_RELEASE sends FIN and moves the TCB
> ESTABLISHED -> FINWAIT_1.
> FIN/ACK arrival moves to FINWAIT_2, the TDI client is not notified on
this.
>
> Then your TDI code will need to wait till
TdiClientEventDisconnect(TDI_DISCONNECT_RELEASE) will be called. This means
incoming FIN
> arrival, and the TCB will be in TIME_WAIT state. It is fine to close the
TCP connection file object in this state.
>
> Or otherwise, if TdiClientEventDisconnect(TDI_DISCONNECT_RELEASE) is
called first, it moves to CLOSE_WAIT. Then your
> TDI_DISCONNECT_RELEASE sends FIN and moves the LAST_ACK, it is OK to close
the TCP connection file object in this state. FIN/ACK
> arrival will kill the TCB, the TDI client will not be notified on this.
>
> Attempting to close the TCP connection file object while not it LAST_ACK
or TIME_WAIT will send TCP RST. So, you must not close it
> too early. Lingering close implementation is up to TDI client, TCP will
not do this.
>
> Max
>
> ----- Original Message -----
> From: “Vovkos”
> To: “NT Developers Interest List”
> Sent: Friday, February 01, 2002 3:18 AM
> Subject: [ntdev] TDI_DISCONNECT_RELEASE problem
>
>
> > Greetings All!!
> > I have TDI client which just dropped TCP connection when needed
> > (TDI_DISCONNECT with TDI_DISCONNECT_ABORT flag). But now we want to
change
> > it to graceful disconnect (FIN->,ACK<-,FIN<-,ACK->) I hoped that all I
had
> > to do is to change TDI_DISCONNECT_ABORT -> TDI_DISCONNECT_RELEASE, but
it
> > appears that after such disconnect TransportAddressFile goes to some
strange
> > state… For example subsequent calls to TDI_CONNECT return 0xC000020A
> > (STATUS_ADDRESS_ALREADY_EXIST) ???
> > I think maybe I do disconnect wrong?
> > I prepare disconnect irp like following:
> >
> > //…
> >
> > PIRP pirpDisconnect = TdiBuildInternalDeviceControlIrp(
> > TDI_DISCONNECT,
> > m_pConnectionFile->DeviceObject,
> > m_pConnectionFile,
> > m_CurrentIrp.evntReady, &m_CurrentIrp.IoStatus);
> >
> > if (!pirpDisconnect)
> > {
> > m_status = STATUS_INSUFFICIENT_RESOURCES;
> > return FALSE;
> > }
> >
> > // here I tried to pass either nullified TDI_CONNECTION_INFORMATION or
> > // fill RemoteAddressLength with remote node’ addr like this:
> > ::RtlZeroMemory(&m_CurrentIrp.TdiConnectionInfo,
> > sizeof(TDI_CONNECTION_INFORMATION));
> > m_CurrentIrp.TdiConnectionInfo.RemoteAddressLength =
sizeof(TA_IP_ADDRESS);
> > m_CurrentIrp.TdiConnectionInfo.RemoteAddress = &m_CurrentIrp.taAddress;
> >
> > LARGE_INTEGER qTimeout;
> > qTimeout.QuadPart = Int32x32To64(dwTimeout, -10000);
> >
> > DWORD dwFlags = TDI_DISCONNECT_RELEASE;
> >
> > TdiBuildDisconnect(
> > pirpDisconnect, m_pConnectionFile->DeviceObject,
> > m_pConnectionFile, DisconnectCompletionRoutine, this,
> > &qTimeout,
> > &dwFlags, // DDK states it should PULONG, I tried both ULONG and
> > PULONG - strange, but BOTH work 
> > &m_CurrentIrp.TdiConnectionInfo, NULL);
> >
> > m_status = IoCallDriver(m_pConnectionFile->DeviceObject,
pirpDisconnect);
> >
> > if (m_status == STATUS_PENDING && bBlock)
> > WaitForReady();
> >
> > //…
> >
> > Or maybe I should do something special in my TDI_EVENT_DISCONNECT? Now I
> > just return STATUS_SUCCESS…
> >
> > Maybe anyone knows whats the problem, or has a clue?..
> > Please help…
> > Thanks in advance.
> >
> > Vladimir
> >
> >
> > —
> > You are currently subscribed to ntdev as: xxxxx@storagecraft.com
> > To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
> >
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@narod.ru
> To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
>
—
You are currently subscribed to ntdev as: xxxxx@midcore.com
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com —
You are currently subscribed to ntdev as: xxxxx@narod.ru
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
—
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com