Re: Socket switch delay

From: mil (mil_at_discussions.microsoft.com)
Date: 08/23/04 

Date: Mon, 23 Aug 2004 14:43:01 -0700

Alun, thanks again for the input.

> You should be able to use the same socket handle in two different threads,
>one to send, the other to receive. If you want to use them in the same

I was referring to the client sending data on this socket while the server
was also sending data in the same time. Which seems to be a big no no.

My client already uses non-blocking sockets, with the combination of the
select statement, so it will never “lock” while waiting to send or receive.

The server uses blocking sockets just because I am also using Overlapped IO
structures to send the packets. Thus I don’t need to care if it locks or not
since the Overlapped IO will never block me.

>You may be over-thinking things a little. Why are you using a zero-byte
>send buffer?

You are right, I always do so, when it comes to client/server stuff :)

The reason I am using a 0 bytes send buffer in my socket (i.e. I setup the
socket not to use any buffering, which actually works on XP but not on
Windows 2000 in the non-blocking sockets) is because all the communication is
done in packets already. Each packet is 32KB max and I can send one or more
of those in one go. The server and client, save all the data they want to
send in these packets, those get compressed (if possible/necessary) and
encrypted (through the MS Crypto API) and then I execute a WSASend with
multiple buffers. So I don’t need the protocol to buffer the data for a
second time, since I let it use my buffers for as long as it likes.

The receiver will always get a 256 byte header that describes what “is
coming” from the other end and will load the number of blocks with their
proper size, decrypt/decompress and pass them to the rest of the app.

After our conversations about the delay, I changed my client code so it uses
2 connections again but now:

The first connection is used to send and receive packets “synchronously”, by
sending the data, then blocking on an “Event”, which another thread receives
the reply and “Sets”. When the client wants to send a number of requests
without conflicting with server replies (i.e. wants delayed replies), it
simply tells to the server to use the second socket (channel) to send the
replies. Another thread handles the receive again from this second channel
and then the client (after it has finished with all the send-requests) blocks
on “multiple events”.

Since the second socket is used to send file data, or feedback messages
generated by the server, I don’t care about the 200ms delay, actually in this
case it really helps when there are many small packets generated by the
“server feedback messages”, for the reasons you explained to be already.

The whole thing now works so nicely that you almost cannot tell the
difference when the server is running on a dual PIII or a dual Opteron 248.
0% CPU usage when idle, instant responses on requests (and that includes a
round trip to the Access through OLEDB in the server side).

mil

"Alun Jones [MSFT]" wrote:

> "mil" <mil@discussions.microsoft.com> wrote in message
> news:8502BB0F-25AC-4FB8-BD7D-992FD9BAEE2C@microsoft.com...

Relevant Pages

  • Re: Problem with writing fast UDP server
    ... UDP packets per second. ... socket and threads. ... I wrote a simple case test: client and server. ... The maximum theoretical limit is 14,880 frames per ...
    (comp.lang.python)
  • Re: Socket switch delay
    ... both at the client and at the server (and why ... would you set the send buffer size to zero on a non-overlapped ... One glaring error is your client does ... So when you use a single socket, ...
    (microsoft.public.win32.programmer.networks)
  • Re: Socket switch delay
    ... > I was referring to the client sending data on this socket while the server ... sockets to provide TCP support without also supporting asynchronous ... > The server uses blocking sockets just because I am also using Overlapped ... > structures to send the packets. ...
    (microsoft.public.win32.programmer.networks)
  • Re: Problem with writing fast UDP server
    ... UDP packets per second. ... socket and threads. ... I wrote a simple case test: client and server. ... I included a bit of the code of the UDP server. ...
    (comp.lang.python)
  • Re: CAsyncSocket thread crashing on WM_SOCKET_NOTIFY message
    ... > getting a message after the socket has closed. ... > packets for the connection/socket that ends in an exception. ... The server is listening to port 33000. ... > Close Connection ...
    (microsoft.public.vc.mfc)