Question re client/server and blocking
fakeaddress at nowhere.org
Mon Mar 6 03:15:06 CET 2006
Frank Millman wrote:
> There is a server component and a client component. All the business
> logic is performed on the server.
Oh, what a give-away. If the logic is in the server, then the
client component should probably be the user's chosen web browser.
> The client communicates with the
> server via a socket. The server is multi-threaded - one thread per
> The server receives messages from the client, and responds as quickly
> as possible. Sometimes it must respond by asking the client a question.
> The server performs field-by-field validation - it does not wait for
> the entire form to be submitted, but validates the data as soon as it
> has been entered.
The modern way is to let the browser do the first cut at
validation and confirmation. Upon submit, the server
re-validates for security.
> Now I have decided that, in some circumstances, I want the server to
> ask the client a question before returning True or False - it could be
> as simple as "Are you sure?".
Simple checks such as "are you sure" can almost always be handled at
the browser. Nevertheless, the problem you note is quite real...
> This throws a large spanner into the
> above scheme. Each caller cannot be sure whether the callee (?) will
> return quickly or not, so it cannot afford to wait for a reply,
> otherwise it may block. The only solution I can think of looks like
> this -
Right. The server should go into a state where it can accept
the answer, among other things. Building interactive apps that
don't suck requires some sophistication in managing state.
More information about the Python-list