Question re client/server and blocking

Discussion in 'Python' started by Frank Millman, Mar 5, 2006.

  1. 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
    Frank Millman, Mar 5, 2006
    #1
    1. Advertising

  2. Frank Millman

    Bryan Olson Guest

    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.


    --
    --Bryan
    Bryan Olson, Mar 6, 2006
    #2
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Hendra Gunawan
    Replies:
    1
    Views:
    12,413
    Allan Herriman
    Apr 8, 2004
  2. Andre Kelmanson

    blocking i/o vs. non blocking i/o (performance)

    Andre Kelmanson, Oct 10, 2003, in forum: C Programming
    Replies:
    3
    Views:
    911
    Valentin Tihomirov
    Oct 12, 2003
  3. nukleus
    Replies:
    14
    Views:
    815
    Chris Uppal
    Jan 22, 2007
  4. brieuc
    Replies:
    5
    Views:
    2,147
    Esmond Pitt
    Mar 20, 2007
  5. Christian
    Replies:
    5
    Views:
    720
    Esmond Pitt
    Dec 2, 2007
Loading...

Share This Page