Re: Socket switch delay
From: mil (mil_at_discussions.microsoft.com)
Date: 08/24/04
- Next message: Arkady Frenkel: "Re: WSAENOBUFS error with 'recv'"
- Previous message: Alexander Nickolov: "Re: Socket switch delay"
- In reply to: Alexander Nickolov: "Re: Socket switch delay"
- Next in thread: Alexander Nickolov: "Re: Socket switch delay"
- Reply: Alexander Nickolov: "Re: Socket switch delay"
- Messages sorted by: [ date ] [ thread ]
Date: Tue, 24 Aug 2004 14:15:02 -0700
"Alexander Nickolov" wrote:
> Your sever side send is never partial - it's overlapped.
Ok…just to double check that. My WSASend in the server will NOT return
partial results, unless it comes back with an error. Unlike the WSARecv which
can come back with partial buffers from a completion io.
Does this apply to the File Write IO when using completion io? i.e. I should
NOT worry about partial writes either.
In the client side now, it seems to be working in the same “style” even
though I am not using Overlapped IO. Is it because I am using the
WSASend/non-blocking sockets, or I should add code to catch the case of a
partial send anyway?
> buffers are queued and will be later sent. You must preserve
> them until notified
The buffers are preserved until they are needed no more, or the Completion
port has been “closed” and the threads have exited.
> BTW, I didn't see any code of yours to deal with the notification –
> you pass NULL event handle and NULL APC...).
Passing events and using callback functions is too easy ;) I am using
threads instead with the completion port.
while(1)
{
//...Reset these (important!)
dwIoSize=0;
pSession=NULL;
pIOContext=NULL;
//...Continually loop to service io completion packets
bSuccess = GetQueuedCompletionStatus(pThis->m_hIOCompletionPortIO,
&dwIoSize,
(PDWORD_PTR)&pSession,
(LPOVERLAPPED*)&pIOContext,
INFINITE);
if(pSession)
{
//...Sanity check
_ASSERTE(pSession->GetRefCount()>0);
//...Add a reference before we do any processing
//...so we can be sure the session won't be deleted
pSession->AddRef();
//...One less IO
pSession->DecrementIO();
if(bSuccess)
{
The above code runs in one or more threads and uses the
m_hIOCompletionPortIO for receives, sends, file read/writes.
Now, before you said my recvs are inefficient. That is not really true,
because I read a header and then all the packets together, so the TCP/IP
layer will just read them as a stream. Given that I also use a big recv
buffer, it shouldn’t cause any delays and it really does not do so. I always
get ~0ms round trips now.
While we were having this conversation, I changed my code to use one socket
again and tested it to see if it will “hit” the partial send. It never does
in the client and server (testing with 3 computers here).
But the more interesting thing is that I also “allowed” the client code to
send while the server is also sending over the same socket. It seems that it
doesn’t have the problems it had before. Now, I don’t know what has changed
in the code and I am not getting this behavior again. The only thing I
remember changing in the server was the “non-blocking sockets” together with
the overlapped IO, but I disabled that and it still works…so I am
investigating.
mil
- Next message: Arkady Frenkel: "Re: WSAENOBUFS error with 'recv'"
- Previous message: Alexander Nickolov: "Re: Socket switch delay"
- In reply to: Alexander Nickolov: "Re: Socket switch delay"
- Next in thread: Alexander Nickolov: "Re: Socket switch delay"
- Reply: Alexander Nickolov: "Re: Socket switch delay"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|