Re: Client Server and Throttling

From:

"ScottMcP [MVP]" <scottmcp@mvps.org>

Newsgroups:

microsoft.public.vc.mfc

Date:

Sat, 5 Dec 2009 01:20:10 -0800 (PST)

Message-ID:

<a1215c51-57b0-4ca9-b125-25586933beed@r24g2000yqd.googlegroups.com>

On Dec 4, 11:49 pm, TomChapman <TomChapma...@gmail.com> wrote:

I have written a client/server application set using TCP as the link.
Normally only a few packets are exchanged every minute. One thing the
client does is ask the server for a specific database record. The server
retrieves the record and sends it back to the client. In some odd cases
the client may all-of-a-sudden realize that it needs thousands of these
records.

The obvious method is to send one request wait for the return data and
then send the next request. That would work. However...

I'm thinking I'd get faster results for the client if I tried to stay
ahead by sending requests early so there were a few queued at the server
or in transit.

I don't know the bast way to do this. How do I know when to send a new
request. An individual client does not know what load the server is
under. It may vary.

I'm thinking I need some kind of counter. What is the best approach
here? How should I tackle this throttling problem.

It doesn't sound like there is a throttling problem, just a queueing
problem. And the queueing problem is largely solved for you by TCP.
If you send multiple requests they will simply wait in a winsock queue
until the server feels like inputting them. At some point, if the
server's input buffer fills, the client end will be paused by TCP,
typically with WSAEWOULDBLOCK. So it that sense you already have a
throttle (assuming you coded proper behavior for WSAEWOULDBLOCK).

----------
Question 2:

In many of my programs I seem to spend more time handling errors and
what-ifs then I do with nominal situation code. I'm use to thinking
about what-ifs.

So in the case where I am sending thousands of request-for-data
messages. In the perfect world, the server would correctly respond and I
would receive 100% of the responses. But I always worry about what-ifs.
Specifically in this case, what if something goes wrong somewhere and I
never get a response. If I'm queuing multiple requests and using some
kind of counter, the counter might get out-of-wack if a packet
here-or-there was never responded to. How do I handle this situation?

You can send a "request number" with each query, and have the server
reply include the same number. That will let you detect any error.