Re: Socket switch delay
From: Alexander Nickolov (agnickolov_at_mvps.org)
Date: 08/24/04
- Next message: Alexander Nickolov: "Re: WSAENOBUFS error with 'recv'"
- Previous message: Arkady Frenkel: "Re: Networking features in XP SP2"
- In reply to: mil: "Re: Socket switch delay"
- Messages sorted by: [ date ] [ thread ]
Date: Tue, 24 Aug 2004 15:12:39 -0700
Ah, hadn't realized the bit about the completion port...
Makes sense now.
-- ===================================== Alexander Nickolov Microsoft MVP [VC], MCSD email: agnickolov@mvps.org MVP VC FAQ: http://www.mvps.org/vcfaq ===================================== "mil" <mil@discussions.microsoft.com> wrote in message news:A73A2096-4B03-4AC3-A856-AC017F1A8879@microsoft.com... > > > "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: Alexander Nickolov: "Re: WSAENOBUFS error with 'recv'"
- Previous message: Arkady Frenkel: "Re: Networking features in XP SP2"
- In reply to: mil: "Re: Socket switch delay"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|