🚀 go-pugleaf

Ok. I apologise. I presented my thoughts incorrectly.

I *know* that shutdown with SD_SEND does close the socket, rather it will
notify when the data enqueued has been sent. Then when FD_CLOSE message is
caught/recieved, the server should clear the buffer using recv until return
is 0. Then use closesocket to close the socket and free the associated
resources. Ok?

Oh, and the problem is fixed - I'd paste a snippet, but it would probably
leave more questions unanswered. We were testing the server performance on a
windows 2000 pro machine. Then after encountering a serious leak (cpu and
mem) in lsass, we discovered that SP3 wasn't installed. That sorted
everything out.

Another question, does how seriously does OutputDebugString hamper
performance? We could test this ourselves, but just off the top of your head
from your experience, could you drop me a tip.

Thanks man,
Tharun.

"Remy Lebeau (TeamB)" <gambit47@yahoo.com> wrote in message
news:3f061924$2@newsgroups.borland.com...
>
> "Tharun Pillay" <tharun@webmail.co.za> wrote in message
> news:3f05bbc0@newsgroups.borland.com...
>
> > From my understanding, this instruction would tell winsock to
> > close the socket once *all* the data enqueued in the socket
> > buffer is sent. Right?
>
> I don't know where you got that understanding from.  First off, shutdown()
> does not ever close the socket at all.  You need to use closesocket() for
> that instead.  Second, specifying SD_SEND simply tells WinSock to disallow
> any further sends from that point on.  The socket itself is still open and
> valid, and can still receive incoming data.
>
> > The problem is that FD_CLOSE is triggered before all the
> > data is sent - the first 8k are sent and then FD_CLOSE fires.
> > Anyone know why????
>
> Please show a more complete code snippet that shows exactly what you are
> trying to do.
>
>
> Gambit
>
>