Question re client/server and blocking

[Frank Millman]

Hi all

I am developing a multi-user business/accounting application. It is
coming along nicely , though rather slowly :-(

I have hit an issue which will require a lot of changes to the code I
have written so far, together with an increase in complexity and all
the bad things that follow from that. Before I go ahead and make the
changes, I thought I would bounce it off the group and see if there is
a simpler approach.

It is a bit tricky to explain (yes I have read the Zen of Python) but
here goes.

There is a server component and a client component. All the business
logic is performed on the server. The client communicates with the
server via a socket. The server is multi-threaded - one thread per
connection.

The server receives messages from the client, and responds as quickly
as possible. Sometimes it must respond by asking the client a question.
It must not block while waiting for an answer, so this is how I handle
it (pseudo code) -

def handleMessage(self):
mainloop.askQuestion(questionText,self.answerYes,self.answerNo)

def answerYes(self):
handle Yes answer

def answerNo(self):
handle No answer

The main loop stores the function references, and sends the question to
the client. When it gets a reply, it calls the appropriate function. It
works well.

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. Depending on the context, the validation may have to
pass a number of checks, which may pass through a number of layers,
eventually returning True or False. e.g. -

def validate(self,data):
if not check1:
return False
if not check2:
return False
if not self.check3(data):
return False
if not self.check4(data):
return False
if not check5:
return False
return True

check3(self,data):
if not check3a:
return False
return True

check4(self,data):
if not check4a:
return False
if not self.check4b(data):
return False
return True

Effectively the entire chain blocks until a result is returned, but
provided each element performs its check quickly, this will not be
noticeable.

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?". 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 -

def validate(self,data,checkOk,checkNotOk):
# checkOk and checkNotOk are functions passed by the caller
self.data = data
self.checkOk = checkOk
self.checkNotOk = checkNotOk
if not check1:
self.checkNotOk()
if not check2:
self.checkNotOk()
self.check3(self.data,self.check3Ok,self.checkNotOk)

def check3Ok(self):
self.check4(self.data,self.check4Ok,self.checkNotOk)

def check4Ok(self):
if not check5:
checkNotOk()
self.checkOk()

The callee must then look like this -

def check3(self,data,checkOk,checkNotOk):
if check ok:
checkOk()
else:
checkNotOk()

Then on the odd occasion that the callee needs to ask a question, it
can do this -

def check4(self,data,checkOk,checkNotOk):
mainloop.askQuestion(questionText,checkOk,checkNotOk)

This is similar to Twisted's approach of deferreds and callbacks.
However, I do not think that using Twisted would simplify any of this -
I would still have to split my logic chain up into multiple callback
functions.

I believe that I can get this to work, that it will add a powerful
layer of functionality to my app, and that I could eventually refactor
it enough so that it is actually understandable. On the other hand, it
is much more complex than what I have got at present, and to change my
entire app to use this mechanism will be quite a task.

Have I explained myself adequately? Has anyone come across a similar
situation before? Any advice will be much appreciated.

Thanks

Frank Millman

 

[Bryan Olson]

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
> connection.
>
> 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.