Re: Client Server and Throttling
For what it's worth, even microsoft managed (of course) to get it wrong in
their server.sys.
See, for example, KB 297019. When outlook PST files are located on a remote
server over a slow WAN link, and many users are accessing the files at once,
the server may run out of paged pool, or hang.
This tells that most likely, server.sys does NOT limit or throttle total
amount of data pending for transmission, thus, when it gets a lot of
requests at once, it will try to queue excessive amount of data, possibly
exceeding available memory.
"Joseph M. Newcomer" <newcomer@flounder.com> wrote in message
news:dhrkh5p6tqr1fae6sqrm0rcetdra025r17@4ax.com...
See below...
On Fri, 04 Dec 2009 22:49:52 -0600, TomChapman <TomChapman12@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.
****
Yes, this sounds like a good idea
****
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.
****
Then the requests will simply wait at the server until it gets around to
them. I don't
see a problem here.
****
I'm thinking I need some kind of counter. What is the best approach
here? How should I tackle this throttling problem.
****
You could limit the number of outstanding requests from any given client,
but as you point
out, that's a simple counter. But I'd be inclined to a more laissez-faire
approach (free
market) and just dump out all the requests; if the server is running slow,
they take
longer to process, but so what? You're going to need them anyway, so just
queue them up
and let the server deal with the issue.
joe
****
----------
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?
Joseph M. Newcomer [MVP]
email: newcomer@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm