Re: Overlapped WSASend and IOCP

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

I actually try to ask about connection closure while some pending IO exists
on the socket. To clean-up per-IO resources we should prematurely initiate
completions. AFAIK, there are two ways to achieve this: Closing socket or
calling CancelIoEx. Since the CancelIoEx () is dependent on OS version, the
only way remaining is socket closure. What I don't completely grasp is the
closure flow on the IOCP infrastructure from beginning to end.

In my server there is an administrative interface by which an administrator
can send a command to the server to disconnect a client which is selected by
he or she. What should I do when a disconnect command received for both
graceful and abortive case? Should I call shutdwn(SD_SEND) and wait to call
closesocket() until GetQueuedCompletionStatus() returns with lpNumberOfBytes
set to zero? Or should I call closesocket() just after the shutdown
(SD_SEND) returns? Does the graceful closure harm performance?


"Len Holgate" <len.holgate@xxxxxxxxxxx> wrote in message
news:e16a8d15-9197-4807-8689-d2f8f62df7df@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Best in what situation?

If you want a graceful shutdown then you should call shutdown on the
send side of your connection when you have no more data to write and
then wait for the other end of the connection to do the same. Once
both ends are shutdown you know that all your data has got to the
other side and you can clean up your resources.

If you want to terminate the connection with no regard to losing data
then you might want to turn off lingering and do an 'abortive' close,
the advantage of that is that you reset the connection and you don't
end up in a TIME_WAIT state.

Without knowing what you're trying to achieve with the shutdown it's
hard to say what's 'best'.

Len
http://www.lenholgate.com

On Jul 7, 1:22 pm, "Kürsat" <x...@xxxxxx> wrote:
Hi Len,

Many thanks for sharing your experience with us.

I never run into the "partial send completion" stuation. I read an article
about it and decide to take precaution. Since our server will communicate
with existing clients via a predefined protocol we will unable to correct
any damage caused by partial send at client site. But after reading your
new
article about your flow control design, I changed my mind. You are right,
controlling resource usage is much more meaningful than handling every
side
effects caused by low resource stuation as long as possible.

Well, I have another question :

- What is the best way to disconnect a client from the server. In my
server,
I simply call shutdown() and closesocket() on that client's socket and
cause pending I/Os of that client are immediately completed. When last
pending I/O is completed, I release resources related to that client. Is
this correct?

Thanks in advance.

"Len Holgate" <len.holg...@xxxxxxxxxxx> wrote in message

news:d781dfa2-6b08-4bd9-bf3f-1590ad2fa9f8@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
On Jul 4, 3:02 am, iunknown <liusi...@xxxxxxxxx> wrote:





On Jul 3, 10:48 pm, "Kürþat" <x...@xxxxxx> wrote:

Hi,

My question is about using WSASend with an overlapped socket and IOCP.

In the software I strive to develop, it is possible to send messages
to
a
particular client from different threads simultaneously. Order of
calls
can
be guarantied by using sequence numbers but another more serious
problem
exists:

WSASend does not guarantee to grab all data in the user supplied
buffer
at
once. For example : If I supply a 10-byte buffer, it is not guaranteed
that
the GetQueuedCompletionStatus will give me 10 as lpNumberOfBytes on
completion. If I get 6 from GetQueuedCompletionStatus then I should
retry to
send last 4 bytes. For this reason I develop a design like this:

I first put the data into a temporary buffer. On completion, I check
If
all
of the data is sent. If so then I discard the temporary buffer,
otherwise I
grab unsent data from the temporary buffer and retry to send it. If a
thread
try to call WSASend while another call is still pending then that
thread
just appends it's data to the temporary buffer and returns. When the
pending
call completes it checks out the temporary buffer and sends remaining
data.
This means I can post only one send per-client.

Is this design correct?

Thanks in advance.

I also deal with the partial write this way. More detail please
referhttp://www.codeproject.com/KB/IP/IOCP_Server_Framework.aspx-Hide
quoted text -

- Show quoted text -

Personally, I think you're solving the wrong problem.

I've done a lot of work with IO completion port based servers and
async IO over the past few years and I've simply never seen this
problem occur for real except when machine resources are very scarce.
Treating 'partial send completion' as a problem that you need to solve
is, IMHO, not sensible. I've found that it's much better to simply
make sure that you don't get yourself into the situations that are
likely to cause it to occur as if you DO get yourself into those
situations the the fact that some of your sends are failing is
probably the least of your problems.

So, the first thing I'm curious about is what you're doing to cause
this to be an actual problem for you. I assume you can cause this
problem repeatably?

Possibly the easiest way to use up non-paged pool using async IO is to
continue issuing sends when the TCP receive window is full. This
causes your send data to be buffered in the TCP/IP stack and often
that uses non-paged pool... If left unchecked then you can use up all
the non-paged pool that you're allowed and then socket calls may start
to fail. Rather than adding code to cripple the performance of all
your sends it's better, IMHO, to monitor how many outstanding sends
you have and stop sending before you get to a point where you exhaust
resources...

I've just made this easy for users of my framework by building some
reusable code that clients can use to monitor the number of writes
that are pending on a connection and which can be configured to buffer
data until the pending writes complete... See
here,http://www.lenholgate.com/archives/000788.htmlfor more details. Of
course there are other ways that non-paged pool can be used up, so
this isn't the only thing that you need to keep an eye on...

Lenhttp://www.lenholgate.com
Free IOCP server framework available
here:http://www.lenholgate.com/archives/000637.html- Hide quoted text -

- Show quoted text -



.

Relevant Pages

  • Re: Multiple instances of CAsyncSocket in same thread
    ... connection failure back. ...  You have to close the socket completely, ...  But if a connection is pending, it is not clear that this does not result in a race ... it is causing an assertion failure, ...
    (microsoft.public.vc.mfc)
  • Re: Multiple instances of CAsyncSocket in same thread
    ... connection failure back. ...  You have to close the socket completely, ...  But if a connection is pending, it is not clear that this does not result in a race ... it is causing an assertion failure, ...
    (microsoft.public.vc.mfc)
  • Re: Multiple instances of CAsyncSocket in same thread
    ... connection failure back. ...  You have to close the socket completely, ...  But if a connection is pending, it is not clear that this does not result in a race ... it is causing an assertion failure, ...
    (microsoft.public.vc.mfc)
  • Re: Confused about GC & Disposing: How to get it right?
    ... controlling. ... As soon as you are done with the myConnectionobject and the resources it is ... The CLR can determine when a connection object is ... >> Not all objects have, nor do they need, a dispose method. ...
    (microsoft.public.dotnet.framework)
  • Re: Closing a database connection stored in a threadlocal upond death of thread
    ... ThreadLocal object and need to close it on death of the Thread. ... It is likely that you should release the db connection much earlier. ... release resources still extant, properly or otherwise. ... Lew's remarks on finalize() are spot-on. ...
    (comp.lang.java.programmer)