Design recommendation wanted.

Discussion in 'Python' started by Yannick Turgeon, Sep 24, 2004.

  1. Hello all,

    I'm implementing a protocol to communicate with a server through serial port
    (Yes Peter and Alex it's me again!). This means looking for lost packet,
    checksum error, connection failure.

    Whitout error, the normal course of things is:
    (C = Client - the one I'm programming, S = Server)

    Type #1 command:
    C: Send a packet to ask something
    S: Reply with the final answer
    C: Acknowledge reception

    Type #2 command:
    C: Send a packet to ask something
    S: Reply with part of the answer
    C: Acknowledge reception of the partial answer
    S: Reply with the following part of the answer
    C: Acknowledge reception of the partial answer
    ....
    S: Confirm the end of the answer
    C: Acknowledge reception

    Added to that, the server can send me an error packet due to my last sent
    packet being lost or checksum error or packet wrongly construct or
    impossibility to answer my "correctly constructed and received question".
    It includs in this error whether or not I should resend the last packet.
    Even more, there is a fixed maximum number of tentative to resent a packet.

    So my question is a general design one:
    Anybody has any hint how to handle in a well structured way that much
    possible errors and situation? How?

    Say I got 20 commands I can ask to server (which is near the real
    situation).

    I tried to make a base Command class that has a function that looks like:

    def getReply(expected):
    try:
    packet = serial.readline() #raise TimeoutError()
    packet_type, data = decode(packet) #raise FormatPacketError()
    # ChecksumError()
    # PacketNumberError()
    if packet_type == ERROR:
    raise ServerReplyError()
    if packet_type <> expected:
    raise UnexpectedPacketError()
    c = PACKETS[packet_type](data) #PACKETS is a dict containing Classes
    #raise DataFormatError()
    expect TimeoutError:
    blabla
    expect FormatPacketError:
    blabla
    expect ChecksumError:
    blabla
    expect PacketNumberError:
    blabla
    expect UnexpectedPacketError:
    blabla
    expect ServerReplyError:
    blabla
    expect DataFormatError:
    blabla


    With this solution, I will get lost very soon. I feel that I would need a
    kind of State-Managing system/class that would keep track of the command
    processing in general. But I'm not grasping it. I'm conscious that by not
    knowing the total situation, it's difficult for anybody to help but any
    suggestion, recommendation would be much appreciated.

    Yannick
    Yannick Turgeon, Sep 24, 2004
    #1
    1. Advertising

  2. Yannick Turgeon wrote:

    > With this solution, I will get lost very soon. I feel that I would need a
    > kind of State-Managing system/class that would keep track of the command


    It would simplify your life if you dealt with
    the problems (that can be dealt with) on the spot, as they
    happen. Don't use the exceptions as a mechnism to jump out of a
    block of code. This is so much easier to follow:

    if packet_type == ERROR1:
    ...deal with it..
    elif packet_type == ERROR2:
    ...deal with it ...
    else:
    try:
    c = PACKETS[packet_type](data)
    except ...:
    ...deal with this


    You don't have to have to put your code in one try/except
    block. This only depens on the nature of the response that
    you want to invoke when an exeption occurs. Feel free to nest them
    as needed. Keep the error and the response to it as one logical
    entity as much as possible.

    Istvan.
    Istvan Albert, Sep 24, 2004
    #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. Harvey
    Replies:
    0
    Views:
    673
    Harvey
    Jul 16, 2004
  2. Harvey
    Replies:
    1
    Views:
    822
    Daniel
    Jul 16, 2004
  3. David M. Siegel
    Replies:
    0
    Views:
    1,494
    David M. Siegel
    Oct 20, 2003
  4. Replies:
    17
    Views:
    576
  5. Replies:
    1
    Views:
    298
    Cowboy \(Gregory A. Beamer\)
    Oct 14, 2008
Loading...

Share This Page