Re: TCP - Outstanding Begin Receives

Thanks a lot this really helped. I just want to clarify that I understand
your response.

As for your answer to #1, if this is the case, then I don't have to worry
about the outstanding requests holding on to my state object, this should all
be garbage collected, right? Do you know the name of the structure that the
OS holds for these requests? I could use CLR Profiler to verify this, huh?

As for #2, I didn't know that there is a possibility of an exception being
thrown when closing the socket; I've always seen a count of 0 and do the
appropriate thing. In most cases, I do a shutdown of the send channel and
wait for the other socket to respond in a similar fashion before I shutdown
the receive channel. I don't like Microsoft's recommendation of shutting
down both channels because this causes an exception in most cases to be
thrown in the outstanding asynchronous receive request (previously, I handled
this but logged it and I don't like cluttering the log for this purpose).
The only time I do a shutdown of both and close is if the server recognizes a
connection that has been inactive for a period of time (e.g. physical line
was severed, etc.).

Thanks again for your input.

"Vadym Stetsyak" wrote:

> > 1) If I do a close on the socket, will this cleanup any outstanding
> > receive
> > / send requests?
>
> Yes
>
> > 2) I am holding on to the IAsyncResult for the outstanding receive and
> > send
> > (in my wrapper socket class), so I could use the EndReceive prior to
> > closing
> > the socket. The issue here is that if for some reason the remote (client
> > socket) is not closed, this call will block (at least that's what MSDN
> > states). I think 99% of the time the client socket will be closed, but I
> > also have a cleanup process that checks if we haven't had read / write
> > data
> > from the socket for a certain amount of time, then I have to do a hard
> > close
> > from the server...would the EndReceive block in this case?
>
> EndReceive will block for timeout, of Socket keepalive option was not
> specified.
> If server will close the socket EndReceive in the client side will throw an
> exception, or
> return 0 bytes, indicating graceful connection close ( more probable ).
>
> --
> Vadym Stetsyak aka Vadmyst
> http://vadmyst.blogspot.com
>
> "Larry Herbinaux" <LarryHerbinaux@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in
> message news:71CDA912-E9A2-4746-80B0-A4208249F173@xxxxxxxxxxxxxxxx
> > Thanks Vadym,
> >
> > On your first point, the async request is being performed in a thread pool
> > thread (e.g. when the AsyncAccept callback is called it is on a thread in
> > the
> > thread pool and I immediately do a BeginRead within this thread), so this
> > thread never exits, right? I'm sure that the request is registered in the
> > OS
> > and when an IOCompletionPort is signaled, the callback runs on a thread in
> > the thread pool and this process starts all over again until we close the
> > socket.
> >
> > Depending on who (client / server) and how the socket is closed, there
> > still
> > could be an outstanding async receive request. We are using 1.1, so in
> > your
> > second point I'm not sure it applies. A couple of questions on this:
> >
> > 1) If I do a close on the socket, will this cleanup any outstanding
> > receive
> > / send requests?
> >
> > 2) I am holding on to the IAsyncResult for the outstanding receive and
> > send
> > (in my wrapper socket class), so I could use the EndReceive prior to
> > closing
> > the socket. The issue here is that if for some reason the remote (client
> > socket) is not closed, this call will block (at least that's what MSDN
> > states). I think 99% of the time the client socket will be closed, but I
> > also have a cleanup process that checks if we haven't had read / write
> > data
> > from the socket for a certain amount of time, then I have to do a hard
> > close
> > from the server...would the EndReceive block in this case?
> >
> > "Vadym Stetsyak" wrote:
> >
> >> Async I/O will be canceled if the thread that initiated that I/O will
> >> exit.
> >>
> >> This means if you're calling BeginReceive the thread that accepts
> >> incomming
> >> connections - it will be sufficient to stop that thread.
> >>
> >> Also if you will call Socket.Shutdown, the exception will be thrown in
> >> EndReceive(...) or appropriate SocketError returned ( under .NET 2.0 )
> >>
> >> --
> >> Vadym Stetsyak aka Vadmyst
> >> http://vadmyst.blogspot.com
> >>
> >> "Larry Herbinaux" <LarryHerbinaux@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in
> >> message news:2AE9B9CA-AA97-4538-A922-793CF919EBCB@xxxxxxxxxxxxxxxx
> >> > It is possible to have an outstanding BeginReceive call when closing a
> >> > socket. There isn't a call from the IAsyncResult to cancel this if it
> >> > hasn't
> >> > completed. This can be an issue when you are accepting a large number
> >> > of
> >> > connections in a long running process.
> >> >
> >> > First off, why isn't there a method for cancelling these requests?
> >> >
> >> > Is there a work around that anyone knows about?
> >> >
> >> > My state object that is referenced by the request is large, so I at
> >> > least
> >> > try to cleanup this reference, but there is still an OS object that is
> >> > queued
> >> > for this request that doesn't get freed.
> >>
> >>
> >>
>
>
>
.

Relevant Pages

  • TCP connection hang problem
    ... I'm running a simulation with one client machine and four server ... size 432 bytes) through a TCP connection to server and server reads it. ... where the clients sends all the requests to a central ... to the socket and the central guy stops reading from the socket. ...
    (comp.lang.c)
  • TCP connection hang problem (resumes upon new TCP request)
    ... I'm running a simulation with one client machine and four server ... 432 bytes) through a TCP connection to servers and servers read it. ... where the clients sends all the requests to a central distributor ... The client stops writing requests to the socket and the central ...
    (comp.unix.programmer)
  • Re: CAtlHttpClient Navigate()
    ... TCPWaitedTimeDelay registry setting parameter to control the number of ... of 4000 sockets and that was the point when we started seeing the Socket ... I suggest that the problem isn't in CAtlHttpClient, but more likely in the way your test harness is designed. ... After about 4000 requests we start getting a "WSAEADDRINUSE" ...
    (microsoft.public.vc.atl)
  • Re: Portable way to close() and prevent RST with non-empty receive queue?
    ... >> I'm implementing a HTTP monitoring server that responds to all requests ... On Linux 2.6.14 without the shutdown, the client gets a RST ... RST is sent by the kernel when it receives data for the socket ...
    (comp.unix.programmer)
  • Re: 2.6.22-rc1-mm1 cifs_mount oops
    ... file requests time to exit from the cifs vfs). ... in various socket calls). ... sfrench at-sign us dot ibm dot com ...
    (Linux-Kernel)